by Roger Hill | Updated May 9, 2014 - Published February 1, 2011
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.
Frequently used acronyms
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 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.
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):
Connection Protocol: This protocol multiplexes the encrypted tunnel to numerous logical channels, running over the User Authentication Protocol.
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).
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:
#ssh firstname.lastname@example.org reboot
email@example.com's password: ∗∗∗∗∗∗
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
Connecting to example.com...
firstname.lastname@example.org's password: ∗∗∗∗∗∗∗
#rsync ‑avul ‑‑rsh=ssh /opt/edbdata/ email@example.com:/root/backup/
firstname.lastname@example.org's password: ∗∗∗∗∗∗
building file list ... done
sent 982813 bytes received 2116 bytes 1374860.38 bytes/sec
total size is 982138 speedup is 1.00
ssh ‑L 8000:mailserver:110 example.com email@example.com's password: ∗∗∗∗∗∗∗∗
Edit /etc/ssh/sshd_config and change 2 keywords :
#service sshd restart
$ export DISPLAY
$ ssh ‑X firstname.lastname@example.org
ssh ‑ND 8000 email@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'
#yum install sshfs fuse‑utils (Install sshfs and fuse‑utils)
$sshfs example.com:/remote_dir /mnt/local_dir
(Report number of apache processes running on the remote server example.com):
$ ssh example.com ps ‑ef | grep httpd | wc ‑l
firstname.lastname@example.org's password: ∗∗∗∗∗
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:
(Use a higher bit rate for the encryption for more security)
ssh‑keygen ‑t rsa ‑b 4096
ALL: 192.168.200.09 #IP Address of badguy
#chkconfig sshd off
#yum erase openssh‑server
AllowUsers fsmythe bnice swilson
DenyUsers jhacker joebadguy jripper
ClientAliveInterval 600 #(Set to 600 seconds = 10 minutes)
Update /etc/sysconfig/iptables (Redhat specific file) to accept connection only
from 192.168.100.0/24 and 18.104.22.168/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 22.214.171.124/27 ‑m state ‑‑state NEW ‑p tcp ‑‑dport 22 ‑j ACCEPT
#< /dev/urandom tr ‑dc A‑Za‑z0‑9_ | head ‑c8
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
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
Installation of the logwatch package on Redhat Linux
#yum install logwatch
#yum update openssh‑server openssh openssh‑clients ‑y
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 .
#find /usr ‑name 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:
#RhostsRSAAuthentication and HostbasedAuthentication
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:
AllowedAuthentications publickey, password
RequiredAuthentications publickey, password
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).
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.
[email@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:
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.
[firstname.lastname@example.org ~]$ scp ‑p /home/fsmythe/.ssh/id_dsa.pub
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.
ls -d /tmp
[email@example.com ~]$ ssh firstname.lastname@example.org 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')
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.
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:
email@example.com ~ssh firstname.lastname@example.org
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:
email@example.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:
firstname.lastname@example.org ~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:
email@example.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):
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:
firstname.lastname@example.org ~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
email@example.com ~ssh ‑A firstname.lastname@example.org
Last login: Sat May 8 06:36:27 2010 from 10.12.53.118
#Assuming target remote host has correct authorized key for private key from example03
email@example.com ~ssh ‑A firstname.lastname@example.org
Last login: Sat May 8 07:04:05 2010 from 10.12.53.119
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.
root@example01 ~/usr/bin/ssh‑keyscan ‑t rsa,dsa example02.com
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 email@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):
CPAN Module Net::SSH::Perl
spawn sftp $argv
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.
[fsmythe@example02 .ssh]$ more authorized_keys
rwarding,no‑pty ssh‑dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5+MYTu5XfRESPLVwQ
User fsmythe at host example01 is only allowed to execute the command ="/usr/local/bin/secureScript.sh in this example.
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:
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.
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:
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.
January 28, 2019
Get the Code »
Apache SparkArtificial intelligence+
May 14, 2019
IBM Cloud PrivateIBM LinuxONE+
Back to top