![]() ![]() In later versions of SSH, you can avoid using netcat (which is handy as it might not be installed on your jump host) and instead use the equivalent flag -W in the inner command: $ ssh -i ~/.ssh/server_id_rsa -oProx圜ommand="ssh -i ~/.ssh/jump_id_rsa jump-host -W myserver" myserverĪnd you can use “special string substitutions” inside the inner comand to avoid repeating the final host and port: $ ssh -i ~/.ssh/server_id_rsa -oProx圜ommand="ssh -i ~/.ssh/jump_id_rsa jump-host -W %h:%p" myserver You will need to provide authentication in the form of private key or password to both commands as in the example. The combination of the two allows you to obtain a shell directly into the server, using the jump host as a proxy. That will be the stdin and stdout of the netcat process we started on the jump host, which will be routed directly to the server. However, instead of connecting the usual way, the -oProx圜ommand flag tells it that when it tries to establish a connection to server it should do so using the stdin/stdout of the “inner” command as a transport. The “outer” SSH (outside the double quotes), which connects to the server.Once connected, it starts a netcat ( nc) process on the jump host which carries all its stdin to the server, and all the stdout back. The “inner” SSH command passed to the -oProx圜ommand option (within the double quotes) connects to the jump host.It is essentially structured into two SSH commands, connected by the -oProx圜ommand directive: It is worth to doing things the “old fashioned” way first in order understand all of the underlying components. This command looks very long and convoluted. The SSH client connects the jump host first, then executes a Prox圜ommand which forwards the standard input and output to the remote server: $ ssh -i ~/.ssh/server_id_rsa -oProx圜ommand="ssh -i ~/.ssh/jump_id_rsa jump-host nc myserver" myserver Unlike agent forwarding and intermediate key value pair this method is not going to store or otherwise expose our keys on the bastion. $ SSH_AUTH_SOCK=/tmp/ssh-JVEaf5qUm5O1/agent.57796 why it’s very important to only forward our SSH agent only to servers that we fully trust. Therefore, any other user gaining access to the jump host as root could simply set own their $SSH_AUTH_SOCK to point to our socket, and use our ssh-agentas their own. However, the root user has access to everything. Usually the socket file on the jump host is stored in /tmp and only the user who owns the SSH session can use it. That way when the SSH client on the jump host wants to connect to the agent, it will be unknowingly communicating with the agent on our local machine instead of its own. That socket is made to actually point back over the network to the one in our local machine (the communication is routed through a secondary channel). When SSH connects with the agent forwarding option -A enabled, it tells the SSH daemon on the jump host to set its own $SSH_AUTH_SOCK variable to a newly created socket. As was mentioned, SSH knows where to find the agent socket by looking at the variable $SSH_AUTH_SOCK. The ssh-agent is a process which stores our keys unencrypted in memory and communicates through a Unix socket (see the section on the agent to understand why). Then we can add our private key to our local agent like this: $ ssh-add ~/.ssh/key_name_id_rsaĪnd forward it when connecting to the jump host: $ ssh -A within the jump host, we should be able to keep using any key previously added to our agent, so we are able to SSH normally into the final remote server: $ ssh How could it be insecure? To set up a simple authentication based on ssh-agent forwarding we might want to install our public key both on the jump host’s and on the remote server’s authorized_keys file like in the picture. This way we can re-use our private keys but without storing any of them on the jump host. This allows us to re-use our agent from there (and all the keys we added to it) as if we were on our own machine. With the special flag to the ssh command -A we are able to “forward” the local ssh-agent containing our keys to the jump host. A slightly better, but still potentially dangerous solution involves the helper command we saw in the previous section: ssh-agent. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |