How to SSH into a Server: A Beginner's Guide to Secure Remote Access

Updated on October 26, 2023

As a system administrator or web developer, mastering Secure Shell (SSH) is a fundamental skill. SSH is your secure gateway to managing remote servers, executing commands, and transferring files safely over encrypted connections. This tutorial will guide you through the essentials of how to SSH into a server, covering everything from basic syntax to advanced security practices.

Understanding SSH: Core Concepts

SSH, or Secure Shell, is a cryptographic network protocol that enables you to securely access and manage remote servers or systems over an unsecured network. It provides a secure channel by encrypting the communication between your local computer (the client) and the remote server. This encryption prevents eavesdropping and tampering, ensuring your data remains confidential and intact during transmission.

At its core, SSH operates on a client-server architecture. You, as the user, utilize an SSH client program to initiate a connection to an SSH server running on the remote host.

The most basic syntax for initiating an SSH connection is:

ssh <remote_host>

Here, <remote_host> refers to the IP address or domain name of the server you intend to connect to. For example:

ssh 203.0.113.0

ssh example.com

This command assumes your username on your local machine is the same as your username on the remote server. If your usernames differ, you need to specify the remote username using the following syntax:

ssh <remote_username>@<remote_host>

For instance, to connect to example.com as the user sammy, you would use:

ssh [email protected]

Upon initiating a connection, SSH typically prompts you to authenticate. The most common initial authentication method is password-based authentication, where you will be asked to enter the password associated with the remote username. However, for enhanced security and convenience, SSH also supports key-based authentication, which we will delve into later in this guide.

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

exit

Setting Up SSH: Client and Server Components

To effectively use SSH, it’s important to understand the client and server components involved.

SSH Client: Your Access Point

The SSH client is the software you use on your local machine to connect to a remote server. If you are using macOS or Linux, an SSH client is already built into your operating system and accessible through the terminal application. You can simply open your terminal and use the ssh command directly.

For Windows users, SSH is not pre-installed. However, you have several options to gain SSH client functionality:

OpenSSH for Windows: Microsoft offers an official OpenSSH implementation for Windows. You can follow Microsoft’s documentation to install and configure it, allowing you to use SSH commands in PowerShell or Command Prompt.
Windows Subsystem for Linux (WSL): WSL provides a complete Linux environment within Windows. Installing a Linux distribution through WSL (like Ubuntu) will include the ssh command by default. This is a robust option if you prefer a Linux-like command-line experience.
Git for Windows: Git for Windows provides a Bash terminal environment that includes various Unix utilities, including ssh. This is a lightweight option if you primarily need SSH functionality and basic Linux commands.

Choose the option that best suits your technical comfort and needs. For most users, OpenSSH for Windows or Git for Windows provide a straightforward way to access the ssh command.

SSH Server (sshd): The Remote Host’s Gateway

The SSH server, often referred to as sshd (SSH daemon), is the program running on the remote server that listens for incoming SSH connections. Almost all Linux distributions come with sshd pre-installed and typically configured to start automatically upon system boot.

In most cases, you won’t need to manually configure or start the SSH server on your remote Linux server, especially if it’s a hosting service or cloud server. However, if for any reason the SSH server is not running or accessible, you may need to access your server through alternative methods like a web-based console provided by your hosting provider or a serial console if you have direct physical access.

If you do need to manually start the SSH server on a Ubuntu-based system, you can use the following command:

sudo systemctl start ssh

This command, executed with sudo for administrative privileges, will initiate the sshd service, allowing you to connect remotely via SSH.

Configuring Your SSH Server for Enhanced Security

Customizing your SSH server configuration is crucial for bolstering security and tailoring SSH behavior to your specific requirements. The primary configuration file for the SSH server on Ubuntu and most Linux distributions is located at /etc/ssh/sshd_config.

Important Security Precaution: Before making any changes to the sshd_config file, always create a backup of the original configuration. This allows you to easily revert to the default settings if any modifications cause issues. Use the following command to create a backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

You can then open the sshd_config file using a text editor like nano or vim:

sudo nano /etc/ssh/sshd_config

Within this file, you’ll find numerous configuration directives. While most options can be left at their default values, certain settings are particularly important for security and usability:

Essential SSH Configuration Options

Port:
```
Port 22
```
The Port directive specifies the port number that the sshd server listens on for incoming connections. The default port is 22. While changing the SSH port to a non-standard port (a practice known as “port obfuscation”) can offer a slight layer of security against automated attacks, it’s not a substitute for robust security measures like key-based authentication. If you do change the port, remember to specify the new port when connecting with your SSH client (e.g., ssh -p <port_number> <remote_host>).
PermitRootLogin:
```
PermitRootLogin yes
```
The PermitRootLogin directive controls whether direct root user logins are allowed via SSH. For enhanced security, it’s highly recommended to disable direct root logins by changing this directive to no:
```
PermitRootLogin no
```
Instead of logging in directly as root, create a regular user account with sudo privileges. Log in using this regular user account and then use sudo to execute administrative commands when necessary. This practice minimizes the risk associated with direct root access.
PasswordAuthentication:
```
PasswordAuthentication yes
```
The PasswordAuthentication directive enables or disables password-based authentication. While convenient initially, password authentication is vulnerable to brute-force attacks. For significantly enhanced security, especially after setting up SSH key-based authentication, disable password authentication by changing this directive to no:
```
PasswordAuthentication no
```
This forces SSH to rely solely on key-based authentication, making brute-force attacks ineffective.
PubkeyAuthentication & ChallengeResponseAuthentication:
```
PubkeyAuthentication yes
ChallengeResponseAuthentication no
```
Ensure that PubkeyAuthentication is set to yes to enable key-based authentication. ChallengeResponseAuthentication should typically be set to no as it relates to less secure authentication methods. These settings are usually configured correctly by default.

Reloading SSH Configuration

After making any changes to the /etc/ssh/sshd_config file, you must reload the SSH server for the changes to take effect. Use the following command:

sudo systemctl reload ssh

It’s crucial to thoroughly test your SSH configuration changes immediately after reloading. Maintain at least one active, separate SSH session while making configuration changes. This allows you to revert any problematic changes quickly without locking yourself out of your server. If you misconfigure SSH and lose access, you may need to use a server console or recovery mode to fix the configuration.

Key-Based SSH Authentication: Passwordless and Secure Login

While password authentication is a straightforward initial method, SSH key-based authentication offers superior security and convenience for accessing your servers.

Why Use SSH Keys?

Enhanced Security: SSH keys are cryptographically stronger than passwords, making them significantly more resistant to brute-force attacks and password guessing.
Convenience: Once set up, key-based authentication eliminates the need to type passwords every time you SSH into your server, streamlining your workflow.

How Key-Based Authentication Works

Key-based authentication relies on a pair of cryptographic keys:

Private Key: This key is kept secret and stored securely on your local computer. Think of it as your digital “secret key.”
Public Key: This key is derived from your private key and can be shared publicly. You place the public key on any server you wish to access.

When you attempt to SSH into a server using key-based authentication, the SSH server uses the public key you’ve placed on it to create a cryptographic challenge. This challenge can only be unlocked by the corresponding private key. Your SSH client on your local machine uses your private key to solve the challenge and prove your identity to the server without ever transmitting your private key over the network.

Generating SSH Keys

You generate SSH key pairs on your local computer (the client machine you’ll use to connect to the server). Open your terminal or command prompt and execute the following command:

ssh-keygen -t rsa

This command initiates the key generation process using the RSA algorithm (a common and secure algorithm). You’ll be prompted to specify a file to save the key pair. Press Enter to accept the default location (~/.ssh/id_rsa for the private key and ~/.ssh/id_rsa.pub for the public key).

You’ll also be prompted to enter a passphrase to protect your private key. While optional, setting a strong passphrase adds an extra layer of security. If a passphrase is set, you’ll need to enter it when using the private key. If you prefer passwordless login with SSH keys, you can leave the passphrase empty by pressing Enter when prompted.

After key generation, navigate to the .ssh directory in your user’s home directory:

cd ~/.ssh

List the files to examine the generated keys:

ls -l

You should see two files: id_rsa (the private key) and id_rsa.pub (the public key). The private key id_rsa should have restricted permissions (readable and writable only by the owner) to protect its secrecy. The public key id_rsa.pub can be shared freely.

Transferring Your Public Key to the Server

To enable key-based authentication, you need to copy your public key (id_rsa.pub) to the authorized_keys file in the .ssh directory of the user account on your remote server that you wish to access.

The easiest way to transfer your public key is using the ssh-copy-id utility, if available on your system. Execute the following command, replacing <remote_username> and <remote_host> with your actual remote username and server address:

ssh-copy-id <remote_username>@<remote_host>

This command attempts to connect to your remote server via SSH. You’ll be prompted for the password for the remote user. Once you enter the password, ssh-copy-id will automatically copy the contents of your ~/.ssh/id_rsa.pub file to the ~/.ssh/authorized_keys file on the remote server.

If ssh-copy-id is not available, you can manually copy the public key:

Copy the public key to your clipboard:
```
cat ~/.ssh/id_rsa.pub
```
Select and copy the output of this command.
SSH into your server using password authentication:
```
ssh <remote_username>@<remote_host>
```
Create the .ssh directory if it doesn’t exist:
```
mkdir -p ~/.ssh
```
Open or create the authorized_keys file:
```
nano ~/.ssh/authorized_keys
```
Paste your public key into the authorized_keys file.
Save and close the file.
Restrict permissions on the .ssh directory and authorized_keys file:
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```

After successfully transferring your public key, you should be able to SSH into your server without being prompted for a password, provided that key-based authentication is correctly configured on the server.

Advanced SSH Client Options

The ssh command offers various options to customize your connection behavior. Here are a few useful client-side flags:

Specifying a Port: If you’ve changed the default SSH port on your server, use the -p option followed by the port number:
```
ssh -p <port_number> <remote_host>
```
For example, if your SSH server listens on port 2222:
```
ssh -p 2222 [email protected]
```
Executing a Single Command: To run a single command on the remote server without opening an interactive shell, specify the command after the remote_host:
```
ssh <remote_host> <command_to_run>
```
For example, to check the server’s uptime:
```
ssh example.com uptime
```
Enabling X11 Forwarding: If you need to run graphical applications on the remote server and display them on your local machine, use the -X option to enable X11 forwarding (provided X11 forwarding is enabled on the server):
```
ssh -X <remote_host>
```
This forwards the graphical display from the remote server to your local X server, allowing you to run GUI applications remotely.

Disabling Password Authentication for Enhanced Security

After successfully setting up SSH key-based authentication and verifying that you can log in without passwords, it’s highly recommended to disable password authentication on your SSH server for enhanced security. This prevents password-based brute-force attacks and ensures that only users with the corresponding private key can access your server via SSH.

Critical Warning: Before disabling password authentication, ensure you have successfully configured and tested SSH key-based authentication. If you disable password authentication prematurely and encounter issues with key-based login, you may lose SSH access to your server.

To disable password authentication:

SSH into your server.
Edit the sshd_config file:
```
sudo nano /etc/ssh/sshd_config
```
Locate the PasswordAuthentication directive. If it’s commented out (preceded by a #), uncomment it by removing the #.
Change its value to no:
```
PasswordAuthentication no
```
Verify that PubkeyAuthentication is set to yes:
```
PubkeyAuthentication yes
```
and that ChallengeResponseAuthentication is set to no:
```
ChallengeResponseAuthentication no
```
Save and close the sshd_config file.
Reload the SSH server:
```
sudo systemctl reload ssh
```

Password authentication will now be disabled, and your server will only accept SSH logins using key-based authentication, significantly improving its security posture.

Conclusion

Mastering SSH is an essential skill for anyone working with remote servers. This tutorial has provided a comprehensive guide to SSH, covering basic connection syntax, server configuration, key-based authentication setup, and advanced client options. By implementing the security practices outlined, such as disabling password authentication and utilizing SSH keys, you can ensure secure and efficient remote server management.

To further enhance your server management skills, explore SFTP (Secure File Transfer Protocol) for secure command-line file transfers, building upon your SSH knowledge.

We’ve streamlined the process of adding SSH Keys to your DigitalOcean virtual machines, making server security more accessible than ever. Learn more here

About the author(s)

Justin Ellingwood, a seasoned Linux system administrator and open-source enthusiast, brings years of practical experience to guide you through the intricacies of SSH and server management.

Category: Tutorial

Tags: SSH, Secure Shell, Linux, Server Security, Remote Access, Command Line, System Administration, Networking

Share to X (Twitter)Share to Facebook Share to LinkedIn Share to YCombinator

How to SSH into a Server: A Beginner’s Guide to Secure Remote Access