ssh Command in Linux: Connect to Remote Servers

Sooner or later, every Linux user has to work on a machine that is not in front of them. Secure Shell (SSH) makes that safe: it is a cryptographic network protocol used for an encrypted connection between a client and a server, so passwords and commands never travel in the clear.

The ssh client creates that secure connection to the SSH server on a remote machine. Once it is open, you can execute commands on the server, tunnel X11 sessions, forward ports, and more.

There are a number of SSH clients available, both free and commercial, with OpenSSH being the most widely used. It is available on all major platforms, including Linux, OpenBSD, Windows, and macOS.

This guide explains how to use the OpenSSH command-line client (ssh) to log in to a remote machine, run commands, and perform other operations.

Installing OpenSSH Client #

The OpenSSH client program is called ssh and can be invoked from the terminal. The OpenSSH client package also provides other SSH utilities such as scp and sftp that are installed alongside the ssh command.

OpenSSH client is preinstalled on most Linux distributions. If your system does not have the ssh client installed, you can install it using your distribution’s package manager.

Install OpenSSH on Ubuntu, Debian, and Derivatives #

sudo apt update
sudo apt install openssh-client

Install OpenSSH on Fedora, RHEL, and Derivatives #

sudo dnf install openssh-clients

Install OpenSSH on Windows 10 and 11 #

Windows 10 and Windows 11 include a built-in OpenSSH client that can be installed via PowerShell. Open PowerShell as Administrator, then find the exact package name by running:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

Name  : OpenSSH.Client~~~~0.0.1.0
State : NotPresent
Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

Once you know the package name, install it by running:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Path          :
Online        : True
RestartNeeded : False

Install OpenSSH on macOS #

macOS ships with the OpenSSH client installed by default.

ssh Command Syntax #

The basic syntax of the ssh command is:

ssh [OPTIONS] [USER@]HOST

The following requirements must be met to log in to a remote machine via SSH:

• An SSH server must be running on the remote machine.
• The SSH port must be open in the remote machine’s firewall.
• You must know the username and password of the remote account, or have a valid SSH key pair configured.

Connecting to a Remote Server #

To connect to a remote server, type ssh followed by the remote hostname or IP address:

ssh ssh.linuxize.com

When you connect to a remote machine for the first time, you will see a message like this:

The authenticity of host 'ssh.linuxize.com (192.168.121.111)' can't be established.
ED25519 key fingerprint is: SHA256:lhj4z2AizvydgC9eYwR+HIexkdWYnN7F39HMzG54t44
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Each server has a unique host key, and ssh saves it in the ~/.ssh/known_hosts file once you accept it. The This key is not known by any other names line means the same key is not saved under any other hostname or IP address. Before accepting the key, compare the displayed fingerprint with the value provided by the server administrator. If you have console access to the server, ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub prints it. Once you have verified that they match, type yes to save the key and continue. You will then be prompted to enter your password:

Warning: Permanently added 'ssh.linuxize.com' (ED25519) to the list of known hosts.
dev@ssh.linuxize.com's password:

Once you enter the password, you will be logged in to the remote machine.

When no username is given, ssh uses the current system login name. To log in as a different user, specify the username and host in the following format:

ssh username@hostname

The username can also be specified with the -l option:

ssh -l username hostname

By default, ssh connects to port 22. On some servers, administrators change the default SSH port to reduce the risk of automated attacks. To connect to a non-default port, use the -p option:

ssh -p 5522 username@hostname

If you are experiencing authentication or connection issues, use the -v option to print debugging messages:

ssh -v username@hostname

For more verbosity, use -vv or -vvv.

Running Remote Commands #

You can execute a command on a remote machine without starting an interactive shell session by appending the command after the host:

ssh username@hostname 'command'

For example, to check the disk usage on a remote server:

ssh username@hostname 'df -h'

To run multiple commands in one session, separate them with a semicolon or use &&:

ssh username@hostname 'uname -a && df -h'

To run a command that requires a pseudo-terminal (for example, top or sudo), pass the -t flag to force TTY allocation:

ssh -t username@hostname 'sudo journalctl -f'

ssh Command Options #

The ssh command accepts a long list of options, but a small group covers almost everything you will do day to day. The ones you have already seen control the connection itself:

• -p - Remote port to connect to (default is 22)
• -l - Login name to use on the remote host
• -i - Path to the private key file (identity file)
• -v - Verbose output for debugging (-vv and -vvv add more detail)
• -q - Quiet mode, which suppresses warnings and diagnostic messages
• -t - Force pseudo-terminal allocation
• -T - Disable pseudo-terminal allocation
• -C - Compress all data sent over the connection
• -F - Use an alternative configuration file instead of ~/.ssh/config
• -4 and -6 - Force IPv4 or IPv6 only

The rest deal with forwarding and tunneling:

• -L - Local port forwarding
• -R - Remote port forwarding
• -D - Dynamic port forwarding (SOCKS proxy)
• -N - Do not execute a remote command, which is useful when you only want a tunnel
• -f - Send ssh to the background just before the command runs
• -g - Allow remote hosts to connect to locally forwarded ports
• -A - Forward your local authentication agent (enable it only for hosts you trust)
• -w - Request tun device forwarding for a layer 3 VPN

A few of these are worth a closer look.

Passing Configuration Options with -o #

Not every setting has a dedicated command-line flag. The -o option lets you pass any ssh_config directive on the command line, using the same Keyword=value form you would write in the config file:

ssh -o "ServerAliveInterval=60" username@hostname

Repeat -o to pass more than one directive:

ssh -o "User=root" -o "Port=5522" hostname

Options given on the command line take precedence over the same options in ~/.ssh/config, so -o is a convenient way to override a host entry once without editing the file. Run man ssh_config for the full list of directives it accepts.

Connecting Through a Jump Host with -J #

Servers on a private network are often reachable only through a bastion host. The -J option tells ssh to connect to the jump host first, then open the connection to the final destination through it:

ssh -J username@jumphost username@internal-server

Authentication to the final server happens from your local machine, so the jump host never sees your password or private key. To chain more than one jump host, separate them with commas:

ssh -J user@first,user@second user@destination

To save the route in ~/.ssh/config and restrict the jump account, see the guide on using an SSH jump host .

Forwarding X11 with -X #

X11 forwarding lets you start a graphical program on the remote server and have its window appear on your local desktop. Pass the -X option to enable it:

ssh -X username@hostname

Once connected, launching an application such as firefox opens the window locally while the program itself runs on the server. Your local system needs a running X server, and the remote host typically needs the xauth package and X11Forwarding yes in its effective SSH server configuration.

Enable X11 forwarding only when you trust the remote server. Although -X applies X11 security restrictions, a compromised or privileged remote host may still be able to access your local display or monitor input. Use -x (lowercase) to disable X11 forwarding for a single connection when your config file enables it by default.

The -Y option enables trusted forwarding and skips the X11 security extension controls. Prefer -X, and use -Y only when an application requires it, because trusted forwarding gives the remote program full access to your local display.

SSH Config File #

If you connect to multiple remote systems over SSH regularly, remembering all IP addresses, usernames, non-standard ports, and command-line options becomes difficult.

The OpenSSH client reads options from the per-user configuration file (~/.ssh/config). You can store different SSH options for each remote host in this file.

A sample SSH config entry looks like this:

Host dev
    HostName dev.linuxize.com
    User mike
    Port 4422

With this entry, typing ssh dev is equivalent to:

ssh -p 4422 mike@dev.linuxize.com

For more information, see the article on the SSH config file . To make repeated sessions to the same host reuse one connection, see the guide on SSH multiplexing .

Public Key Authentication #

The SSH protocol supports various authentication mechanisms. Public key authentication lets you log in to a remote server without entering a password .

This method uses a pair of cryptographic keys. The private key stays on your local machine and the public key is placed on each remote server you want to access.

If you do not already have an SSH key pair on your local machine, generate one with:

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

Ed25519 is the recommended key type for new keys because it provides strong security with smaller keys and faster signing than RSA. If you need RSA for compatibility with older systems, use:

ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"

You will be asked to enter a passphrase. Using a passphrase is optional but strongly recommended for security.

Once you have your key pair, copy the public key to the remote server with ssh-copy-id :

ssh-copy-id username@hostname

Enter the remote user’s password when prompted. The public key will be appended to the ~/.ssh/authorized_keys file on the remote server.

After the key is in place, you can log in without being prompted for a password.

Port Forwarding #

SSH tunneling (port forwarding) creates an encrypted SSH connection through which traffic for other services can be relayed. It is useful for securing unencrypted protocols such as VNC or FTP, accessing geo-restricted services, or bypassing intermediate firewalls.

There are three types of SSH port forwarding:

Local Port Forwarding #

Local port forwarding forwards a connection from the client host through the SSH server to a destination host and port. Pass the -L option to create a local forward:

ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION_HOST:DESTINATION_PORT -N -f username@hostname

Remote Port Forwarding #

Remote port forwarding forwards a port from the server host back to the client host. Pass the -R option:

ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT -N -f username@hostname

Dynamic Port Forwarding #

Dynamic port forwarding creates a SOCKS proxy server that allows communication across a range of ports. Pass the -D option:

ssh -D [LOCAL_IP:]LOCAL_PORT -N -f username@hostname

The -f option tells ssh to run in the background and -N tells it not to execute a remote command.

For detailed step-by-step instructions, see How to Set Up SSH Tunneling (Port Forwarding) .

Other SSH Commands #

The OpenSSH client package installs more than ssh itself. The other commands in it handle keys, file transfers, and host verification:

• ssh-keygen - Create and manage key pairs, and remove old host entries from known_hosts
• ssh-copy-id - Add your public key to the authorized_keys file of a remote account
• ssh-agent - Keep decrypted private keys in memory, so you type each passphrase only once per session
• ssh-add - Load keys into the running agent and list the keys it holds
• ssh-keyscan - Fetch the public host keys of one or more servers, for example to fill known_hosts in a script
• scp - Copy files between hosts over SSH
• sftp - Transfer files in an interactive session over SSH

Before adding keys fetched by ssh-keyscan to known_hosts, verify their fingerprints through a trusted channel, such as the server console or the server administrator. The command collects keys but does not authenticate the server.

The commands you type after logging in, such as ls, cd, or df, are regular Linux commands that run on the remote server. If you are new to them, start with the basic Linux commands guide.

Troubleshooting #

Connection refused
The SSH server is not running on the remote host, or the SSH port is blocked by a firewall. Verify the server is running (sudo systemctl status ssh or sudo systemctl status sshd) and that the port is open. If both check out, work through the remaining causes of an SSH connection refused error , such as a listener bound to the wrong address.

Host key verification failed
The remote host’s key has changed since you last connected, which may indicate a server rebuild or a man-in-the-middle attack . If you are sure the host is legitimate, remove the old key with:

ssh-keygen -R hostname

Then reconnect to store the new fingerprint.

Permission denied (publickey)
The server does not accept your key. Verify that your public key is in ~/.ssh/authorized_keys on the remote host, that permissions are correct (chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys), and that the correct private key is being used. Run ssh -v for details, or see Fix SSH Permission Denied (publickey) .

Permission denied, please try again.
The server rejected the password login. Check the username and password, then the server authentication log for account or policy restrictions. By default, the client prompts up to three times, controlled by NumberOfPasswordPrompts. The final error may read Permission denied (publickey,password). The list in parentheses shows the methods the server currently offers. A missing password can mean password authentication is disabled, or an AuthenticationMethods policy requires a key before offering it.

On the server, check /etc/ssh/sshd_config and any included files in /etc/ssh/sshd_config.d/. Run sudo sshd -T | grep -E '^(passwordauthentication|authenticationmethods) ' to see the global settings. To evaluate per-user or client-specific Match rules, add -C user=username,addr=192.0.2.10,host=client.example.com to sshd -T, replacing the example values with the remote username and the client’s address and hostname.

Received disconnect from HOST port 22:2: Too many authentication failures
The server reached its MaxAuthTries limit before you logged in. This usually happens when the SSH agent holds several keys and the client offers each of them in turn. Pick the right key with -i and -o IdentitiesOnly=yes, or see Fix SSH “Too Many Authentication Failures” Error .

kex_exchange_identification: read: Connection reset by peer
The SSH server closed the connection before the key exchange started. A common cause is the MaxStartups limit in sshd_config. When too many unauthenticated connections are open at once, the server drops new ones. Check the server log with sudo journalctl -u ssh (-u sshd on Fedora and RHEL) for the reason. Older OpenSSH clients print the same error as ssh_exchange_identification.

client_loop: send disconnect: Broken pipe
The connection dropped while the session was open. A router or firewall often closes SSH connections that stay idle for too long. Client keepalives, shown in the FAQ below, prevent most of these drops. For other causes, see SSH Broken Pipe Error: Causes and Fixes .

Connection is slow to establish
Add GSSAPIAuthentication no to your ~/.ssh/config for the affected host to skip Kerberos authentication, which can cause delays when it times out.

Quick Reference #

For a printable quick reference, see the SSH cheatsheet .

FAQ #

What is the difference between ssh and scp/sftp?
ssh opens an interactive shell session or runs a single remote command. scp copies files between hosts over SSH, and sftp provides an interactive file transfer session. All three use the same SSH protocol and authentication.

Should I use Ed25519 or RSA keys?
Use Ed25519 for new keys. It provides strong security with short keys and fast operations. RSA with a sufficient key size, such as 4096 bits, also remains secure and is useful when connecting to older systems that do not support Ed25519.

How do I keep an SSH session alive?
Add the following to your ~/.ssh/config to send keepalive packets and prevent idle disconnection:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

How do I run ssh without typing a password every time?
Use public key authentication and copy your public key to the server with ssh-copy-id. See How to Set Up Passwordless SSH Login for a step-by-step guide.

Conclusion #

The ssh command is the primary tool for securely connecting to remote Linux servers. Use key-based authentication with Ed25519 keys, reach for -v whenever a connection misbehaves, and move your regular hosts into the SSH config file once you are managing more than a couple of them.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page