Use SSH to Cross a Suspect Host Securely
An authentication agent holds authentication credentials and allows other processes to use it for authenticating with SSH servers. It can be used for an X session allowing various commands and shells to authenticate automagically when logging in to remote services.
Authentication agents also can pass credentials on to remote servers allowing the remote shell to use it. The following command will connect to hostB and forward the authentication agent connection if you have one established:
ssh -A hostB
If hostC allows authentication with the same key, you then can ssh from hostB to hostC without having to authenticate manually.
A couple risks are involved in this type of authentication agent forwarding. In the example in the article, the risk is that if you forward the authentication agent connection to Gateway from Netbook, the attacker also could gain access to that authentication agent connection. If Server accepts the same key, the attacker could use your authentication agent connection to establish a connection to Server.
Another issue is that the authentication agent will forward all keys that it has. If you use one key for customerA and another key for customerB, you don't want the agent to forward the key for customerA to customerB's machine.
Figure 1 displays the example graphically. The initial ssh command builds the SSH connection for the tunnel, the tunneled connection and the forwarded connection. The second ssh command initiates a new connection through the tunnel and forwards the connection directly to the machine you are trying to reach. The forwarded connection is in red to show that it is unencrypted, but the blue SSH connection going through it is secure.
This tunnel could work for any TCP protocol, but the packets from Gateway to Server and back to Gateway are unencrypted. That means unencrypted services would not be secure between Gateway and Server, even though you're using an SSH tunnel. You may want to review the -L option section of the SSH man page and consider this a bit to convince yourself that the Server/Gateway connection (the red part in Figure 1) is unencrypted. Anything that isn't secure or that gets decrypted on Gateway can be read by the attacker if the attacker has root access on Gateway. The attacker also can read much of that simply by having access to your account on Gateway even without root access on Gateway.
Before connecting to the tunnel, you need to make sure you have Server's host public key registered as a key for localhost. If you tried to pull the public key out of Gateway's known_hosts file, the attacker can give you a bogus key, so you need to get the key another way.
Therefore, it's best to have Server's public key already. If you don't already have the public key, make sure to acquire it or the fingerprint for the key from a secure, trusted source. For instance, you could list the SSH key fingerprints for all of your servers on a secure Web page.
I suggest registering Server's public key in your known_hosts file under the real server name as well as under localhost. By registering under the real server name, you can figure out to which server a key belongs with the ssh-keygen command.
The following command checks your $HOME/.ssh/known_hosts file for a public key for Server. The command also reports the line number for the entry:
ssh-keygen -F Server
The entry then can be copied. By replacing the hostname portion of the copied entry with localhost, you create an entry for that key on localhost. See the Obtaining the Public Key sidebar for information on how to obtain a server's public key securely.
Obtaining the Public Key
The public key for a host is usually in either /etc/ssh/ssh_host_rsa_key.pub or /etc/ssh/ssh_host_dsa_key.pub, depending on the type of key the host uses. You also can get the public key out of the known_hosts file of a computer you can trust. For instance, if you normally connect to the server from your work desktop, you could copy the entry for server out of your work desktop's known_hosts file.
Your site also might publish SSH public keys or public key fingerprints via a secure Web page or via DNS entries.
If your known_hosts file has hostnames that look like the keys, you have hashed hostnames. Use the -H option to ssh-keygen to hash your new localhost entry. The following command translates plain-text hostnames in your known_hosts file to hashed hostname entries:
Now with the tunnel set up, you can connect to SSH on Server, and because it's an SSH connection, it's encrypted:
ssh -p 3333 localhost
Again, localhost here is from Netbook's perspective, so that command connects to port 3333 on Netbook. The last SSH “tunnel” command created a tunnel from that port over to the SSH port on Server via Gateway—meaning that this command uses the tunnel to connect to Server's SSH server via port 3333 on Netbook.
Even though the tunnel passes through Gateway, it is unreadable by Gateway. Just as SSH connections normally travel across untrustable routers, yet are secure, the connection through Gateway to Server is secure. The SSH connection via the tunnel is never unencrypted on Gateway, so the attacker can't compromise it. But again, remember to have verified the host key for Server already, or the attacker can compromise the connection with a man-in-the-middle attack.
With the connection to Server, you now could set up a SOCKS proxy to allow applications running on Netbook to be effectively on your work's network. See the SOCKS Proxy sidebar for more information.
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- Purism Librem 13 Review