Mastering SSH: Securely Connect to Your Server

Updated for Enhanced Clarity and SEO Optimization

By Justin Ellingwood and Anish Singh Walia

Introduction

Secure Shell (SSH) is an indispensable tool for anyone working with remote servers. As a system administrator or developer, mastering SSH is crucial for securely accessing and managing your servers. SSH, often referred to as Secure Socket Shell, is a cryptographic network protocol that enables you to establish a secure connection to a remote server over an unsecured network. It’s the most prevalent method for accessing Linux servers remotely, providing a secure channel for executing commands and transferring files.

This tutorial will guide you through the essentials of using SSH to connect to a remote system, ensuring you understand not just the how, but also the why behind each step. Whether you are managing web servers, databases, or any other remote services, SSH will become a cornerstone of your workflow.

Deploy your robust backend applications effortlessly from GitHub using DigitalOcean App Platform. Let DigitalOcean handle the complexities of scaling your applications, allowing you to focus on development and growth.

Understanding SSH Basics

To initiate a connection to a remote server using SSH, you’ll primarily use the ssh command. The syntax is straightforward, yet powerful.

If your operating system is Windows, you’ll first need to ensure you have OpenSSH installed to utilize the ssh command from your terminal. For those who prefer PowerShell, Microsoft provides comprehensive documentation on integrating OpenSSH. Alternatively, for a complete Linux-like environment on Windows, consider setting up WSL (Windows Subsystem for Linux), which includes SSH by default. A lighter option is to install Git for Windows, which provides a Bash terminal environment for Windows that includes the ssh command. Each option is well-supported, and your choice will depend on your preferred working environment.

For macOS and Linux users, the ssh command is readily available in your terminal right out of the box.

Basic SSH Command

The most fundamental form of the SSH command is as follows:

ssh <mark>remote_host</mark>

Here, <mark>remote_host</mark> refers to the IP address or the domain name of the server you intend to connect to.

This command assumes that your username on your local machine is the same as your username on the remote server. If your username on the remote server differs, you need to specify it in the command:

ssh <mark>remote_username@remote_host</mark>

Upon establishing a connection, you might be prompted for a password to verify your identity. We will later explore how to set up SSH keys for passwordless authentication, which is both more secure and convenient.

Exiting an SSH Session

To terminate your SSH session and return to your local terminal, simply type:

exit

How SSH Works: The Technical Details

SSH operates on a client-server architecture. It involves an SSH client program connecting to an SSH server, known as sshd.

In the commands we used earlier, ssh is the client program. The sshd server is expected to be running on the <mark>remote_host</mark> you specified.

In almost all Linux distributions, the sshd server is configured to start automatically upon system boot. However, if it’s not running, possibly due to configuration changes or errors, you might need to access your server through a web-based console or a local serial console to diagnose and resolve the issue.

The exact procedure to start the SSH server varies based on your Linux distribution.

For Ubuntu-based systems, you can start the SSH server by executing:

sudo systemctl start ssh

This command should initiate the sshd server, enabling you to log in remotely.

Configuring Your SSH Server for Security and Customization

Modifying the SSH configuration involves adjusting the settings of the sshd server. These configurations dictate how the server behaves, especially regarding security and access policies.

On Ubuntu, the primary configuration file for sshd is located at /etc/ssh/sshd_config.

Before making any changes, it’s best practice to back up the original configuration file:

sudo cp /etc/ssh/sshd_config{,.bak}

This command creates a backup of your configuration file, named sshd_config.bak, in the same directory. If anything goes wrong, you can easily revert to the original settings.

To edit the configuration, open the file using nano or your preferred text editor:

sudo nano /etc/ssh/sshd_config

While many options in this file are best left untouched unless you have specific requirements, several key configurations are worth understanding and potentially adjusting:

Port 22

The Port directive specifies the port number on which the sshd server listens for incoming connections. The default port for SSH is 22. It is generally advisable to leave this as default unless you have a compelling reason to change it, such as for security through obscurity. If you decide to change the port, remember that you’ll need to specify this new port when connecting with the SSH client. We’ll cover how to do this later.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

The HostKey directives specify the locations of the host keys. Host keys are crucial for verifying the server’s identity. When you connect to a server for the first time, SSH will ask you to verify the host key. This mechanism ensures that you are connecting to the intended server and not falling victim to a man-in-the-middle attack.

SyslogFacility AUTH
LogLevel INFO

These two directives control the logging behavior of SSH. SyslogFacility AUTH specifies that authentication-related log messages should be directed to the AUTH facility of the system logging daemon. LogLevel INFO sets the verbosity of the logs to informational level. If you encounter issues with SSH, increasing the LogLevel to DEBUG or DEBUG2 can provide more detailed logs to help diagnose the problem.

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

These parameters govern login-related settings.

LoginGraceTime defines the number of seconds the server waits after a connection is established before timing out if the user fails to authenticate. The default is usually 120 seconds. You might want to adjust this based on your typical login time, but generally, the default is adequate.

PermitRootLogin determines whether the root user is allowed to log in directly via SSH. For enhanced security, it is highly recommended to change this to no. Instead, create a regular user account with sudo privileges. This practice minimizes the risk of unauthorized root access. After setting up a user with administrative privileges, switch to root using su or sudo after logging in.

StrictModes is a security feature that enforces strict file permissions for user’s .ssh directory and key files. It prevents logins if these files are world-readable, ensuring that private keys remain private. It’s generally a good practice to leave this set to yes.

X11Forwarding yes
X11DisplayOffset 10

These directives configure X11 Forwarding, which allows you to run graphical applications on the remote server and display their windows on your local machine. X11Forwarding yes enables the feature on the server side. To use it, you also need to enable X11 forwarding on the client side, typically by using the -X or -Y option when connecting with the ssh command. X11DisplayOffset sets the offset for the display numbers.

After making your desired changes, save the file and exit the text editor. If you are using nano, press Ctrl+X, then Y to confirm saving, and finally press Enter.

For any changes in /etc/ssh/sshd_config to take effect, you must reload the sshd server:

sudo systemctl reload ssh

It’s crucial to thoroughly test your changes to ensure they function as expected. A good approach is to keep a few terminal sessions open while modifying SSH configurations. This way, if you misconfigure something and lock yourself out, you can revert the changes from another session without losing access.

Locating and accessing the sshd_config file for server configuration.

Enhancing Security with SSH Keys: Passwordless Login

While password-based authentication is a standard method to log into remote systems, utilizing SSH keys offers a more secure and efficient alternative. Key-based authentication is faster and significantly enhances security by eliminating the vulnerabilities associated with passwords.

Why Use SSH Keys?

SSH keys provide a more secure way to log in because they leverage cryptographic key pairs for authentication, rather than passwords which can be intercepted or brute-forced. Furthermore, once set up, SSH key authentication streamlines the login process, allowing for passwordless logins, which is particularly beneficial for frequent server access and automation scripts.

Key-based Authentication Explained

Key-based authentication relies on a pair of keys: a private key and a public key.

The private key is stored on your local machine and must be kept secret and secure. Think of it as the physical key to your house, which you would never share.

The public key is designed to be shared and is placed on any server you wish to access. It’s like the lock on your door; anyone can see it, but only your private key can unlock it.

When you attempt to connect to a server using SSH keys, the server uses the public key to generate a challenge that can only be decrypted by the corresponding private key. If your client machine can successfully decrypt this challenge using its private key, authentication is granted without the need for a password. This entire process is handled automatically by SSH once configured.

Generating SSH Keys

SSH keys are generated on the machine from which you will be initiating the SSH connection—typically your local computer.

Open your terminal and enter the following command:

ssh-keygen -t rsa

This command initiates the key generation process using the RSA algorithm, which is widely accepted and secure. You will be prompted to specify a location to save the keys. The default location (~/.ssh/id_rsa for the private key and ~/.ssh/id_rsa.pub for the public key) is generally recommended.

You’ll also be asked to enter a passphrase. Setting a passphrase adds an extra layer of security by encrypting your private key on disk. However, if you prefer passwordless login without entering a passphrase each time you use the key, you can leave it empty by pressing Enter at the prompts. Be aware that omitting the passphrase slightly reduces the security if your private key is compromised.

After pressing Enter through the prompts to accept the defaults (or setting a passphrase if desired), your SSH key pair will be created in the .ssh directory in your home directory.

To verify, change into the .ssh directory:

cd ~/.ssh

And list the files:

ls -l

Verifying the creation of SSH keys by listing files in the .ssh directory.

You will see two files: id_rsa (the private key) and id_rsa.pub (the public key). The permissions are crucial for security. The private key id_rsa should only be readable and writable by you, while the public key id_rsa.pub can be publicly shared.

Transferring Your Public Key to the Server

Once you have generated your SSH key pair, the next step is to copy your public key to the server you wish to access. The easiest way to do this, assuming you currently have password-based SSH access to the server, is using the ssh-copy-id command:

ssh-copy-id <mark>remote_host</mark>

This command attempts to copy your public key to the authorized_keys file on the remote server. It will initiate an SSH session to the remote host, and you will be prompted for your password. After successful authentication, it will append the content of your public key (~/.ssh/id_rsa.pub) to the ~/.ssh/authorized_keys file on the remote server.

If ssh-copy-id is not available or if you prefer a manual method, you can manually copy the public key. First, display your public key:

cat ~/.ssh/id_rsa.pub

Copy the entire output of this command. Then, log into your server using password authentication:

ssh <mark>username@remote_host</mark>

Once logged in, create the .ssh directory if it doesn’t exist and ensure correct permissions:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Then, open the authorized_keys file using a text editor:

nano ~/.ssh/authorized_keys

Paste the public key you copied earlier into this file. Save and close the file. Finally, set the correct permissions for authorized_keys:

chmod 600 ~/.ssh/authorized_keys

After completing either method, you should be able to log in to your server using SSH keys without being prompted for a password.

Advanced SSH Client Options

The ssh command offers numerous optional flags that allow you to customize your connection. Some of these options are essential to align with specific server-side configurations or to enhance your workflow.

Specifying a Different Port

If you modified the default SSH port (port 22) in your sshd configuration, you need to specify the new port when connecting from the client side. Use the -p flag followed by the port number:

ssh -p <mark>port_number</mark> <mark>remote_host</mark>

Note on Security: Changing the SSH port to something other than 22 is a form of security through obscurity. While it won’t stop determined attackers, it significantly reduces automated brute-force password attempts, as these typically target the default port 22. Combining a non-standard port with key-based authentication provides a reasonable baseline security posture.

Running Single Commands Remotely

SSH is not just for interactive sessions; you can also use it to execute a single command on a remote server without opening an interactive shell. Simply append the command after the remote_host in your ssh command:

ssh <mark>remote_host</mark> <mark>command_to_run</mark>

For example, to check the uptime of a remote server, you could use:

ssh <mark>remote_host</mark> uptime

This command executes uptime on the remote server and returns the output to your local terminal.

Enabling X11 Forwarding for GUI Apps

If X11 forwarding is enabled on both the client and server, you can run graphical applications on the server and display them on your local desktop. To enable X11 forwarding when connecting, use the -X flag:

ssh -X <mark>remote_host</mark>

Ensure you have an X server running on your local machine for this to work. After connecting with the -X option, you can launch graphical programs on the remote server, and their interfaces will appear on your local system.

Strengthening Server Security: Disabling Password Authentication

After successfully setting up SSH key-based authentication, a significant security enhancement is to disable password-based authentication altogether. This measure drastically reduces the risk of brute-force attacks that attempt to guess passwords.

Warning: Before proceeding, ensure you have successfully configured and tested SSH key-based authentication. If you disable password authentication without working SSH keys, you risk locking yourself out of your server!

To disable password authentication, log into your server via SSH keys or through the console. Open the sshd_config file with root or sudo privileges:

sudo nano /etc/ssh/sshd_config

Locate the line PasswordAuthentication. It might be commented out (preceded by a #). Uncomment it by removing the # if necessary, and change its value to no:

PasswordAuthentication no

Also, ensure that PubkeyAuthentication is set to yes and ChallengeResponseAuthentication is set to no. These settings should typically be configured correctly by default:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

Save and close the file. Then, reload the SSH daemon to apply the changes:

sudo systemctl reload ssh

With password authentication disabled, the only way to log into your server (besides the console) will be through SSH key authentication, significantly improving your server’s security posture.

Conclusion

Becoming proficient with SSH is an invaluable asset for anyone involved in cloud computing and server management. As you explore its capabilities, you’ll discover more advanced features that can streamline your workflows and enhance your security practices. SSH’s enduring popularity stems from its security, efficiency, and versatility across various operational scenarios.

To further expand your skills, consider exploring SFTP (Secure File Transfer Protocol) for secure command-line file transfers.

We’ve simplified the process of adding SSH Keys to both new and existing DigitalOcean virtual machines. Learn more here.

About the author(s)

Justin Ellingwood

See author profile

Category: Tutorial

Tags: Linux Basics, Security, Ubuntu, Networking, System Tools