[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