Hacker News new | ask | show | jobs
by Androider 1579 days ago
Where is the ssh-agent reading your private key from? If from ~/.ssh/, you're just one "npm install" away from the key being exfiltrated by a compromised package. If the private key is on your Yubikey, you're already good. The 1password agent will provide a good hardwareless method of keeping your private keys off the local filesystem, and it'll sync between your devices too.
4 comments

> you're just one "npm install" away from the key being exfiltrated

It's not as easy as that if your private key is protected with a passphrase, which IMO ought to be the default option.

I am amused by the rationalization going on here, though... taking extra steps to secure your SSH private key because you might "npm install" something bad. There's nothing wrong with enhancing the security of your private keys through dongles or TPM chips but it's a lot better to attack the root of the problem: just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.

My day job has me working with javascript packages but I don't have npm installed on my system, and never will. All of my work with npm happens inside docker containers. This offers many workflow advantages besides a layer of security.

> just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.

So it is unreasonable to want to develop a JS app on the same machine I use for SSH?

Docker works I guess, but adds a lot of mental (and in the case of Docker for Mac, performance) overhead.

Just because I happened to be dealing with this today (on Windows with WSL2 but same rules apply) I'll make a comment.

The issue I ran into was due to Docker for Desktop binding the local filesystem into the devcontainer running in a WSL2 VM.

The solution to this is to instead use a named volume in your docker-compose.yml and in your Dockerfile copy the files from your working directory into your devcontainer.

This provided an incredible improvement in the performance of using devcontainers in vscode. The one big drawback to this approach that I've run into is needing to make sure I commit and push my code to a git repo when I'm done working as there's not a copy stored on my local machine.

Even better is defense-in-depth. Do development in VMs AND don’t store your private SSH in plain text on your laptop.
Your ~/.ssh/ private key is not readable by normal users since it's encrypted, so that isn't going to work.

The main security benefit is here:

> 1Password will ask for your consent before an SSH client can use your SSH key. Because of this, there's no concept of adding or removing keys like with the OpenSSH agent.

This prevents SSH agent hijacking, requiring either a social engineering attack to bypass or a privesc.

> If the private key is on your Yubikey, you're already good.

This is the way.

Why can the compromised package not also access wherever 1p is storing the keys or access the part of memory they're loaded into?
Because the keys never exist "on disk"? Why isn't every password manager pwned on every persons machine is what you're asking it seems.
No but what you seem to be saying is .ssh is pwned on every machine that doesn’t use a password manager.
A process can not dump the memory of another process if those processes are executing under different users, or the process performing the dump is root.

On many OS's there are even more strict restrictions, where within a user a process can only dump the memory of processes that are its direct descendants.

1p runs as the logged in user so does a hypothetical malicious npm package.
they would have access to the socket not the key, sure a very elaborated attack can probably figure out how to exfiltrate a lot of things (since they have already compromised the host) but for most, if they don't see things in ~/.ssh they would just go away and figure out another host to exfiltrate keys