The Secure Shell (SSH) protocol is often used for remote management because it provides encrypted connections between a client and a remote device and enables an encrypted bidirectional communication path between two systems. For decades developers have relied on the SSH protocol to establish secure command-line sessions with Linux®/UNIX environments and networking devices. And with the proliferation of Internet of Things (IoT) devices, setting up SSH to enable a secure login is more useful than ever.
SSH is a protocol used in client/server applications. The server runs an SSH server or daemon and the SSH client is installed by default on most UNIX and Mac systems and recent versions of Windows as well. There are other free and commercial versions available that provide additional features, like individually configuring and saving frequent connections. PuTTY is a popular free SSH client and VanDyke Software's SecureCRT is a popular commercial client.
You can use SSH for several activities that require a secure, remote connection to another device, such as:
You can copy files over SSH using the Secure Copy Protocol (SCP) or Secure File Transfer Protocol (SFTP). Both copy files over TCP 22 but use different protocols. SSH handles the authentication and encryption. SFTP is an extension of the SSH protocol and requires an additional SFTP server on the server-side. SFTP includes a more robust command set like listing remote directories and removing files, which SCP cannot do.
SSH also supports several other features like the ability to encapsulate other network traffic over an established SSH tunnel. For example, after you create an SSH tunnel, you could instruct a different app, like a web browser, to connect to your local host on a specific port. The system will then send subsequent network calls to a destination server. This allows remote connections to a network without exposing that service on the internet.
SSH provides authentication and encryption functions that enable you to configure your system to meet your security requirements. By default, SSH is configured for username and password authentication, but you can add public key authentication and additional multi-factor authentication (MFA) provided through other modules (like OATH-TOTP). Multi-factor authentication proves more resilient against phishing attacks than a password alone because MFA requires at least one other factor beyond a password to confirm an identity.
SSH server configurations can be made on the command line, per user, or system-wide through a file called SSH_config, which is typically located in /etc/SSH/SSHd_config.
Configuring SSH for username and password authentication is easiest. By default, on many devices, you only need to create a user account on the server, assign a password, ensure the SSH server daemon is installed and listening, and you are ready to go.
On a client computer, log on to the server remotely using the command:
When you first log on to a new device, you will be presented with an alert that the authenticity of the server or device that you are connecting to cannot be verified. This is normal and an excellent security measure. The SSH client will show you the host key that was presented by the server. To ensure that the server you are connecting to is the actual server you intended to connect to (and not a spoof or man-in-the-middle), you should confirm its identity. On the server, use this command to output the server’s identity public key:
ssh-keygen -l -f <filename of the key located on the host (often in /etc/SSH)>
ssh-keygen -l -f ssh_host_ecdsa_key.pub
Then, compare this command’s output with the hash the SSH client presented you. You only need to do this once. The SSH client will save this entry in a list of all known hosts that you previously logged onto in the file ~/.SSH/known_hosts and will only alert you if a mismatch is detected.
Setting up certificates for authentication is a bit more complicated, but many internet sites detail the required steps. For example, a very good walkthrough is available on https://ssh.com. These sites show the specifics for installing and configuring SSH and certificates for different Linux distributions. The keys generated are actual credentials and just as important as a username and password and should be handled carefully and well protected. These certificates will allow access to your devices.
In general, the steps include:
This completes the process in the simplest form. Now when you log into that remote device, it will use your certificate to authenticate you.
SSH also lets you specify which encryption cipher to use. Not all ciphers are equal and some you should avoid. Most modern Linux distributions default to acceptable encryption ciphers but older devices may not support these. To limit downgrading to remove ciphers that you don't want, edit the file sshd_config and specify the ciphers you wish to support. If your server or device supports a later version of OpenSSH, you can run the following command to invoke extended test mode, which will list many configuration options including what crypto algorithms are enabled:
Refer to the OpenSSH website for current guidance on the best symmetric, host key, key exchange, and message authentication code algorithms to use. The National Institute of Standards and Technology (NIST) also offers recommendations of what encryption ciphers to avoid due to inadequate key length or the algorithms themselves.
SSH is a very powerful and useful tool to connect to a myriad of devices. IoT devices that allow interactive login will support SSH, and you should be wary of using those that do not on untrusted networks.
Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop.
Privacy Centre |
Terms and Conditions
Copyright ©2023 Mouser Electronics, Inc.
Mouser® and Mouser Electronics® are trademarks of Mouser Electronics, Inc. in the U.S. and/or other countries.
All other trademarks are the property of their respective owners.
Corporate headquarters and logistics centre in Mansfield, Texas USA.