Getting started with SSH security and configuration

A hands-on guide

Are you a new UNIX administrator who needs to be able to run communication over a network in the most secure fashion possible? Brush up on the basics, learn the intricate details of SSH, and delve into the advanced capabilities of SSH to automate securely your daily system maintenance, remote system management, and use within advanced scripts to manage multiple hosts.

09 May 2014 - Correction: Listing 2 illustrates copying the public key of the key pair. Changed 'private key' to 'public key.'

Share:

Roger Hill (unixman@charter.net), Independent author

Roger Hill has worked as a UNIX®/Linux® systems engineer and programmer/developer in large, complex hybrid environments for the past 23 years. His specialization for the past seven years has been on intercommunications between various UNIX, Linux, and Windows® platforms and creating seamless and secure automation for such systems. Roger holds an Associate's Degree in Computer Information Systems, a Bachelor's Degree in Computer Science, and a Chancellor's Certificate in Linux Administration and maintains nine professional technical certifications.



09 May 2014 (First published 01 February 2011)

Also available in Chinese Russian

What is SSH? A basic description

Secure Shell (SSH) was intended and designed to afford the greatest protection when remotely accessing another host over the network. It encrypts the network exchange by providing better authentication facilities as well as features such as Secure Copy (SCP), Secure File Transfer Protocol (SFTP), X session forwarding, and port forwarding to increase the security of other insecure protocols. Various types of encryption are available, ranging from 512-bit encryption to as high as 32768 bits, inclusive of ciphers, like Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES), and ARCFOUR. Higher-bit encryption configurations come at a cost of greater network bandwidth use. Figure 1 and Figure 2 show how easily a telnet session can be casually viewed by anyone on the network using a network-sniffing application such as Wireshark.

Figure 1. Telnet protocol sessions are unencrypted.
Illustration displaying how telnet protocol sessions are unencrypted

Frequently used acronyms

  • API: Application programming interface
  • FTP: File Transfer Protocol
  • IETF: Internet Engineering Task Force
  • POSIX: Portable Operating System Interface for UNIX
  • RFC: Request for Comments
  • VPN: Virtual private network

When using an unsecured, "clear text" protocol such as telnet, anyone on the network can pilfer your passwords and other sensitive information. Figure 1 shows user fsmythe logging in to a remote host through a telnet connection. He enters his user name fsmythe and password r@m$20!0, which are both then viewable by any other user on the same network as our hapless and unsuspecting telnet user.

Figure 2. SSH protocol sessions are encrypted.
Illustration showing how 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
SSH protocol logical layers

The transport layer is responsible for key exchange and server authentication. It sets up encryption, integrity verification, and (optionally) compression and exposes to the upper layer an API for sending and receiving plain text packets. A user authentication layer provides authentication for clients as well as several authentication methods. Common authentication methods include password, public key, keyboard-interactive, GSSAPI, SecureID, and PAM.

The connection layer defines channels, global requests, and the channel requests through which SSH services are provided. A single SSH connection can host multiple channels concurrently, each transferring data in both directions. Channel requests relay information such as the exit code of a server-side process. The SSH client initiates a request to forward a server-side port.

This open architecture design provides extensive flexibility. The transport layer is comparable to Transport Layer Security (TLS), and you can employ custom authentication methods to extend the user authentication layer. Through the connection layer, you can multiplex secondary sessions into a single SSH connection (see Figure 4).

Figure 4. SSH within the Seven-layer OSI Model
SSH within the Seven-layer OSI Model

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:

# RSAAuthentication yes		
# PubkeyAuthentication yes		
# RhostsRSAAuthentication no
# HostbasedAuthentication no
# RhostsRSAAuthentication and HostbasedAuthentication
PasswordAuthentication yes
ChallengeResponseAuthentication no
# KerberosAuthentication no
GSSAPIAuthentication yes

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:

# vi /etc/ssh/sshd_config
AllowedAuthentications publickey, password
RequiredAuthentications publickey, password

Private and public key pairs for SSH

To help validate identities, SSH has a key management capacity and related agents. When configured with public key authentication, your key proves your identity to remote SSH hosts. An SSH-based identity consists of two parts: a public key and a private key. The private SSH key is the user's identity for outbound SSH connections and should be kept confidential. When a user initiates an SSH or SCP session to a remote host or server, he or she is said to be the SSH client. Through a mathematical algorithm, a private key is like your electronic identification card; the public key is like the lock or gate mechanism that you present your ID card to. Your private key says, "This really is Fred Smythe"; the public key says, "Yes, you are indeed the real Fred Smythe; you are now authenticated: Please enter."

Your public key represents who you will allow inbound access to through your gate or lock. Public keys need not be kept secret; they cannot be used to compromise a system or for unwarranted access into a system. On a Linux or UNIX system, these private and public key pairs are stored in ASCII text files; on Windows systems, some programs store the key pairs as text files, some in the Windows registry.

Multiple identifications using multiple private keys can be created with an SSH Protocol 2 configuration. Let's look at how to generate, set up, and configure an SSH private and public key pair on typical Linux hosts (see Figure 5).

Figure 5. Diagram of the SSH private-public key pair transactions, as defined within the SSH defined architecture model
SSH private-public key pair transactions

Steps for configuring public and private SSH key pairs

The example shown in step 1 (see Listing 1) uses the ssh-keygen utility for user fsmythe to create the SSH private-public key pair with the type of dsa.

Listing 1. Generate the SSH key pair
[fsmythe@example.com ~]$ /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): ******    (Enter 'mypassword')
Enter same passphrase again: ******	(Enter 'mypassword')
Your identification has been saved in /home/fsmythe/.ssh/id_dsa.
Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub.
The key fingerprint is:
33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 fsmythe@example.com
[fsmythe@example.com ~]$

The example shown in step 2 (Listing 2) illustrates copying the public key of the key pair from the source to the destination host's authorized_keys file within the .ssh subdirectory under the home directory of the desired user account on the destination host.

Listing 2. Copy the public key from the source host to the authorized_keys file on the destination host
[fsmythe@example.com ~]$ scp -p /home/fsmythe/.ssh/id_dsa.pub 
fsmythe@thor01.com:/home/fsmythe/.ssh/authorized_keys
fsmythe@ thor01.com's password:
id_dsa.pub       100%  	624   	0.6KB/s    	00:00

The example shown for step 3 (see Listing 3) makes the first-time remote SSH call (ls -d /tmp) to the destination server, thereby caching the key within your server's .ssh/known_hosts file. You enter the same passphrase with which you created the SSH private-public key pair, and the output of the command run on the remote destination server is seen locally back on your source server.

Listing 3. Verify the SSH access by running a remote command on the target remote host
[fsmythe@example.com ~]$ ssh root@thor01.com ls -d /tmp
The authenticity of host 'thor01.com (10.12.53.118)' can't be established.
RSA key fingerprint is 84:4f:e5:99:0b:7d:54:d0:1b:3e:2b:96:02:34:41:25.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'thor01.com,10.12.53.118' (RSA) to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_dsa': ******  (Enter 'mypassword') 
/tmp
file1.txt
file2.txt
dir3_5432

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:

[root@example01.com ~]# ssh root@example02.com
Enter passphrase for key '/root/.ssh/id_dsa':******	(User must type password)
Last login: Sat May  8 06:37:26 2010 from 10.12.53.118

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

[root@example01.com ~]# ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1849; export SSH_AGENT_PID;
echo Agent pid 1849;

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

[root@example01 ~]# SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845;export SSH_AUTH_SOCK
SSH_AGENT_PID=1849; export SSH_AGENT_PID;echo Agent pid 1849
Agent pid 1849

Then, verify that the ssh-agent is running:

[root@example01.com ~]# ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
root      1849     1  0 06:14 ?        00:00:00 ssh-agent -s

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

[root@example01.com ~]# ssh-add -l
The agent has no identities.

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

[root@example01.com ~]# ssh-add
Enter passphrase for /root/.ssh/id_dsa:
Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa)	****** (Entered 'mypassword')

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

[root@example01.com ~]# ssh-add -l
1024 33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 /root/.ssh/id_dsa (DSA)

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

# Assuming target remote host has correct authorized key for private key from example01
[root@example01.com ~]# ssh -A root@example02.com	
Last login: Sat May  8 06:36:27 2010 from 10.12.53.118
[root@example02 ~]#

# Assuming target remote host has correct authorized key for private key from example03
[root@example01.com ~]# ssh -A root@example03.com		
Last login: Sat May  8 07:04:05 2010 from 10.12.53.119
[root@example03 ~]#

When you enter the passphrase using the ssh-add command, you are actually decrypting the private key and then placing it in memory through the agent for any future SSH connections with that particular passphrase. Note that you can enter multiple private keys and pre-authenticate them with the ssh-add command.

The SSH tool ssh-keyscan, shown in Listing 4, allows you to gather the public SSH host keys from multiple remote SSH hosts. The tool is helpful in building of the /etc/ssh_known_hosts files and is exceptionally fast and efficient. It is primarily suited to shell scripts for automation purposes.

Listing 4. Example using ssh-keyscan
[root@example01 ~]# /usr/bin/ssh-keyscan -t rsa,dsa example02.com
# example02.comSSH-2.0-OpenSSH_4.3
example02.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example03.comSSH-2.0-OpenSSH_4.3
example03.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==
# example04.comSSH-2.0-OpenSSH_4.3
example04.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example05.comSSH-2.0-OpenSSH_4.3
example05.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==

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:

$ ssh fsmythe@example.com /usr/local/bin/dangerous_script.pl

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):

#!/usr/local/bin/expect
spawn sftp $argv
expect "password:"
send "mysshpassowrd\r"

Granting a password-less SSH mechanism for remote host access to typical users is justification enough for a lynching in the eyes of some systems administrators. However, alternative security measures to justify the password-less SSH mechanism for remote host access, such as a user on the remote host machine only given a restricted korn shell (rksh) account or restricted shell (rssh) instead of a full bash or Bourne shell account. It is also possible on an authorized key to restrict a user to a subset of commands in a list so that in effect, the user can only use the exact commands required to run remotely without the possibility for further access or an accidental command run that could damage the system. The SSH restriction example provided in Listing 5 provides such a restriction type.

Listing 5. Example of configuration restricting the authorized_keys file on remote host
[fsmythe@example02 .ssh]$ more authorized_keys
command="/usr/local/bin/secureScript.sh",no-port-forwarding,no-X11-forwarding,no-agent-fo
rwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5+MYTu5XfRESPLVwQ
A7HlUxhsXsxgmb1L1RgvR/g0JZnipDS+fGOrN2/IerSpgyzegTVxYLPrOovvuyCn5TA0+rmyrkV27so6yRDkdqTJc
YzWNJOyDndnTrDc/LNmqLFKoGMQ33aur6RNv4VAAAAFQD4leC5Fc1VJqjvXCNsvazBhi84vQAAAIAWbshT80cTESg
dX/srxX4KVNAzY1uhBz5V0UYR4FGP+aoe6laxRj+gQvFIvAKIrpikvBjgyW6cdT8+k0t8HGIQp20MzSBdY9sH8xdj
05AG97Nb/L8xzkceB78qfXhV6txaM1CzssUtiOtaAygrywNPBDEN9MbEbwpVVVyd6iqZNgAAAIAmV0SUZoUr8dHdC
tagRye4bGOQjoztpb4C0RbXQw+w7Jpzr6cZISdZsK4DTBjODvv2+/OWPm7NEzzWyLzHPBNul8hAHOUCOpp+mYWbXX
F78BTk2Ess0SZu8dwpOtasTNEp+xPcsOvQx2Kdr17gTp+28SfpREuLudOr6R3KeTb+hw== fsmythe@example01

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


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:

/etc/hosts.equiv
~/.rhosts

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:

/etc/shosts.equiv
~/.shosts

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

PermitEmptyPasswords yes
AllowSHosts remoteclient.com
DenySHosts

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

+remoteclient.com fsmythe
+secureserver.net sallyh
+192.168.100.12 fsmythe
-hackers.org james

you would allow user fsmythe trusted host authentication from the remote sources remoteclient.com, 192.168.100.12, and secureserver.net and user sallyh access from secureserver.net, denying access from user james at the remote source hackers.org.

The trusted-host authentication and public-private SSH key pair authentication methods are similar and to a greater end achieve the same results. Table 1 provides a side-by-side comparison of the two authentication methods.

Table 1. Comparison of private-public SSH key pairs with trusted-host configuration
SSH aspectTrusted hostPrivate-public key pair
Authenticate by IP addressYesYes
Authenticate by host nameYesYes
Use other public key featuresNoYes
Authenticate by remote user nameYesNo
Allow wildcards in host names and IP addressesNoYes
Passphrase is necessary for login accessNoNo
Breaks on IP address or host name changeSometimesYes
Configuration required on the server and clientNoYes
Useful for automated tasks or scripting needsYesYes

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 no within /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.


Downloads

DescriptionNameSize
Putty Windows SSH client installerputty-0.60-installer.exe1.7MB
FileZilla Windows SSH installerFileZilla_3.3.2.1_win32-setup.exe4.0MB
Tera Term Windows SSH installerteraterm-4.65.exe7.5MB
WinSCP installation packagewinscp427setup.exe2.9MB
Cygwin Universal DownloaderSoftonicDownloader11694.exe251KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=620350
ArticleTitle=Getting started with SSH security and configuration
publish-date=05092014