Secure Shell (SSH) was developed to overcome the security concerns of earlier remote access programs like Telnet and rlogin. These programs had several security weaknesses, including the sending of clear text passwords; unencrypted payload that allowed user data to be seen; and lack of modularity to support advanced security methods, such as two-factor authentication, public key support and support of protocols beyond remote access.
SSH is implemented on Linux and most versions of Unix using OpenSSH, which is supported by the OpenBSD project. In addition to SSH, OpenBSD offers programs that allow users to easily copy data to systems using SSH's secure copy (SCP) and secure file transfer protocol (SFTP).
The SSH protocol is secure enough to use across nonsecure private and public Internets. For example, SSH could be used to connect to a remote partner's Unix system across a leased T1 connection or to connect across the public Internet when a private connection is not available.
In this tip, I will cover the basic uses of SSH and the more advanced topic of tunneling traffic through an SSH session.
In its simple form SSH can be use to connect remotely to a system. Basically the program opens a session and then provides a login and shell as specified for the user in
To open a remote shell, simply execute SSH with the remote server's name or IP address:
~$ SSH 192.168.1.3
If the user has not previously opened a session to the host, then a warning will be displayed stating that the remote host is unkown:
The authenticity of host '192.168.1.3 (192.168.1.3)' can't be established. RSA key fingerprint is d2:af:9e:c7:52:97:d2:55:e8:3e:83:a4:eb:98:a1:b6. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.3' (RSA) to the list of known hosts.
If the warning states that the key does not match, then you need to determined if the key has been compromised, or if the remote host has had activity that would change the key (e.g., new OS install, removal or regeneration of the key). Once the session is established, then the normal programs the user requires can be executed remotely on the host as if the user was local to the system with a shell account.
By default, SSH passes the local user's account name to the remote host. But, if the user's ID does not match the local user ID, then the -l parameter can be provided to the SSH command:
SSH -l rmccarty 192.168.1.3
SSH provides a powerful function to not only encrypt the interactive traffic used in remote logging, but it also provides tunneling features to allow other traffic to be sent through the tunnel as well. The traffic is directed appropriately to either the remote server or to some other device on the remote network.
SSH local to remote tunnels: A basic example of this is when a remote user has SSH access to a central site, but also needs secure access to an intranet Web server at the remote site. An unsecure method of providing the access would be to present the intranet site to the internet; however, a safer solution is to SSH to the host and redirect traffic through the remote SSH gateway to the Web server.
Assuming the remote SSH server is 192.168.1.3 and the remote web server is 192.168.1.4 with the web server running on port 80, then an SSH tunnel can be established with:
SSH -L 80:192.168.1.4:80 192.168.1.3
The -L tells the local SSH client to bind port 80 on the local host (the first 80: in the parameter) to the remote host 192.168.1.4 (the Web server) on port 80, through the SSH gateway at 192.168.1.3. The user can then open a browser on the local system with http://localhost:80 and see the Web content served up from the remote Web server. (You can also use the local system's IP address instead of localhost if you wish.)
Port 80 is a privileged port (i.e., less than 1024) and under root's control, so often a high local port will need to be established. For example, let's use 8080 with the same example:
SSH -L 8080:192.168.1.4:80 192.168.1.3
Now the user can connect to the remote Web site with http://localhost:8080 and correctly connect to port 80 on the Web server. By providing local to remote tunneling of traffic, SSH provides an easy way to access remote services. This solution is ideal when the remote site is initiating the session and needs to access remote resources. But, solution doesn't work when the remote site needs to make a connection and provide access to local services through the session. This remote to local tunneling is provided similarly to the local to remote with the -R paramater.
SSH remote to local tunneling: For this example, let's assume the local site needs to kick off a batch process, and then provide FTP services during a time, to allow the remote site to download files from the local site. Keep in mind that the same rules apply concerning ports: port under 1024 will need to be opened by root.
The tunnel can be initiated with:
SSH -R 23:192.168.1.3:23 192.168.1.3
This means that the remote SSH gateway will open a socket on its own port 23 (from the parameter 192.168.1.3:23) and forward any traffic that it received on the port back through the tunnel to port 23. Once the tunnel is established, users at the remote site can then ftp to 192.168.1.3 as if it was running an FTP server.
Optimizing traffic across SSH tunnels
SSH provides several useful options for optimizing traffic trough the tunnel. These options can be useful both across the Internet and private networks.
Compression: By compressing traffic in real time, SSH allows transactions to be completed quicker. Generally it will speed things up on interactive traffic such as running a shell command through the tunnel, and with data that lends itself to compression (e.g., documents containing large amounts of text). But, compression does have overhead, and often brings no use on high-speed lines as the compression is offset by the overhead. The parameter to enable compress is -C.
Non-interactive: If a remote login is not needed during the encryption session, then remote commands can be disabled. This is useful for simple port forwarding or batch processing. The parameter to not execute the remote shell for interaction is -N.
SSH also provides some commands to allow direct interaction across a secure tunnel for basic file interaction. This enables batch transfers to be optimized with a single command versus executing the SSH tunnel and another command (e.g., FTP) to push a file across the line. SCP and SFTP can be used instead of native OS commands RCP and FTP.
Taking advantage of SSH on your Linux network
SSH provides a secure method of encrypting data across private and public networks. SSH avoids earlier implementation weaknesses of not encrypting passwords and sending data in the open. Beyond these basic security features, SSH also provides secure tunnels. Try out these examples, and add SSH to your secure computing toolbox.
ABOUT THE AUTHOR: Ronald McCarty is a freelance writer and consultant specializing in systems, network, and information security. He received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany and his master's degree in Management with a specialization in information technology at Capella University. Ron's company, Your Net Guard offers IT consulting and integration services in the Dallas/Forth Worth area. He can be reached at firstname.lastname@example.org.