SSH Agent Explained
smallstep.com
SSH Agent Explained
1–10 of 50 posts
Re: SSH Agent Explained
#2Nit: The TL;DR is what is called an introduction.
Re: SSH Agent Explained
#3Thank you for the well done intro and the security risk implied with agent forwarding. I'd be curious how to actually sign with the ssh-agent as you mentioned it. I'd also like to know if when OS at login automatically decrypts the default private key, for later use e.g. pushing to github, what would be the risk? Would there be another preferred behaviour?
Re: SSH Agent Explained
#4Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent
It works with SSH and Mosh. The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf. And the principal's authorization should then be limited to that context.
The ssh-agent protocol doesn't give the agent any of that information; it's really just intended for local SSH-like processes to ask "please sign this blob so I can connect somewhere" without them having to see the plaintext private key. Forwarding that to untrusted remote machines isn't ideal.
It turns out an agent can get access to this information and limit the scope of authorization in a mostly[1] backwards-compatible way, which is how guardian-agent works, but imo it would be preferable if a future version of the SSH protocol were designed more expressly for secure agent forwarding.
[1] For (c), the remote server has to be OpenSSH because guardian-agent relies on a nonstandard extension.
Re: SSH Agent Explained
#5Nit: The TL;DR is what is called an introduction.
Yeah that is an odd choice of words.
Re: SSH Agent Explained
#6Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent It works with SSH and Mosh. The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf.…
YES. It would be so easy for OpenSSH to fix agent forwarding. Just need to limit authority and/or ask for consent for a particular action.
Re: SSH Agent Explained
#7Something that's skimmed over in the article but not addressed is: if the key pair isn't used for encryption, then how are session keys protected?
The answer is: using the server's public key which is transmitted to client when establishing the connection.
But then it's trivial to perform a person-in-the-middle attack and both observe and manipulate the plain text data by sending the client the attacker's public key.
That's why it's crucial to retrieve host keys via secure channels and explicitly whitelist them on clients.
Re: SSH Agent Explained
#8Nit: The TL;DR is what is called an introduction.
I don’t think it’s a nit. It’s polite and proper feedback on the misuse of a term. The TL;DR here didn’t really convey anything useful from the rest of the post. So it ought to be rightly called “Introduction”, as you said.
Re: SSH Agent Explained
#9What I am missing is why ever use ssh agent, including any re-enforced variations, if ProxyJump has none of the ssh agent issues and has little to no other disadvantages?
Re: SSH Agent Explained
#10Something that's skimmed over in the article but not addressed is: if the key pair isn't used for encryption, then how are session keys protected? The answer is: using the server's public key which is transmitted to client when establishing the connection. But then it's trivial to perform a person-in-the-middle attack and both observe and manipulate the plain text data by sending the client the attacker's public key.…
"Protected" is an odd word to choose here because session keys are agreed long before we know who we're talking to.
The approach of SSH (like modern TLS) is to create a secure channel between two participants and only then authenticate one or both participants by binding credentials to this secure channel.
The article gets that upside down, which is understandable because most people seem to imagine that it'd be essential to figure out who you're talking to first and only then encrypt things, but actually the opposite is better.
If you do Trust On First Use as many SSH users do, then you're correct that bad guys can interpose on that first connection if they happen to get lucky - but that's because they can authenticate as the "correct" server by presenting their own public key since you have no idea what the correct one looks like.