One thing I like to do with the SSH Agent is also forward my X.509 certificates by adding new opcodes to the SSH Agent protocol, then you can do stuff like PKCS#11 on the remote side with your local smartcard. [0]
This gives you, among other things, passwordless but authenticated "sudo" capability (which is actually required by the DOD, though nobody does it).
[0] http://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?ln...
I regularly ssh into boxes with varying IPs. Something like "ssh -i <key> <user>@<ip>". Every time I want to scp a file, I quit the ssh session, press UP, modify the ssh command into an scp one, execute then restore the ssh session. It's slow and annoying.
Does anyone know of a way to use scp without hassle, once ssh session is established?
Something 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.
The author states:
>"Later in the handshake process, a set of new, ephemeral and symmetric keys are generated and used to encrypt the SSH session traffic."
This isn't correct. After the TCP handshake, both systems agree on a session key by using the Diffie-Hellman key exchange. It's only after establishing a session key that user authentication takes place. There's a re-keying event but that's not part of the initial handshake and only happens later when some threshold(time or blocks) has been reached.
The problem is that this breaks with use of tmux or similar tools since the scope of the SSH session is often smaller than the scope of my doing something on a machine. I've moved to just having a limited-use key with access to dev machines and git on the hard drive of each machine I use, which covers the cases I care about.
I restart my computer pretty infrequently and everytime I do, I can't connect to various things. Inevitably I realize I didn't run ssh-add and after debugging, things work again once I have run this command. But I never really looked into the basics.
Thanks to this article I realize why I need to do that every time. :)
SSH agent has other interesting possibilities too - it's an opaque channel from far server to your local machine, there must be various cool hacks you could do.
Years ago I wrote something to copy a file from a remote machine to my desktop over ssh-agent, worked well back then. https://matt.ucc.asn.au/ssh-xfer/
Thank 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?
A pithy way of explaining all this: ssh-agent is exactly like a U2F token but implemented in software and using a slightly different protocol. But both do the same thing and serve the same purpose.
What 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?
Cool, didn't know about -J! I have been using dodgy port forwarding all this time.
Now I just need to set up my Somu, and I will be living in 2020.
Nit: The TL;DR is what is called an introduction.
I skip ssh-agent and use gpg-agent instead, which does both ssh and gpg agenting. Combined with monkeysphere, I store ssh private keys in gpg rather than in the encrypted ssh format.
Thanks 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.