[grishka]

But then enter it every time you need to use the key, thus negating the advantage of just magically logging in without passwords? Because if you use ssh-add and only enter the passphrase once per reboot, apps will be able to use it, that's the point.

[Xylakant]

You can (and should) use ssh-agent/ssh-add to handle the key for you. It will still protect you against apps reading the key - ssh-agent only performs crypto operations on behalf of programs and will not hand out the private key.

[PlutoIsAPlanet]

So a malicious app instead could just read your known hosts file, use the SSH agent to connect to them and spread malware that way, including installing its own public key.

Doesn't really protect you.

Sandboxing is pretty much the only way to solve this, SELinux does place restrictions but that's a dumpster fire of over engineering that's useless for the end user, who when they find their computer isn't doing what they want it to do, will turn it off.

[Xylakant]

It protects from exfiltrating the key, which is something. Because yes, the app could connect (if the key has been loaded, which is not guaranteed) but that’s something entirely different. Not saying it’s not a threat, but it’s a different threat with different mitigation.

[speed_spread]

Could you individually authorize every app for ssh-agent access? Maybe like sudo, the app would get a temporary token. This would work well in combination with a sandbox.

[3np]

Indeed. You can even break out the ssh-agent in an offline VM, proxy your ssh auth socket(s) from the agent, and have it prompt for approval that persists with a configurable timeout.

QubesOS calls this "split ssh" and you can use the same pattern with pgp.

There's also this which I don't see mentioned much: https://manpages.debian.org/unstable/ssh-agent-filter/ssh-ag...

[LarryMullins]

A malicious program could also add a passphrase-logging wrapper around `ssh` or `sudo` to your PATH and nab your password the next time you try to use either of those. This whole model of computing assumes that you'll never run a malicious program, it completely collapses if you do.

[Xylakant]

Absolutely, but there are various attack vectors that different mitigations are effective against.

The program doesn’t even need to be malicious, for a while it was a pretty common attack vector to trick browsers into uploading random file you could access.

Later, a malicious ssh server could read memory of the ssh process, potentially exposing the private key (CVE-2016-0777)

Using an agent with an encrypted key protects against that. Using a yubikey/smartcard as well. So it’s strictly a good thing to use it.

A yubikey could potentially protect you against a malicious program that wants to open connections if you have set it up to confirm every key operation - but that comes at a cost. You could also use little snitch to see what network connections a program opens, protecting you against a program trying to use your agent to access a server.

[jesprenj]

The app in question can just dump the memory of ssh-agent and obtain the private key from there. Or not?

[tristor]

Usually no. It requires root / Admin to dump memory of other processes, generally. Although vulnerabilities do exist.

[jesprenj]

Are you sure this is how, let's say, Linux behaves?

I tested it now in a minimal privilege account in a chroot on Debian 11 that I use for login from untrusted machines, and strace worked. This is how I captured a password entered into a ssh client password prompt, opened in another login shell of the same user:

-bash-5.1$ ps aux | grep abcde

z 2502130 0.0 0.3 9500 6132 ? S+ 18:04 0:00 ssh abcde@localhost

z 2502140 0.0 0.1 6316 2336 ? S+ 18:04 0:00 grep abcde

-bash-5.1$ strace -p 2502130

strace: Process 2502130 attached

read(4, "s", 1) = 1

read(4, "e", 1) = 1

read(4, "c", 1) = 1

read(4, "r", 1) = 1

read(4, "e", 1) = 1

read(4, "t", 1) = 1

read(4, "\n", 1) = 1

write(4, "\n", 1) = 1

ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0

[jeroenhd]

"Just magically logging in" is more of a nice side-effect than the intended purpose, in my opinion. SSH keys allow you to let multiple people log into a server without needing to set up complicated user accounts and without sharing a password that quickly becomes difficult to change.

You can have the best of both worlds by storing the key itself in a place that's not readable by many programs. TPMs and other such tech can store a key securely without risk of FunnyGame.app sending it to a remote server. In this model the key would be stored inside a safe, sandboxed place, only readable by an SSH agent or similar, which will prompt for permission to use the key every time. With fingerprint scanners and other biometrics being available even in cheap devices, this process can be relatively seamless.

If you run sufficiently modern SSH software, you can also use external key stores like Yubikeys to authenticate with plain old OpenSSH.