One of the problems here is that the SSH agent protocol doesn't include the host that's being authenticated to in the request. In theory we could implement an SSH agent that popped up a request asking you to agree to the request before signing - but it has no way of knowing who it's signing on behalf of, because the protocol doesn't include the destination
@mjg59 This is not very well known, but actually, these days it does! OpenSSH 8.9 added the publickey-hostbound-v00@openssh.com extension which does exactly that. It's currently used in combination with restrict-destination-v00@openssh.com to implement "ssh-add -h" constraints. See https://www.openssh.com/agent-restrict.html#authverify
@faidon …oh gosh I did read about that and then entirely forgot! I think just giving the server key back makes it hard to do confirmation notification if you're using hashed entries in known_hosts?
Ideally you'd be able to get a prompt saying "evil.com wants your ssh key" and you'd say no, and also if a site says "cats.com wants your ssh key" and then tries to use that to access dogs.com dogs.com would see that the signature was for cats.com, but the protocol doesn't seem to allow this
I unironically love the SSH agent protocol and I have done some terrible things with it at a professional level but I think given what we know now this is now what it would look like if developed again
@mjg59 I've always considered it risky for this sort of reason.
Any time I need to SSH into a remote system via a not-fully-trusted jump box I've just port forwarded the remote system and then run ssh localhost:1234 to get to it.
@mjg59 And you have to explicitly consent to the host forwarding that port and SSH to the forwarded port (vs having your agent there ready for anyone on the remote box to use at their leisure).
@mjg59 Presumably you could at least look at getpeerucred(3C) on the socket, though, and report on the process that's asking for a signature? Depending on what SSH does to the visible arguments, you might even be able to print something relatively accurate about what name you used to connect to the remote system? You could also presumably grovel in /proc/PID/fdinfo to find out the IP of the remote system to which an apparent SSH process has connected.
Add comment