SSH security and configuration

Figure 2. SSH protocol sessions are encrypted.

Figure 2 provides an overview of a typical SSH session and shows how the encrypted protocol cannot be viewed by any other user on the same network segment. Every major Linux® and UNIX® distribution now comes with a version of the SSH packages installed by default—typically, the open source OpenSSH packages—so there is little need to download and compile from source. If you're not on a Linux or UNIX platform, a plethora of open source and freeware SSH-based tools are available that enjoy a large following for support and practice, such as WinSCP, Putty, FileZilla, TTSSH, and Cygwin (POSIX software installed on top the Windows® operating system). These tools offer a UNIX- or Linux-like shell interface on a Windows platform.

Whatever your operating system, SSH touts many positive benefits for commonplace, everyday computing. Not only is it dependable, secure, and flexible, but it is also simple to install, use, and configure—not to mention feature laden.

SSH architecture

IETF RFCs 4251 through 4256 define SSH as the "Secure Shell Protocol for remote login and other secure network services over an insecure network." The shell consists of three main elements (see Figure 3):

• Transport Layer Protocol: This protocol accommodates server authentication, privacy, and integrity with perfect forward privacy. This layer can provide optional compression and is run over a TCP/IP connection but can also be used on top of any other dependable data stream.

• User Authentication Protocol: This protocol authenticates the client to the server and runs over the transport layer.

• Connection Protocol: This protocol multiplexes the encrypted tunnel to numerous logical channels, running over the User Authentication Protocol.

Figure 3. SSH protocol logical layers

Common use of SSH for UNIX and Linux systems

You typically use SSH to allow users to log in to a remote host and execute commands. However, SSH also supports tunneling and X11 connections. It can even transfer files using SFTP or SCP. SSH is applicable for numerous applications within most common platforms, including Linux, UNIX, Windows, and Apple® OS X, although some applications may require features that are only available or compatible with specific SSH clients or servers.

Here are a few common SSH syntax examples:

• Remote host shell access (supersedes telnet and rlogin clear text, insecure protocols):

  • • • • • # ssh fsmythe@example.com

          • [fsmythe@example.com] ~

• Executing a single command on a remote host (replacing rsh):

  • • • • • # ssh root@example.com reboot

          • root@example.com's password: ******

• Copying files from a local server to a remote host by way of the SCP command:

  • • • • • root@edb-01.example.com's password: ******

          • file1.txt 100% 0 0.0KB/s 00:00

          • file2.txt 100% 0 0.0KB/s 00:00

• In combination with SFTP, as a secure substitute to FTP file transfer:

  • • • • • sftp fsmythe@example.com

          • Connecting to example.com...

          • fsmythe@example.com's password: *******

          • sftp>

• In combination with rsync to back up, copy, and mirror files efficiently and securely to a local or remote host:

  • • • • • # rsync -avul --rsh=ssh /opt/edbdata/ root@example.com:/root/backup/

          • root@example.com's password: ******

          • building file list ... done

          • ./

          • file1.txt

          • file2.txt

          • file3.txt

          • file4.txt

          • dir1/file5.txt

          • dir2/file6.txt

          • sent 982813 bytes received 2116 bytes 1374860.38 bytes/sec

          • total size is 982138 speedup is 1.00

• Port forwarding or tunneling a port (not to be confused with a VPN):

  • • • • • ssh -L 8000:mailserver:110 example.com fsmythe@example.com's password: ********

• Forwarding X sessions from a remote host (possible through multiple intermediate hosts):

  • • • • • Edit /etc/ssh/sshd_config and change 2 keywords :

          • AllowTcpForwarding yes

          • X11Forwarding yes

          • # service sshd restart

          • $ export DISPLAY

          • $ ssh -X fsmythe@example.com

• With the X11 forwarding configuration in conjunction with an X Windows client with SSH X11 tunneling to allow for the implementation of a UNIX or Linux GUI subsystem run over SSH securely on the same Windows machine host that is the source for the SSH session to the Linux or UNIX remote host:

  • • • • • ssh -ND 8000 fsmythe@example.com

          • Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host" to example.com,

          • the 'Port to 8000' , Enable SOCKS v5, and lastly set 'No Proxy for' field

          • to 'localhost, 127.0.0.1'

• Securely mounting a directory on a remote server as a file system on a local computer using sshfs:

  • • • • • # yum install sshfs fuse-utils (Install sshfs and fuse-utils)

          • $sshfs example.com:/remote_dir /mnt/local_dir

• Automated remote host monitoring and management of servers through one or more mechanism:

  • • • • • (Report number of apache processes running on the remote server example.com):

          • $ ssh example.com ps -ef | grep httpd | wc -l

          • root@example.com's password: *****

SSH security and configuration best practices

With some of the previously illustrated code examples, many good systems administrators are nervous about some of the security implementations for SSH usage and functions. Although much has been said and written about the various approaches to SSH security and remote host security in general, here is a list of processes and configurations that you can use to tighten and enhance SSH security with regard to remote host access:

• Restrict the root account to console access only:

  • • • • • # vi /etc/ssh/sshd_config

          • PermitRootLogin no

• Create private-public key pairs using a strong passphrase and password protection for the private key (never generate a password-less key pair or a password-less passphrase key-less login):

  • • • • • (Use a higher bit rate for the encryption for more security)

          • ssh-keygen -t rsa -b 4096

• Configure TCP wrappers to allow only selective remote hosts and deny undesirable hosts:

  • • • • • # vi /etc/hosts.deny

          • ALL: 192.168.200.09 # IP Address of badguy

• On workstations or laptops, disable the SSH server by turning off the SSH service, and then removing the ssh server package:

  • • • • • # chkconfig sshd off

          • # yum erase openssh-server

• Restrict SSH access by controlling user access:

  • • • • • # vi /etc/ssh/sshd_config

          • AllowUsers fsmythe bnice swilson

          • DenyUsers jhacker joebadguy jripper

• Only use SSH Protocol 2:

  • • • • • # vi /etc/ssh/sshd_config

          • Protocol 2

• Don't allow Idle sessions, and configure the Idle Log Out Timeout interval:

  • • • • • # vi /etc/ssh/sshd_config

          • ClientAliveInterval 600 # (Set to 600 seconds = 10 minutes)

          • ClientAliveCountMax 0

• Disable host-based authentication:

  • • • • • # vi /etc/ssh/sshd_config

          • HostbasedAuthentication no

• Disable users' .rhosts files:

  • • • • • # vi /etc/ssh/sshd_config

          • IgnoreRhosts yes

• Configure firewalls to accept SSH connections only from know network segments:

  • • • • • Update /etc/sysconfig/iptables (Redhat specific file) to accept connection only

          • from 192.168.100.0/24 and 209.64.100.5/27, enter:

          • -A RH-FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT

          • -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state --state NEW -p tcp --dport 22 -j ACCEPT

• Restrict the available interfaces that SSH will listen on and bind to:

  • • • • • # vi /etc/ssh/sshd_config

          • ListenAddress 192.168.100.17

          • ListenAddress 209.64.100.15

• Set user policy to enforce strong passwords to protect against brute force, social engineering attempts, and dictionary attacks:

  • • • • • # < /dev/urandom tr -dc A-Za-z0-9_ | head -c8

          • oP0FNAUt[

• Confine SFTP users to their own home directories by using Chroot SSHD:

  • • • • • # vi /etc/ssh/sshd_config

          • ChrootDirectory /data01/home/%u

          • X11Forwarding no

          • AllowTcpForwarding no

• Disable empty passwords:

  • • • • • # vi /etc/ssh/sshd_config

          • PermitEmptyPasswords no

• Rate-limit the number of incoming port 2022 connections within a specified time:

  • • • • • Redhat iptables example (Update /etc/sysconfig/iptables):

          • -A INPUT -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit --limit 3/min

          • --limit-burst 3 -j ACCEPT

          • -A INPUT -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT

          • -A OUTPUT -o eth0 -p tcp --sport 2022 -m state --state ESTABLISHED -j ACCEPT

• Configure iptables to allow only three connection attempts on port 2022 within 30 seconds:

  • • • • • Redhat iptables example (Update /etc/sysconfig/iptables):

          • -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --set

          • -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update

          • --seconds 30 --hitcount 3 -j DR

• Use a log analyzer such as logcheck, loggrep, splunk, or logwatch to better understand the logs and create logging reports. Also, increase logging verbosity within the SSH application itself:

  • • • • • Installation of the logwatch package on Redhat Linux

          • # yum install logwatch

• Configure an increase in SSH logging verbosity:

  • • • • • # vi /etc/ssh/sshd_config

          • LogLevel DEBUG

• Always keep the SSH packages and required libraries up to date on patches:

  • • • • • # yum update openssh-server openssh openssh-clients -y

• Conceal the OpenSSH version, require SSH source code, and re-compile. Then, make the following updates:

  • • • • • # vi /etc/ssh/sshd_config

          • VerifyReverseMapping yes # Turn on reverse name checking

          • UsePrivilegeSeparation yes # Turn on privilege separation

          • StrictModes yes # Prevent the use of insecure home directory

          • # and key file permissions

          • AllowTcpForwarding no # Turn off , if at all possible

          • X11Forwarding no # Turn off , if at all possible

          • PasswordAuthentication no # Specifies whether password authentication is

          • # allowed. The default is yes. Users must have

          • # another authentication method available .

• Delete the rlogin and rsh binaries from the system, and replace them with a symlink to SSH:

  • • • • • # find /usr -name rsh

          • /usr/bin/rsh

          • # rm -f /usr/bin/rsh

          • # ln -s /usr/bin/ssh /usr/bin/rsh

SSH supports numerous, diverse methods and techniques for authentication that you can enable or disable. Within the /etc/ssh/sshd_config file, you make these configurations changes by entering the keyword listed for the authentication method followed by yes or no. Here are some of the common configuration changes:

The keywords AllowedAuthentications and RequiredAuthentications within the sshd_config file dictate which authentication methods and configurations are used with SSH Protocol 2 only, and the syntax for them to allow password and public key authentication is as follows:

Note: For the examples above, you didn't have to enter the user fsmythe's password. Rather, you enter the passphrase that you set in the first step. If you would rather not have to enter a passphrase when accessing the remote destination, create an empty passphrase by typing enter in step 1 when prompted for the passphrase. Now, you won't have to type anything to access the thor01.com remote target machine as the user fsmythe.

Configuring and using the ssh-agent

For the truly paranoid who refuse to create a password-less SSH public-private key pair, there's the ssh-agent utility. In a nutshell, you use the ssh-agent utility to temporarily grant password-less SSH access on a public-private key pair configuration that does have a passphrase set, but only for the current shell session. Before employing the ssh-agent utility, enter the passphrase as normal:

Next, query ssh-agent to generate Bourne shell commands on stdout:

In step 3, you set the aforementioned environmental variables in the current shell session:

Then, verify that the ssh-agent is running:

Now, list the currently loaded identities within the running ssh-agent:

In step 6, add the desired SSH identities (preauthenticating them with the correct passphrase for that SSH key):

Now, you can verify that those identities are loaded into the running ssh-agent:

Finally, test the ssh-agent with SSH command syntax. Note that now there's no passphrase prompt:

Configuring SSH with UNIX applications or scripts

Configuration of SSH access for use by remote shell scripts and remote tools for maintenance, remote backup, and archival systems has great usefulness, but it has always been at the very least a subject of high controversy when it comes to server security. Many shell scripts that a user might want to run, such as:

cannot handle a required SSH passphrase prompting him or her to authenticate but in fact will break unless a password-less private-public SSH key pair, an ssh-agent configuration, or possibly a trusted host network mechanism—something that does not prompt for an SSH password—has been configured ahead of time. This is because SSH expects the passphrase from the current terminal associated with that shell session. A user can get around this issue by using an expect script or possibly a Perl (see CPAN Module Net::SSH::Perl) script (or your shell script could alternatively call one of the aforementioned types of scripts):

User fsmythe at host example01 is only allowed to execute the command ="/usr/local/bin/secureScript.sh in this example.

Back to top

Creating a trusted host environment using SSH

Finally, I mention the trusted host environment as an alternative to setting up public-private SSH key pairs. For automation or in a scripted environment in which these types of calls are necessary, the trusted host network, though still bearing some security risks, has advantages over the public-private key pair scenario. A trusted host network or trusted host authentication relies primarily on preconfigured files that list a combination of users and hosts that are allowed access. There are two types of trusted-host authentication. The older (such as for OpenSSH and SSH1) and weaker uses the clear-text protocol commands (rsh, rcp, and rlogin); checks the two files; and sets one keyword in the sshd_config file:

SSH Protocol 2 does not support this method. Instead, for a more secure trusted host network, make the following changes in the /etc/ssh/sshd_config file (which accepts host names or IP Addresses), and configure the shosts.equiv and/or the .shosts files:

To enable a trusted-host environment in the /etc/ssh/sshd_config file for SSH Protocol 2, use:

For example, if you were on the server example.com and had configured your /etc/shosts.equiv file as follows:

To those admins who are scoffing right now at the thought of allowing a trusted host authentication system using password-less remote SSH access on their network, consider the downside of public-private key pairs when using a script for remote SSH functionality:

• If a server host name or IP address changes, the public-private key pair configuration will break because of the cached known hosts. The old entry will need to be removed in the .ssh/known_hosts file and the SSH remote host name and/or IP address re-cached again. This will break scripts dependant on the private-public key pair.

• Private-public key pair authentication requires both client and server configuration. If an SSH public key changes or the pair is regenerated, all of the remote hosts will need the new public key in their authorized_keys file.

• If the permissions of the .ssh/ folder or private or public key files themselves change, it could prevent the SSH password-less access from occurring. To disable strict file and directory permissions checking, set the keyword StrictModes to nowithin /etc/ssh/sshd_config file.

• There is no centralized way to revoke a key once a key pair has been generated or to know exactly to whom the key has been distributed.

Conclusion

SSH is a powerful and secure network utility that countless users worldwide use for numerous tasks. Offered as a safe and secure alternative to the clear-text protocols such as telnet and the r* series command and with multiple offerings of freely distributable SSH clients and servers, SSH is difficult to beat. Used widely in many networks for mass remote monitoring, system maintenance, remote system auditing, reporting, and automation within scripting technologies, it appears that SSH is here to stay and will continue to evolve.