How to Connect to a Remote Server Using SSH: Step-by-Step Guide

SSH (Secure Shell) encrypts all traffic between your local machine and a remote server, keeping credentials and commands safe even on untrusted networks. System administrators, developers, and DevOps engineers rely on it daily for running commands, transferring files, and tunneling services.

In this tutorial, you will connect to a remote server using SSH, generate SSH keys (Ed25519 and RSA), transfer files with SCP and SFTP, troubleshoot common connection problems, and more.

#What is SSH?

SSH (Secure Shell) is a network protocol that lets you securely connect to remote servers and run commands, even over an untrusted network. System administrators and developers rely on it to manage servers, deploy software, and monitor services from anywhere.

Unlike older protocols such as Telnet, which transmit everything in plain text, including passwords, SSH encrypts your entire connection. Because of this security gap, Telnet was phased out decades ago, and SSH became the standard remote access protocol.

#What is SSH used for?

SSH is a secure way to access a server. The following are some of the things one can do with SSH:

• Remote server administration: One can connect to any server from anywhere across the world and work with it as if you are sitting next to it.

• File transfers: SSH provides functionality for safely copying and transferring files via SCP or SFTP from a local machine onto a remote server.

• Software installation: Installation or upgrade of any software on your server is feasible via SSH.

• System monitoring: SSH enables you to view logs and, hence, would allow for monitoring of the running processes on your remote servers.

• Port forwarding and tunneling: SSH can forward local ports to remote services or create encrypted tunnels for database connections, web dashboards, and other traffic that should not be exposed publicly.

#Prerequisites

Before you use SSH to connect to a remote server, ensure that the following have been set up:

• A remote server that is powered on and connected to the network.

• Your server's IP address or Domain name.

• Ensure you have the necessary permissions to access the remote server.

• Ensure that your server's firewall allows SSH connections (port 22 by default).

#How to connect to a remote server via SSH

Now that everything is up and running, let's connect to your server remotely using SSH.

#Step 1: Ensure that SSH is installed on the local machine

Before accessing your server, you should have an SSH client installed on your computer. Before installing it, take a look at whether it is installed using the following command:

ssh -V

OutputOpenSSH_9.6p1 Ubuntu-3ubuntu13.15, OpenSSL 3.0.13 30 Jan 2024

Otherwise, you can install SSH using your local package manager. For instance, on Debian/Ubuntu, you would install with:

sudo apt install openssh-client -y

Let it install, then proceed with the next step.

#Step 2: Connect to your remote server

Now, run the following to SSH into your remote server:

ssh username@remote_host

Replace the above username with the actual username of your server and remote_host with the IP address or domain name of your server.

For example:

ssh cherryservers@88.216.70.187

The first time you connect to any server, it will always show you the fingerprint of the server and ask you whether you want to continue connecting to it.

Type yes to confirm and hit Enter to proceed.

OutputThe authenticity of host '88.216.70.187 (88.216.70.187)' can't be established.  
ED25519 key fingerprint is: SHA256:bMR+QUP7MHEq8Qax+C+y1eRd+8+3ZiWbMWa/aoy0Y1Q  
This key is not known by any other names.  
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes  
Warning: Permanently added '88.216.70.187' (ED25519) to the list of known hosts.  
cherryservers@88.216.70.187's password:

#Step 3: Authenticating with a password

The server will prompt you for the user account’s password. Type your password and press Enter.

You will be logged in and may start to work with the server, provided the password is correct.

OutputWelcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64)  
  
* Documentation: https://help.ubuntu.com  
* Management: https://landscape.canonical.com  
* Support: https://ubuntu.com/pro  
  
System information as of Mon Mar 16 07:12:33 EET 2026  
  
System load: 0.27 Processes: 147  
Usage of /: 2.1% of 76.45GB Users logged in: 0  
Memory usage: 5% IPv4 address for eth0: 88.216.70.187  
Swap usage: 0%  
  
Expanded Security Maintenance for Applications is not enabled.  
  
0 updates can be applied immediately.  
  
Enable ESM Apps to receive additional future security updates.  
See https://ubuntu.com/esm or run: sudo pro status  
  
The list of available updates is more than a week old.  
To check for new updates run: sudo apt update

#Step 4: Exiting the SSH session

You can exit this SSH session anytime with the following command:

exit

OutputConnection to 88.216.70.187 closed.

The command will log you out of the server and bring you back to your local terminal.

#Using SSH keys for secure authentication on your server

Using SSH keys does not require you to continuously input your password every time you want to log in; it keeps your connection more secure and much faster. SSH keys also help to manage several servers or to automate tasks.

Now, enable key-based authentication on your server with SSH by following these steps:

#Step 1: Generate Ed25519 SSH keys (recommended)

Ed25519 is the recommended SSH key algorithm. It produces shorter keys than RSA, signs and verifies faster, and resists several classes of side-channel attacks. All modern SSH clients and servers (OpenSSH 6.5+) support it.

Generate an Ed25519 key pair:

ssh-keygen -t ed25519 -C "your_email@example.com"

The -C flag adds a comment to help you identify the key later. Press Enter to accept the default file location (~/.ssh/). Set a passphrase when prompted. A passphrase encrypts the private key on disk, so even if someone steals the file, they cannot use it without the passphrase.

If you plan to configure passwordless SSH authentication (for example, for automated scripts or tools like Ansible), leave the passphrase blank by pressing Enter twice. Otherwise, you will still be prompted for the passphrase each time you connect.

Ed25519 vs. RSA: when to use which

Use Ed25519 for any system running OpenSSH 6.5 or later. Fall back to RSA 4096-bit only when connecting to older hardware or embedded systems that do not support Ed25519.

#Step 2: Generate RSA keys (fallback for legacy systems)

Run the command. Skip this step if you did step 1 above:

ssh-keygen -t rsa -b 4096

This will generate a 4096-bit RSA keypair, which is good enough for most situations. Next, it will prompt you to specify the path to save the key. You can simply hit Enter to accept the default location (~/.ssh/id_rsa).

You would be prompted for a passphrase. You can hit Enter to skip this stage, but it is highly recommended that you provide a passphrase for your private key so it can be encrypted if someone compromises it.

#Step 3: Copy the public key to the remote server

Next, you need to copy the public key to your server so it knows and trusts your local machine when you connect to it.

Run the following command to copy the public key to your remote server:

ssh-copy-id username@remote_host

Remember to use your actual username for username and the IP address or domain name of your server for remote_host. For instance:

ssh-copy-id cherryservers@88.216.70.187

Output/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/emmanueloyibo/.ssh/id_ed25519.pub"  
/usr/bin/ssh-copy-id: INFO: attempting to log  in with the new key(s), to filter out any that are already installed  
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys  
cherryservers@88.216.70.187's password:  
  
Number of key(s) added: 1  
  
Now try logging into the machine, with: "ssh 'root@88.216.70.187'"  
and check to make sure that only the key(s) you wanted were added.

The command above will always prompt you for your password. Then, after entering the password, it adds your public key to the server in the ~/.ssh/authorized_keys file. You can now log in to the server without a password.

However, you can copy the key manually, if ssh-copy-id is not available by running:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

#Step 4: Login using SSH keys

To log in using SSH keys, run the same SSH command as before:

ssh username@remote_host

This time, it will not ask for your password. The connection is authenticated with your SSH key. If you had a passphrase during the key generation, you will be required to provide it. Enter the passphrase to log into the server.

#Step 5: Disable password authentication (optional)

Disabling password-based logins can take your server security a step further. That means only people with the proper SSH keys can access your server.

Follow the steps below to disable password authentication:

1. Log in to your server using SSH keys.

2. Open the SSH configuration file in your favorite editor, for example, nano:

sudo nano /etc/ssh/sshd_config

3. Look for the line that says #PasswordAuthentication yes. Uncomment the line by removing the #, then change yes to no.

4. Additionally, look for the #PubkeyAuthentication yes line and uncomment it. This enables key-based authentication. This way, you will not be locked out of your server after disabling password authentication.

5. Save the file and exit the editor by pressing Ctrl + X, then Y, and Enter.

6. Finally, restart the SSH service to apply the changes:

sudo systemctl restart sshd

From now on, only SSH keys will be able to log into your server. This is more secure for your server. However, ensure your SSH keys are set up before this change. Otherwise, you may lock yourself out.

#How to transfer files over SSH (SCP and SFTP)

Here is how to use SCP and SFTP to move files between your local machine and a remote server.

#Copy files with SCP

SCP (Secure Copy Protocol) copies files over an encrypted SSH connection. It works well for quick, one-off transfers.

Copy a local file to the remote server:

scp /path/to/local/file username@remote_host:/path/to/remote/directory

Copy a file from the remote server to your local machine:

scp username@remote_host:/path/to/remote/file /path/to/local/directory

Copy an entire directory recursively with the -r flag:

scp -r /path/to/local/directory username@remote_host:/path/to/remote/directory

If your server uses a non-default SSH port, specify it with the -P flag (uppercase):

scp -P 2222 file.txt username@remote_host:/home/username/

#Interactive file management with SFTP

SFTP (SSH File Transfer Protocol) opens an interactive session for browsing, uploading, and downloading files.

Start an SFTP session:

sftp username@remote_host

Once connected, use ls to list remote files, cd to change directories, get to download, put to upload, and exit to close the session.

Use SCP when you know the exact paths. Use SFTP when you need to browse the remote filesystem or transfer multiple files interactively.

#SSH agent and agent forwarding

Entering your passphrase every time you connect to a server gets tedious fast. The SSH agent stores your decrypted private keys in memory for the duration of your session.

#Start the SSH agent and add keys

Start the agent and add your key:

eval "$(ssh-agent -s)"  
ssh-add ~/.ssh/id_ed25519

The agent will prompt for your passphrase once. After that, all SSH connections using that key will authenticate without asking again.

List the keys currently loaded in the agent:

ssh-add -l

#Agent forwarding

Agent forwarding lets you authenticate from a remote server to a third host (like GitHub or another server) using your local SSH key. Your private key never leaves your local machine.

Connect with agent forwarding enabled:

ssh -A username@remote_host

From the remote server, you can now run commands that require your SSH key, such as git clone from a private repository, without copying your private key to the server.

Security warning: Only use agent forwarding with servers you trust. A compromised server with root access could potentially use your forwarded key to authenticate as you on other systems.

#SSH file permissions reference

Incorrect file permissions are one of the most common causes of SSH authentication failures. SSH refuses to use key files if their permissions are too open, because other users on the system could read your private key.

Set the correct permissions with these commands:

chmod 700 ~/.ssh  
chmod 600 ~/.ssh/id_ed25519  
chmod 600 ~/.ssh/id_rsa  
chmod 644 ~/.ssh/id_ed25519.pub  
chmod 644 ~/.ssh/id_rsa.pub  
chmod 600 ~/.ssh/authorized_keys  
chmod 600 ~/.ssh/config

Here is a quick reference table:

If you see "WARNING: UNPROTECTED PRIVATE KEY FILE" errors, run the commands above to fix them.

#Common SSH options and flags

SSH also provides many options and flags that let you connect to your server in a much more flexible way. Let's review some of the most useful options for customizing your SSH connections.

#Using a custom port

By default, SSH connects on port 22, but you can change it to whatever you'd like for extra security. You would then specify your port by adding the -p, immediately followed by the port number.

For example, if the server is using port 2222, you would run:

ssh -p 2222 username@remote_host

This blocks one of the possible avenues of attack using automation that rely on the default ports.

#Running a command on the remote server

To run a quick command on your server without opening an interactive session, add the command to the end of your SSH line. For instance:

ssh username@remote_host "uptime"

Output07:42:12 up 31 min, 2 users, load average: 0.02, 0.02, 0.00

This runs the uptime command, displays the output, and logs you out immediately.

#Enabling X11 forwarding

SSH even allows you to forward running applications on a remote server to your local machine with X11 forwarding. For this to work, though, you have to make sure that xauth is installed on the remote server and also that your local machine actually runs an X server.

To enable X11 forwarding, add the -X option:

ssh -X username@remote_host

This will enable you to run graphical applications from the remote server on your local system.

#Using SSH config file

If you regularly use several different servers, you can streamline your SSH usage by creating an SSH config file. The SSH config file holds your connection information, such as usernames, ports, and keys. You can create or edit the config file at ~/.ssh/config, and add entries like below:

Host myserver
    HostName 192.168.1.1
    User username
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Now, you can connect to the server using:

ssh myserver

#Specifying a private key file

For multiple SSH keys, you can specify which private key to use with the -i flag. This is helpful when managing many servers with different keys.

For example, to use the key stored in ~/.ssh/id_rsa_work run the command:

ssh -i ~/.ssh/id_rsa_work username@remote_host

#SSH connection troubleshooting

You might experience one or two hiccups that could lead to failure in connecting to your server via SSH. Let's now explore some common SSH issues and how to fix them.

#Connection refused error

A "Connection refused" error generally indicates that the SSH service is not running on the target server; it can also mean that a firewall rule is blocking the connection attempt. First, verify SSH is installed and running:

sudo systemctl status ssh

If SSH is not running, start it with the command below:

sudo systemctl start ssh

Also, verify that your server's firewall allows SSH traffic on the correct port.

#Permission denied error

This error usually indicates a problem with the user's permissions or the SSH key. You have to check if you are using the correct username and that your public key is properly set on the server. Also, double-check if you are using a password and ensure the user has SSH access.

In many cases, incorrect file permissions cause this error. Run the following on the server to fix permissions:

chmod 700 ~/.ssh  
chmod 600 ~/.ssh/authorized_keys

If you are connecting with a key file, make sure the private key on your local machine also has 600 permissions. SSH will silently refuse to use a key file that other users can read.

#Host key verification failed

The error happens when your server's SSH key changes and your local machine sees a mismatch. Fix this error by removing the old key from the ~/.ssh/known_hosts file using:

ssh-keygen -R remote_host

The remote_host directive above represents the IP address or domain name of your server. After this, try connecting again. You will be prompted to verify the new key.

#Timeout during connection

This may be due to a problem with your network or due to the server you are targeting being poorly configured. First, troubleshoot your network connection. After that make sure the right port is open by running the following command:

nc -v remote_host 22

The -v option above enables verbose mode. However, if you still encounter timeouts, the server might be overloaded or misconfigured.

#Authentication method not supported

This is the error that usually occurs when a server does not allow the method you are trying to use to authenticate yourself. When using SSH keys, they need to be set up correctly on the server.

Additionally, you must apply the right permissions to the ~/.ssh/authorized_keys file. Moreover, you can adjust your server's SSH configuration to enable authentication with keys or passwords.

#Too many authentication failures

SSH tries every key loaded in your agent before falling back to password authentication. If you have many keys loaded, the server may reject the connection before trying the correct one. Fix this by specifying the exact key and disabling agent keys:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes username@remote_host

The -o IdentitiesOnly=yes flag tells SSH to only use the key specified with -i and ignore keys from the agent. You can also add this permanently to your ~/.ssh/config:

Host myserver
    HostName 192.168.1.1
    User username
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

#DNS resolution failures

If you see "Could not resolve hostname" errors, your system cannot translate the server's hostname to an IP address. Verify DNS works by running:

nslookup remote_host

If DNS resolution fails, try connecting to the server directly using its IP address. You can also check your /etc/resolv.conf file to confirm your DNS servers are configured correctly.

#Conclusion

In this tutorial, you learned how to connect to a remote server using SSH, generate Ed25519 and RSA key pairs, and set up key-based authentication. You also transferred files with SCP and SFTP, configured the SSH agent for passphrase management, and fixed common connection errors.

For deeper server hardening, including Fail2Ban and firewall configuration, see our guide on how to secure a Linux server. You can also create a dedicated sudo user for day-to-day management instead of logging in as root.