SoylentNews is people
SoylentNews
SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.
ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.
ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!
Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.
How and why have soylentils had to deal with SSH agent forwarding?
Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?
(Score: 2, Interesting) by Anonymous Coward on Tuesday April 07 2020, @01:59AM (4 children)
With either the newer (2016) ProxyJump, or ProxyCommand with netcat or socat, you can traverse multiple jump hosts, and never expose your keys.
I've never seen a situation where agent key forwarding was ever required.
I used to have a bastion host at work that required a port knock. The script for ProxyCommand would check if host was directly reachable (on-site / vpn up), if not it would do the port knock, and then automatically traverse a second internal jump host-- all completely transparent when I used it. I would just 'ssh hostx'
openssh is pretty damn amazing at what you can do with it. Well worth spending a few minutes with its man page.
(Score: 0) by Anonymous Coward on Tuesday April 07 2020, @06:25AM (3 children)
doesn't port forwarding simplify access to gitlab type of stuff? I log into the cluster, get disconnected, I'd like to not load the key all over again when I reconnect. Also I may have several terminals logged into the cluster because I want to edit multiple source files.
what would the alternative to key forwarding be? honestly asking.
(Score: 0) by Anonymous Coward on Tuesday April 07 2020, @11:20AM (2 children)
If you want to log back into the same machine again quickly after disconnection then a key in an agent is the way to go.
If you want to rapid fire concurrently connect to the same machine repeatedly then multplexing is the way to go.
If you need to pass through a machine to get to others behind it, then ProxyJump is the way to go.
Any of those can be combined.
Can you give a sanitized set of commands illustrating your workflow connecting to or through GitLab?
(Score: 0) by Anonymous Coward on Tuesday April 07 2020, @02:35PM (1 child)
main usage type: I'm on laptop. I work on code, push to gitlab. I then connect to cluster (.ssh/config proxy thing), and pull code from gitlab.
it may happen that I connect to interactive node of cluster at the same time as regular frontend (one for editing, one for running code), or similar.
and it does happen that I need to synchronize between work desktop (vpn + ssh), cluster and laptop within a few minutes.
for me using agent forwarding simplifies things a lot. I assume all is put on the laptop ssh-agent, even when I ssh-add a key from the cluster I can leave the ssh session, then when I log back in the key is still available.
(Score: 0) by Anonymous Coward on Tuesday April 07 2020, @03:48PM
I'll show my ignorance and admit I am not familiar with GitLab yet.
Can you try using ProxyJump instead? That can be set in ~/.ssh/config
Here you would write 'ssh cluster' to hop through the front end and reach the cluster:
Host cluster
Hostname cluster.gitlab.com
IdentitiesOnly yes
IdentityFile whatever
AddKeysToAgent yes
ProxyJump account@frontend.gitlab.com
If you can leave a connection to the frontend open and use it for repeated passthroughs to the cluster, then you can make it into a master connection and multiplex subsequent connections over it. That will save a little time if you are constantly rebuilding connections.