Croatia - Flag Croatia

All prices include duty and customs fees on select shipping methods.

Please confirm your currency selection:

Free shipping on most orders over 50 € (EUR)
All payment options available

US Dollars
Free shipping on most orders over $60 (USD)
All payment options available

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

SSH Part 1: Configuring SSH to Securely Connect to Remote Devices Jeff Fellinge

Digital lock guard sign binary code number.

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.

Using SSH in Client/Server Applications

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:

  • Secure file copy between a client and server
  • Redirect network protocols over a secure tunnel
  • Interactive command-line utility for remote management

Using SSH to Securely Copy Files

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.

Redirecting Network Traffic over an SSH Tunnel for Secure Remote Management

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.

Using SSH’s Interactive Commands to Meet Your Remote Management Security Needs

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:
ssh username@remotehost

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

For example:

ssh-keygen -l -f

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

  1. Generate a key pair that includes an authorized key and identity key by running the command ssh-keygen. By default, ssh-keygen will create a new identity (private) and authorized (public) SSH Protocol 2 RSA key pair into the ~/.ssh directory. If you choose to enter a passphrase when creating your SSH keys, then you will be required to reenter this passphrase when attempting to use the key to log into the remote computer. Reentering the passphrase is a good security measure since the passphrase encrypts your private key and prevents an attacker from using it.

    From a command line on the client computer, run:
  2. Copy the authorized key from the client computer to the server. Using the ssh defaults, this key has a .pub extension and is located alongside the identity key in the user's .ssh directory. After you run ssh-keygen to generate the ssh keys, run this on the client computer:

    ssh-copy-id username@remotehost

    This tool will look for the keys on your client computer and will log into the remote computer you specified and copy the keys into (a new) file, located at ~/.ssh/authorized_keys.

This completes the process in the simplest form. Now when you log into that remote device, it will use your certificate to authenticate you.

Specifying Which Encryption Cipher to Use

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:

sshd -T

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.

Key Points:

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.

  • The SSH standard includes tools that enable secure, remote administration of IoT devices and cloud infrastructure.
  • SSH provides modern encryption and authentication controls, including multi-factor authentication using password-protected certificates.
  • The OpenSSH suite of utilities provides all the tools you need to use SSH to remotely administer your Linux systems and network equipment.

« Back

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. 

All Authors

Show More Show More
View Blogs by Date