SSH Essentials on Linuxize

ssh Command in Linux: Connect to Remote Servers

hello@linuxize.com (Linuxize) — Tue, 17 Dec 2019 19:31:47 +0100

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

Terminal
sudo apt update
sudo apt install openssh-client

Install OpenSSH on Fedora, RHEL, and Derivatives

Terminal
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. To find the exact package name, run:

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

output

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:

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

output

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:

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

Terminal
ssh ssh.linuxize.com

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

output

The authenticity of host 'ssh.linuxize.com (192.168.121.111)' can't be established.
ECDSA key fingerprint is SHA256:Vybt22mVXuNuB5unE++yowF7lgA/9/2bLSiO3qmYWBY.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Each host has a unique fingerprint that is stored in the ~/.ssh/known_hosts file. Before accepting it, compare the displayed fingerprint with the value provided by the server administrator or shown in the server console. Once you have verified that they match, type yes to store the fingerprint and continue. You will then be prompted to enter your password:

output

Warning: Permanently added 'ssh.linuxize.com' (ECDSA) 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:

Terminal
ssh username@hostname

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

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

Terminal
ssh -p 5522 username@hostname

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

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

Terminal
ssh username@hostname 'command'

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

Terminal
ssh username@hostname 'df -h'

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

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

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

Terminal
ssh -o "ServerAliveInterval=60" username@hostname

Repeat -o to pass more than one directive:

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

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

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

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:

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

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

With this entry, typing ssh dev is equivalent to:

Terminal
ssh -p 4422 mike@dev.linuxize.com

For more information, see the article on the SSH config file .

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:

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

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

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

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

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

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

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:

Terminal
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 file permissions are correct (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 (password)
The password is wrong, or the server has password authentication disabled. Check PasswordAuthentication in /etc/ssh/sshd_config on the remote host.

ssh_exchange_identification: read: Connection reset by peer
The SSH server rejected the connection before authentication. This can be caused by MaxStartups or AllowUsers/DenyUsers restrictions in sshd_config.

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 .

Command	Description
`ssh hostname`	Connect using current username
`ssh user@hostname`	Connect as a specific user
`ssh -p PORT user@hostname`	Connect on a non-default port
`ssh -i ~/.ssh/id_ed25519 user@hostname`	Connect with a specific key
`ssh -o "User=root" hostname`	Pass an ssh_config directive inline
`ssh -J user@jump user@target`	Connect through a jump host
`ssh -X user@hostname`	Enable X11 forwarding
`ssh -C user@hostname`	Enable compression
`ssh -q user@hostname`	Quiet mode
`ssh user@hostname 'command'`	Run a remote command
`ssh -t user@hostname 'sudo command'`	Run a command requiring a TTY
`ssh -L 8080:localhost:80 user@hostname`	Local port forward
`ssh -R 9090:localhost:3000 user@hostname`	Remote port forward
`ssh -D 1080 user@hostname`	Dynamic SOCKS proxy
`ssh -v user@hostname`	Debug connection
`ssh-keygen -t ed25519`	Generate an Ed25519 key pair
`ssh-copy-id user@hostname`	Copy public key to remote host

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:

ini
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.

How to Enable SSH on Ubuntu 18.04

hello@linuxize.com (Linuxize) — Sun, 09 Sep 2018 19:31:47 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server.

In this tutorial, we’ll show you how to enable SSH on an Ubuntu Desktop machine. Enabling SSH will allow you to remotely connect to your Ubuntu machine and securely transfer files or perform administrative tasks.

Prerequisites

Before continuing with this tutorial, make sure you are logged in as a user with sudo privileges .

Enabling SSH on Ubuntu

The SSH server is not installed by default on Ubuntu desktop systems but it can be easily installed from the standard Ubuntu repositories.

To install and enable SSH on your Ubuntu system complete the following steps:

Open your terminal either by using the Ctrl+Alt+T keyboard shortcut or by clicking on the terminal icon and install the openssh-server package by typing:
Terminal
```
sudo apt update
sudo apt install openssh-server
```
Enter the password when prompted and enter Y to continue with the installation.
Once the installation is completed, the SSH service will start automatically. To verify that the installation was successful and SSH service is running type the following command which will print the SSH server status:
Terminal
```
sudo systemctl status ssh
```
You should see something like Active: active (running) :

Press q to get back to the command line prompt.
Ubuntu comes with a firewall configuration tool called UFW. If the firewall is enabled on your system, make sure to open the SSH port:
Terminal
```
sudo ufw allow ssh
```

Now that SSH is installed and running on your Ubuntu system you can connect to it via SSH from any remote machine. Linux and macOS systems have SSH clients installed by default. If you want to connect from a Windows machine then you can use an SSH client such as PuTTY .

Connecting to SSH Over LAN

To connect to your Ubuntu machine over LAN you only need to enter the following command:

Terminal
ssh username@ip_address

Info

Change the username with the actual user name and ip_address with the IP Address of the Ubuntu machine where you installed SSH.

If you don’t know your IP address you can easily find it using the ip command :

Terminal
ip a

As you can see from the output, the system IP address is 192.168.121.111.

Once you’ve found the IP address, login to remote machine by running the following ssh command:

Terminal
ssh linuxize@192.168.121.111

When you connect through SSH for the first time, you will see a message looking something like this:

output

The authenticity of host '192.168.121.111 (192.168.121.111)' can't be established.
ECDSA key fingerprint is SHA256:Vybt22mVXuNuB5unE++yowF7lgA/9/2bLSiO3qmYWBY.
Are you sure you want to continue connecting (yes/no)?

Type yes and you’ll be prompted to enter your password.

output

Warning: Permanently added '192.168.121.111' (ECDSA) to the list of known hosts.
linuxize@192.168.121.111's password:

Once you enter the password you will be greeted with a message similar to the one below.

output

Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-33-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
...

You are now logged in to your Ubuntu machine.

Connecting to SSH Over Internet

To connect to your Ubuntu machine over the Internet you will need to know your public IP Address and to configure your router to accept data on port 22 and send it to the Ubuntu machine where the SSH is running.

To determine the public IP address of the machine you’re trying to SSH to, simply visit the following URL: https://api.ipify.org .

When it comes to setting up port forwarding each router has a different way to setup port forwarding. You should consult your router documentation about how to set up port forwarding. In short, you need to enter the port number where requests will be made (Default SSH port is 22) and the private IP address you found earlier (using the ip a command) of the machine where the SSH is running.

Once you’ve found the IP address, and configured your router you can log in by typing:

Terminal
ssh username@public_ip_address

If you are exposing your machine to the Internet it is a good idea to implement some security measures. The most basic one is to configure your router to accept SSH traffic on a non-standard port and to forward it to port 22 on the machine running the SSH service.

You can also set up an SSH key-based authentication and connect to your Ubuntu machine without entering a password.

Disabling SSH on Ubuntu

If for some reason you want to disable SSH on your Ubuntu machine you can simply stop the SSH service by running:

Terminal
sudo systemctl stop ssh

To start it again run:

Terminal
sudo systemctl start ssh

To disable the SSH service to start during system boot run:

Terminal
sudo systemctl disable ssh

To enable it again type:

Terminal
sudo systemctl enable ssh

Conclusion

You have learned how to install and enable SSH on your Ubuntu 18.04. You can now login to your machine and perform common sysadmin tasks through the command prompt.

By default, SSH listens on port 22. Changing the default SSH port adds an extra layer of security to your server by reducing the risk of automated attacks.

If you are managing multiple systems, you can simplify your workflow by defining all of your connections in the SSH config file .

For more information, about how to configure your SSH server read the Ubuntu’s SSH/OpenSSH/Configuring guide and the official SSH manual page.

If you have any questions, please leave a comment below.

How to Enable SSH on Ubuntu

hello@linuxize.com (Linuxize) — Mon, 01 Jun 2020 19:51:27 +0100

Secure Shell (SSH) is a network protocol that allows you to securely connect to a remote server or computer over an encrypted connection. With SSH enabled, you can remotely manage your Ubuntu system, run administrative commands, and transfer files securely using tools like scp and sftp .

This guide explains how to enable SSH on Ubuntu 20.04, 22.04, 24.04, and 26.04, connect to it remotely, and manage the SSH service.

Quick Reference

Task	Command
Install OpenSSH server	`sudo apt install openssh-server`
Check SSH service status	`sudo systemctl status ssh.service ssh.socket`
Start SSH on Ubuntu 20.04/22.04	`sudo systemctl start ssh.service`
Start SSH on Ubuntu 24.04/26.04	`sudo systemctl start ssh.socket`
Stop SSH	`sudo systemctl stop ssh.service ssh.socket`
Enable SSH on boot (Ubuntu 20.04/22.04)	`sudo systemctl enable ssh.service`
Enable SSH on boot (Ubuntu 24.04/26.04)	`sudo systemctl enable ssh.socket`
Disable SSH	`sudo systemctl disable --now ssh.service ssh.socket`
Allow SSH through UFW	`sudo ufw allow ssh`
Connect to remote host	`ssh username@ip_address`

For a printable quick reference, see the SSH cheatsheet .

Enabling SSH on Ubuntu

By default, on fresh installs, Ubuntu does not allow SSH connections. You must enable it manually.

Follow the steps below as root or a user with sudo privileges to install and enable SSH on your Ubuntu system:

Open the terminal using Ctrl+Alt+T and install the openssh-server package:
Terminal
```
sudo apt update
sudo apt install openssh-server
```
When prompted, enter your password, then press Enter to continue the installation.
After installation, Ubuntu enables OpenSSH automatically. Ubuntu 20.04 and 22.04 run ssh.service at boot. Verify that the service is running:
Terminal
```
sudo systemctl status ssh.service
```
The output should show the service as active (running) and enabled to start on system boot:
output
```
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2026-09-01 12:34:00 CEST; 9h ago
...
```
Press q to exit the status screen and get back to the command line prompt.

Ubuntu 24.04 and 26.04 use ssh.socket by default, a behavior introduced in Ubuntu 22.10. The socket listens for incoming connections and starts ssh.service when a client connects. Check the socket unit instead:
Terminal
```
sudo systemctl status ssh.socket
```
Look for Active: active (listening) in the output. Before the first connection, ssh.service may be inactive, which is expected and does not mean that SSH is broken.
Ubuntu ships with a firewall configuration tool called UFW. If the firewall is enabled on your system, make sure to open the SSH port:
Terminal
```
sudo ufw allow ssh
```

That is it. You can now connect to your Ubuntu system via SSH from any remote machine. Linux and macOS systems include an SSH client by default. On Windows 10 and 11, you can use the built-in ssh client from PowerShell or Command Prompt, or use PuTTY if you prefer a graphical SSH client.

Connecting to the SSH Server

To connect to your Ubuntu machine over LAN, invoke the ssh command followed by the username and the IP address in the following format:

Terminal
ssh username@ip_address

Info

Make sure you change username to the actual username and ip_address to the IP Address of the Ubuntu machine where you installed SSH.

If you do not know the IP address, you can easily find it using the ip command :

Terminal
ip a

As you can see from the output, the system IP address is 10.0.2.15.

Once you have found the IP address, log in to the remote machine by running the following SSH command:

Terminal
ssh linuxize@10.0.2.15

When you connect the first time, you will see a security warning like this:

output

The authenticity of host '10.0.2.15 (10.0.2.15)' can't be established.
ED25519 key fingerprint is SHA256:Vybt22mVXuNuB5unE++yowF7lgA/9/2bLSiO3qmYWBY.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes, and you will be prompted to enter your password.

output

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

Once you enter the password, you will be logged into your system and greeted with the default Ubuntu message:

output

Welcome to Ubuntu 24.04 LTS (GNU/Linux 6.8.0-45-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
...

You are now logged in to your Ubuntu machine.

Connecting to SSH behind NAT

To connect to your home Ubuntu machine over the Internet, you will need to know your public IP address and configure your router to accept incoming traffic on port 22 and forward it to the Ubuntu system where SSH is running.

Find Your Public IP Address To determine the public IP address of the machine you are trying to SSH to, visit the following URL: https://api.ipify.org .
Configure Port Forwarding When it comes to setting up port forwarding on your router, each device has its own interface and terminology. You should consult your router’s documentation for instructions on setting up port forwarding. In short, you need to enter the port number where requests will be made (the default SSH port is 22) and the private IP address you found earlier (using the ip a command) of the machine where SSH is running.
Connect Using Public IP Once you have found the IP address, and configured your router, you can log in by typing:
Terminal
```
ssh username@public_ip_address
```

If you are exposing your home machine to the Internet, it is a good idea to implement some security measures. The most basic one is to configure your router to accept SSH traffic on a non-standard port and to forward it to port 22 on the machine running the SSH service.

You can also set up an SSH key-based authentication and connect to your Ubuntu machine without entering a password.

Disabling SSH on Ubuntu

To turn off the SSH server on any of the supported Ubuntu releases, disable and stop both systemd units at once:

Terminal
sudo systemctl disable --now ssh.service ssh.socket

Only one of these units is normally enabled. Specifying both prevents ssh.socket from continuing to listen on port 22 and starting the service when a client connects.

Later, to re-enable SSH on Ubuntu 24.04 or 26.04, enable and start the socket:

Terminal
sudo systemctl enable --now ssh.socket

On Ubuntu 20.04 or 22.04, enable and start the service instead:

Terminal
sudo systemctl enable --now ssh.service

Troubleshooting

SSH service fails to start
Run sudo journalctl -u ssh.service -u ssh.socket to see the error. A common cause is a misconfigured /etc/ssh/sshd_config. Test the config with sudo sshd -t before restarting the service or socket.

Connection refused on port 22
Confirm that SSH is running with sudo systemctl status ssh.service ssh.socket. If UFW is active, verify the rule is in place with sudo ufw status and re-run sudo ufw allow ssh if it is missing. Our guide on the SSH connection refused error covers the rest of the checks, from the listening address to the network path.

Host key verification failed
This happens when the remote host’s key has changed (for example, after a reinstall). Remove the old entry with ssh-keygen -R ip_address and reconnect.

Permission denied (publickey)
If you use key-based auth, ensure the correct private key is available (~/.ssh/id_rsa or ~/.ssh/id_ed25519) and that ~/.ssh/authorized_keys on the server contains the matching public key with permissions 600.

FAQ

Does this work on Ubuntu 20.04, 22.04, 24.04, and 26.04?
Yes. All four releases use the openssh-server package. Ubuntu 20.04 and 22.04 run ssh.service at boot, while Ubuntu 24.04 and 26.04 listen through ssh.socket and start the service when a client connects.

What port does SSH use by default?
SSH uses port 22 by default. You can change the default SSH port to reduce automated login attempts.

How do I connect without a password?
Set up SSH key-based authentication to log in using a key pair instead of a password.

How do I connect to multiple servers more easily?
Define your hosts in the SSH config file so you can connect with a short alias instead of typing the full address each time.

Conclusion

We have shown you how to install and enable SSH on Ubuntu systems. With SSH enabled, you can manage your system remotely, securely transfer files, and perform everyday administrative tasks without physical access.

If you manage multiple systems, you can simplify your workflow by defining all your connections in the SSH config file . Changing the default SSH port adds an extra layer of security to your system by reducing the risk of automated attacks.

How to Enable SSH on Raspberry Pi

hello@linuxize.com (Linuxize) — Tue, 14 May 2019 19:31:47 +0100

Secure Shell (SSH) is a network protocol that lets you securely connect to your Raspberry Pi over an encrypted connection without needing a monitor or keyboard attached. With SSH enabled, you can run commands remotely, transfer files using tools like scp , and manage your Pi from any machine on the network.

Raspberry Pi OS ships with SSH disabled by default. This guide covers three ways to enable it: during OS installation with Raspberry Pi Imager, on a pre-imaged SD card without a screen, and from the desktop or terminal on a running system.

Enabling SSH During OS Installation

The cleanest approach is to configure SSH before you write the SD card. Raspberry Pi Imager handles this through its Customisation settings, so SSH is ready the moment the Pi boots.

Download and install Raspberry Pi Imager for your operating system.
Open Imager, select your Raspberry Pi device, choose Raspberry Pi OS, and select your storage device.
Click Next. If the image supports customisation, Imager opens the Customisation tab.
On the Hostname and User subtabs, set a hostname, username, and password. Current Raspberry Pi OS images no longer include a default account, so these credentials are required.
Open the Remote Access subtab. Turn on Enable SSH and choose password authentication or public key authentication.

To use public key authentication, paste the contents of your ~/.ssh/id_rsa.pub or ~/.ssh/id_ed25519.pub file into the field. If you do not have a key pair yet, generate one first .
Continue through any remaining subtabs, save the customisation settings, and write the image to the card.

When the Pi boots from this card, SSH will be active and you can connect immediately using the credentials you configured.

Enabling SSH on a Pre-Imaged SD Card (Headless)

If you already have an SD card with Raspberry Pi OS installed and no monitor available, you can enable SSH by placing an empty file named ssh in the boot partition. The OS checks for this file on startup and enables SSH automatically if it finds it.

This method only enables the SSH service. You still need a configured user account and, for Wi-Fi-only setups, working network settings. For a new headless install, Raspberry Pi Imager is usually safer because it sets the user, network, and SSH options together.

Power off your Raspberry Pi and remove the SD card.
Insert the SD card into your computer. It mounts automatically.
Navigate to the boot partition. On current Raspberry Pi OS images it is usually labeled bootfs; on older images it may be labeled boot.
Create a new empty file named exactly ssh with no extension.

On Linux or macOS, open a terminal and run the following command, replacing the path with your actual mount point:
Terminal
```
touch /media/$USER/bootfs/ssh
```
On Windows, right-click inside the partition in File Explorer, create a new text file, and rename it to ssh removing the .txt extension.
Eject the SD card, insert it back into the Pi, and power it on. The Pi detects the file on boot, enables SSH, and removes the file automatically.

Enabling SSH With a Monitor Attached

If you have a monitor and keyboard connected, you can enable SSH through the graphical configuration tool, through raspi-config in the terminal, or by starting the service directly with systemctl.

From the Raspberry Pi Configuration Tool

Open the Raspberry Pi menu and go to Preferences > Control Centre.
Open the Interfaces tab.
Turn on the toggle next to SSH.
Click Close and reboot if prompted.

From raspi-config in the Terminal

Open a terminal and launch the configuration tool:

Terminal
sudo raspi-config

Use the arrow keys to select 3 Interface Options > I1 SSH. Confirm that you want to enable the SSH server, then select OK and Finish.

Alternatively, you can enable and start the SSH service in one step with systemctl:

Terminal
sudo systemctl enable --now ssh

Connecting to Raspberry Pi via SSH

Once SSH is running, you need the Pi’s IP address. On the Pi itself, run:

Terminal
hostname -I

output

192.168.1.42

If you are setting up headlessly, check your router’s DHCP client list instead.

From your computer, connect using the ssh command with the username and IP address you configured:

Terminal
ssh username@192.168.1.42

The first time you connect, SSH displays a fingerprint warning. Type yes to accept it and add the host to your known hosts file.

output

The authenticity of host '192.168.1.42 (192.168.1.42)' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Windows users can use the built-in ssh client from PowerShell or Command Prompt, or a graphical client like PuTTY .

If you are exposing the Pi to the internet, changing the default SSH port reduces automated login attempts. Setting up key-based authentication removes the need to type a password on every connection.

Troubleshooting

Connection refused
SSH is not running or was not enabled on boot. If you have local access, run sudo systemctl status ssh and start it with sudo systemctl enable --now ssh.

No route to host or connection timed out
The Pi is not reachable on the network. Check that it is powered on, connected to Ethernet or Wi-Fi, and using the IP address shown by your router or hostname -I.

Permission denied
The username, password, or SSH key does not match the account configured on the Pi. Recheck the username you set in Raspberry Pi Imager and make sure the public key was copied correctly.

The hostname does not resolve
If raspberrypi.local or your custom hostname does not work, connect with the Pi’s IP address instead.

Conclusion

You now have SSH enabled on your Raspberry Pi and can connect remotely from any machine on the network. To manage connections more easily, define your Pi in the SSH config file so you can connect with a short alias instead of typing the full address each time.

Using the SSH Config File

hello@linuxize.com (Linuxize) — Sun, 06 Jan 2019 19:31:47 +0100

If you are regularly connecting to multiple remote systems via SSH, remembering various IP addresses, usernames, non-standard ports, and command-line options can be challenging or even impossible.

One approach is to create a bash alias for each remote server connection. However, there is a better, more straightforward solution. OpenSSH allows you to set up a per-user configuration file where you can store different SSH options for each remote machine you connect to.

This guide covers the basics of the SSH client configuration file and highlights some of the most common options.

SSH Config File Location

The OpenSSH client-side configuration file is named config, and resides in the .ssh directory under the user’s home directory. The examples in this guide assume you are using Linux or macOS with an OpenSSH client installed.

The ~/.ssh directory is created automatically when the user runs the ssh command for the first time. If the directory does not exist on your system, create it with:

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

By default, the SSH configuration file may not exist, so you may need to create it using the touch command :

Terminal
touch ~/.ssh/config

For security, the file must be readable and writable only by the user and not accessible by others:

Terminal
chmod 600 ~/.ssh/config

SSH Config File Structure and Patterns

The SSH config file takes the following structure:

ini
Host hostname1
 SSH_OPTION value
 SSH_OPTION value

Host hostname2
 SSH_OPTION value

Host *
 SSH_OPTION value

The contents of the SSH client config file are organised into stanzas (sections).

Each stanza begins with the Host directive and contains specific SSH options that apply when connecting to matching hosts.

Indentation is not required, but it is recommended because it makes the file easier to read.

Lines beginning with # are treated as comments and ignored by SSH, which makes them useful for documenting aliases or temporarily disabling options.

The Host value can be a single hostname, IP address, or pattern, or a space-separated list of patterns. Each pattern can contain zero or more non-whitespace characters or one of the following pattern specifiers:

* - Matches zero or more characters. (e.g, Host * matches all hosts, while 192.168.0.* matches hosts in the 192.168.0.0/24 subnet.)
? - Matches exactly one character. (e.g The pattern, Host 10.10.0.? matches all hosts in 10.10.0.[0-9] range.)
! - When used at the start of a pattern, it negates the match. (e.g Host 10.10.0.* !10.10.0.5 matches any host in the 10.10.0.0/24 subnet except 10.10.0.5.)

The SSH client processes the file from top to bottom. If more than one pattern matches, the options from the first matching stanza take precedence. Therefore, more host-specific declarations should be given at the beginning of the file, and more general overrides (like Host *) at the end of the file.

You can find a full list of available SSH options by typing man ssh_config in your terminal or by visiting the ssh_config man page .

The SSH config file is also read by other programs such as scp , sftp , and rsync .

Basic Example

Now that we have covered the basics of the SSH configuration file, let us look at the following example.

Normally, when connecting to a remote server via SSH, you would specify the remote user name, hostname, and port. For example, to log in as a user named john to a host called dev.example.com on port 2322 from the command line, you would type:

Terminal
ssh john@dev.example.com -p 2322

To connect to the server using the same options as provided in the command above by typing ssh dev, add the following lines in your ~/.ssh/config file:

~/.ssh/configini
Host dev
 HostName dev.example.com
 User john
 Port 2322

Now, when you type ssh dev, the ssh client will read the configuration file and use the connection details that are specified for the dev host:

Terminal
ssh dev

Advanced Example: Patterns and Precedence

This example gives more detail about host patterns and option precedence.

Consider the following example file:

ini
Host targaryen
 HostName 192.168.1.10
 User daenerys
 Port 7654
 IdentityFile ~/.ssh/targaryen.key

Host tyrell
 HostName 192.168.10.20

Host martell
 HostName 192.168.10.50

Host *ell
 user oberyn

Host * !martell
 LogLevel INFO

Host *
 User root
 Compression yes

When you type ssh targaryen, the SSH client reads the file and applies the options from the first match, which is Host targaryen. Then it checks the next stanzas one by one for a matching pattern. The next matching one is Host * !martell (meaning all hosts except martell), and it will apply the connection option from this stanza. The last definition Host * also matches, but the SSH client will take only the Compression option because the User option is already defined in the Host targaryen stanza.

The full list of options used when you type ssh targaryen is as follows:
ini
```
HostName 192.168.1.10
User daenerys
Port 7654
IdentityFile ~/.ssh/targaryen.key
LogLevel INFO
Compression yes
```
When running ssh tyrell, the matching host patterns are: Host tyrell, Host *ell, Host * !martell, and Host *. The options used in this case are:
ini
```
HostName 192.168.10.20
User oberyn
LogLevel INFO
Compression yes
```
If you run ssh martell, the matching host patterns are: Host martell, Host *ell and Host *. The options used in this case are:
ini
```
HostName 192.168.10.50
User oberyn
Compression yes
```
For all other connections, the SSH client will use the options specified in the Host * !martell and Host * sections.

Overriding Options

The SSH client reads its configuration in the following precedence order:

Options specified from the command line.
Options defined in the ~/.ssh/config.
Options defined in the system-wide /etc/ssh/ssh_config file.

To override a single option, specify it on the command line. For example, if you have the following definition:

ini
Host dev
 HostName dev.example.com
 User john
 Port 2322

and you want to use all other options but connect as user root instead of john, simply specify the user on the command line:

Terminal
ssh -o "User=root" dev

The -F (configfile) option allows you to specify an alternative per-user configuration file.

To tell the SSH client to ignore all of the options specified in the SSH configuration file, use:

Terminal
ssh -F /dev/null user@example.com

Common SSH Config Options

Here are some of the most useful directives you will reach for regularly.

Keep connections alive

SSH connections drop when there is no traffic for a period of time. To prevent this, configure keepalive packets in a Host * block at the end of your config:

~/.ssh/configini
Host *
 ServerAliveInterval 60
 ServerAliveCountMax 3

ServerAliveInterval sends a keepalive packet every 60 seconds. ServerAliveCountMax closes the connection after 3 unanswered packets.

Specify a private key

If you use different keys for different servers, set IdentityFile per host:

~/.ssh/configini
Host github.com
 User git
 IdentityFile ~/.ssh/github_key

Connect through a jump host

ProxyJump routes your connection through an intermediate server. This replaces the older ProxyCommand approach:

~/.ssh/configini
Host internal
 HostName 10.0.0.50
 User admin
 ProxyJump jumphost.example.com

Now ssh internal connects through jumphost.example.com automatically.

Enable SSH agent forwarding

When you need to authenticate to a second server from within an SSH session, enable agent forwarding selectively — only for hosts that require it:

~/.ssh/configini
Host bastion
 HostName bastion.example.com
 ForwardAgent yes

Avoid setting ForwardAgent yes in a Host * block, as it exposes your SSH agent to every server you connect to.

Quick Reference

Directive	Description
`Host`	Pattern to match one or more hosts
`HostName`	The actual hostname or IP address to connect to
`User`	SSH username
`Port`	Remote port (default: 22)
`IdentityFile`	Path to the private key file
`ServerAliveInterval`	Seconds between keepalive packets
`ServerAliveCountMax`	Unanswered keepalives before disconnect
`ProxyJump`	Connect through a jump host
`ForwardAgent`	Enable SSH agent forwarding
`Compression`	Enable compression (`yes`/`no`)
`LogLevel`	Verbosity level (`QUIET`, `INFO`, `DEBUG`)
`StrictHostKeyChecking`	Control known_hosts checking

For a printable quick reference, see the SSH cheatsheet .

Troubleshooting

Options are not being applied
The file permissions must be exactly 600 (-rw-------). If the file is readable by others, OpenSSH ignores it entirely. Fix with chmod 600 ~/.ssh/config. Also check that your Host pattern actually matches the alias you are using.

“Bad configuration option” error
There is a typo in a directive name. SSH config directives are case-insensitive but must be spelled correctly. Check the directive against man ssh_config.

“Permission denied (publickey)” despite setting IdentityFile
Verify the path in IdentityFile is correct and the key file permissions are 600. You can test which key is being offered with ssh -v alias and look for lines starting with Offering public key.

Config works with ssh but not scp or rsync
Both scp and rsync (over SSH) read ~/.ssh/config. Check that the Host pattern matches the hostname or alias you pass to those commands, not just the alias you use with ssh.

FAQ

Where is the SSH config file located?
The per-user SSH config file is at ~/.ssh/config. A system-wide config for all users is at /etc/ssh/ssh_config. Settings in ~/.ssh/config override /etc/ssh/ssh_config for your user.

What is the difference between ~/.ssh/config and /etc/ssh/ssh_config?
~/.ssh/config is your personal config — only your user account reads it. /etc/ssh/ssh_config applies to all users on the system and is managed by the system administrator. Your personal config takes precedence for any options it defines.

Can I have multiple Host entries pointing to the same server?
Yes. You can define multiple stanzas with different aliases that connect to the same HostName, each with different options — for example, one for a regular user and one for root access.

How do I apply an option to all hosts?
Add a Host * stanza at the end of your config file. Options in Host * apply to every connection but have the lowest precedence — any host-specific option defined earlier in the file takes priority.

Does the SSH config file work with scp and sftp?
Yes. scp, sftp, and rsync (when using SSH transport) all read ~/.ssh/config and respect the same host aliases and options.

Conclusion

The SSH config file is the most practical way to manage connections to multiple remote servers. Once your aliases are in place, tools like scp, sftp, and rsync pick them up automatically. To further simplify logins, set up SSH key-based authentication so you can connect without entering a password each time.

How to Change the SSH Port in Linux

hello@linuxize.com (Linuxize) — Sat, 16 Mar 2019 03:40:24 +0100

By default, SSH listens on port 22. Changing the default SSH port adds an extra layer of security to your server by reducing the risk of automated attacks.

This tutorial explains how to change the default SSH port in Linux. We will also show you how to configure your firewall to allow access to the new SSH port.

Info

The best way to protect your server from attacks is to configure your firewall to allow access to port 22 only from trusted hosts and set up an SSH key-based authentication .

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Step	Command
Open firewall port	`sudo ufw allow 5522/tcp`
Edit SSH config	`sudo vim /etc/ssh/sshd_config`
Set new port	`Port 5522`
Restart SSH	`sudo systemctl restart ssh`
Verify listening	`ss -tlnp
Connect to new port	`ssh -p 5522 user@host`

Changing the SSH Port

Changing the SSH port of a Linux server is a simple task. All you need to do is to edit the SSH configuration file and restart the service.

The following sections explain how to change the SSH Port on a Linux system.

1. Choosing a New Port Number

In Linux, port numbers below 1024 are reserved for well-known services and can only be bound to by root. Although you can use a port within a 1-1024 range for the SSH service to avoid issues with port allocation in the future, it is recommended to choose a port above 1024.

In this example we will change the SSH port to 5522, you can choose any port you want.

2. Adjusting Firewall

Before changing the SSH port, you will need to adjust your firewall to allow traffic on the new SSH port.

If you are using UFW , the default firewall configuration tool for Ubuntu, run the following command to open the new SSH port:

Terminal
sudo ufw allow 5522/tcp

In CentOS, the default firewall management tool is FirewallD. To open the new port run:

Terminal
sudo firewall-cmd --permanent --zone=public --add-port=5522/tcp
sudo firewall-cmd --reload

CentOS users also need to adjust the SELinux rules:

Terminal
sudo semanage port -a -t ssh_port_t -p tcp 5522

On RHEL, Fedora, and derivatives where semanage is not available, install it with:

Terminal
sudo dnf install policycoreutils-python-utils

If you are using nftables, add a rule to accept the new port:

Terminal
sudo nft add rule inet filter input tcp dport 5522 accept

If you are using iptables as your firewall, to open the new port, run:

Terminal
sudo iptables -A INPUT -p tcp --dport 5522 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

3. Configuring SSH

Open the SSH configuration file /etc/ssh/sshd_config with your text editor:

Terminal
sudo vim /etc/ssh/sshd_config

Search for the line starting with Port 22. In most cases, this line starts with a hash (#) character. Remove the hash # and enter the new SSH port number:

/etc/ssh/sshd_configini
Port 5522

Be extra careful when modifying the SSH configuration file. The incorrect configuration may cause the SSH service to fail to start.

On Ubuntu 22.10 and later, including 24.04, OpenSSH may be started through ssh.socket. In that case, changing Port in sshd_config is not enough because the socket can still listen on port 22. Check whether socket activation is enabled:

Terminal
systemctl is-active ssh.socket

If the output is active, create a drop-in to override the listening port:

Terminal
sudo systemctl edit ssh.socket

Add the following, clearing the existing listeners with an empty ListenStream= before setting the new one:

/etc/systemd/system/ssh.socket.d/override.confini
[Socket]
ListenStream=
ListenStream=5522

Reload systemd and restart the socket:

Terminal
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Once done, apply the changes. If ssh.socket is not active, restart the SSH service:

Terminal
sudo systemctl restart ssh

In CentOS the ssh service is named sshd:

Terminal
sudo systemctl restart sshd

To verify that SSH daemon is listening on the new port 5522, use ss :

Terminal
ss -an | grep 5522

The output should look something like this:

output

tcp LISTEN 0 128 0.0.0.0:5522 0.0.0.0:*
tcp ESTAB 0 0 192.168.121.108:5522 192.168.121.1:57638
tcp LISTEN 0 128 [::]:5522 [::]:*

Using the New SSH Port

To specify the port, invoke the ssh command followed by the -p <port_number> option:

Terminal
ssh -p 5522 username@remote_host_or_ip

If you are regularly connecting to multiple systems, you can simplify your workflow by defining all of your connections in the SSH config file .

Troubleshooting

Connection refused after changing the port
Confirm the SSH daemon is listening on the new port with ss -tlnp | grep sshd. If the output still shows port 22, the daemon did not pick up the change. On Ubuntu 22.10 and later check socket activation; otherwise restart with sudo systemctl restart sshd.

Error: Permission denied or SELinux blocks the new port
SELinux only allows SSH on ports defined in the ssh_port_t type. Run sudo semanage port -a -t ssh_port_t -p tcp 5522. Confirm with sudo semanage port -l | grep ssh.

Firewall rule not persisted after reboot
UFW and FirewallD persist rules by default. With plain iptables, save the rules with sudo iptables-save > /etc/iptables/rules.v4 or use the iptables-persistent package.

Cannot connect after editing sshd_config
Test the config syntax before restarting: sudo sshd -t. Keep an existing SSH session open while testing changes so that a fresh session can be opened from another terminal to verify.

Conclusion

You have changed the default SSH port on a Linux server and adjusted the firewall to allow traffic on the new port. For a stronger layer of security, also set up SSH key-based authentication and restrict SSH access to trusted IPs in your firewall.

The ~/.ssh Folder: Files, Permissions, and Layout

hello@linuxize.com (Linuxize) — Tue, 16 Jun 2026 10:15:00 +0200

When SSH stops accepting a key after you copy files to a new computer, restore a backup, or change ownership, the first place to check is ~/.ssh. OpenSSH uses this directory for your private and public keys, trusted host records, and per-host connection settings.

Some files inside the directory are public, while others must stay private. This guide explains what each file does, which permissions to use, and how the layout differs between an SSH client and server.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Path	Purpose	Permissions
`~/.ssh/`	The directory itself	`700`
`~/.ssh/id_ed25519`, `id_rsa`	Private keys	`600`
`~/.ssh/id_ed25519.pub`, `id_rsa.pub`	Public keys	`644`
`~/.ssh/authorized_keys`	Public keys allowed to log in to this account	`600`
`~/.ssh/known_hosts`	Host keys of servers you have connected to	`644`
`~/.ssh/config`	Client config and per-host shortcuts	`600`

Where the Folder Lives

The ~/.ssh directory sits inside your home directory. OpenSSH tools create it when needed, such as when you generate a key or connect to a host for the first time.

You can confirm the location with:

Terminal
ls -ld ~/.ssh

output

drwx------ 2 sara sara 4096 Mar 4 14:22 /home/sara/.ssh

In this output, sara owns the directory and rwx------ corresponds to mode 700. This gives the owner full access while blocking everyone else.

OpenSSH does not require every file in the directory to be secret. However, group or world write access can make the server reject authorized_keys, while loose private-key permissions make the client ignore that key.

Private and Public Keys

When you generate a key pair with ssh-keygen, two files land in ~/.ssh:

Terminal
ssh-keygen -t ed25519 -C "sara@workstation"

output

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sara/.ssh/id_ed25519):

Press Enter to accept the default path. After the key is generated, you will have two new files:

id_ed25519 is the private key. It must stay on the machine where you generated it and must never be shared. Permissions are 600 (owner read/write only). If the file is even readable by the group, OpenSSH refuses to use it.
id_ed25519.pub is the public key. It is meant to be copied to other machines, pasted into hosting dashboards, or added to ~/.ssh/authorized_keys on servers. Permissions are usually 644.

You may also see id_rsa and id_rsa.pub on older systems. OpenSSH recognizes these default names and tries them automatically when no IdentityFile is set. For new keys, Ed25519 is the better default because the keys are smaller and authentication is fast.

authorized_keys

On the server side, ~/.ssh/authorized_keys lists the public keys that are allowed to log in as this user. Each line is one full public key, exactly as it appears in a .pub file on the client.

Terminal
cat ~/.ssh/authorized_keys

output

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE2... sara@workstation
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPgs... sara@laptop

Each line grants access to one public key. The optional comment at the end, such as sara@workstation, helps you identify where the key came from.

The file must belong to the account that uses it and must not be writable by other users. Mode 600 is the recommended setting. With StrictModes enabled (the default), the SSH server also checks the parent path, so your home directory must not be group- or world-writable even if ~/.ssh itself is correct.

To copy a public key to a server, use ssh-copy-id instead of editing the file manually:

Terminal
ssh-copy-id sara@example.com

The command appends your public key and avoids replacing keys that are already in the file.

known_hosts

The ~/.ssh/known_hosts file records the host keys of servers you have connected to before. The first time you SSH into a new host, OpenSSH prints the host fingerprint and asks you to confirm. After you accept, the key is appended here, and any future change to that host key triggers a sharp warning instead of a silent reconnect.

Terminal
ssh-keygen -F example.com

output

# Host example.com found: line 3
|1|abc...=|def...= ssh-ed25519 AAAAC3Nz...

The output shows the matching entry and its line number. The leading |1| means the hostname is hashed. OpenSSH uses this format when HashKnownHosts yes is enabled in the client configuration. The upstream default is no, although your Linux distribution may enable it in /etc/ssh/ssh_config.

When a server gets a new host key, such as after a reinstall, remove only the old entry instead of deleting the whole file:

Terminal
ssh-keygen -R example.com

Mode 644 is common because the file contains public host keys. On a shared machine, you can use mode 600 to stop other users from reading unhashed server names.

config

The ~/.ssh/config file is where per-host shortcuts and per-host options live. A short example:

~/.ssh/configtxt
Host work-server
 HostName example.com
 User sara
 Port 2222
 IdentityFile ~/.ssh/id_ed25519_work
 IdentitiesOnly yes

Host *
 ServerAliveInterval 60
 ServerAliveCountMax 3

With this configuration, ssh work-server connects to example.com on port 2222 as sara and uses only the specified key. The Host * block applies to every host, which makes it a useful place for defaults such as keepalives.

OpenSSH uses the first value it finds for each option. Put specific host blocks at the top and general settings at the bottom.

OpenSSH requires that ~/.ssh/config is not writable by other users. Mode 600 also prevents other users on the machine from reading your hostnames and account names.

Reset SSH Permissions

If the permissions changed after copying or restoring the directory, use the following commands to reset the standard files:

sh
chmod 700 ~/.ssh
find ~/.ssh -maxdepth 1 -type f -name 'id_*' ! -name '*.pub' -exec chmod 600 {} +
find ~/.ssh -maxdepth 1 -type f -name '*.pub' -exec chmod 644 {} +
for file in authorized_keys config; do
 [ -e "$HOME/.ssh/$file" ] && chmod 600 "$HOME/.ssh/$file"
done
[ -e ~/.ssh/known_hosts ] && chmod 644 ~/.ssh/known_hosts

The first find command sets mode 600 on private keys, while the second sets mode 644 on public keys. The remaining checks update only files that exist, so you can run the block on a client or server account without errors for missing files.

Client vs Server Layout

The same ~/.ssh directory holds different files depending on whether the machine acts as a client or a server in a given session.

A typical client has:

Terminal
ls ~/.ssh

output

config id_ed25519 id_ed25519.pub known_hosts

This client has a key pair, a connection configuration, and a record of known servers.

A typical server account has:

Terminal
ls ~/.ssh

output

authorized_keys

The server only needs authorized_keys to accept key-based logins for this account. A machine can also be both a client and a server. For example, your workstation may use private keys for outgoing connections and keep authorized_keys for incoming SCP transfers.

Troubleshooting

Permissions 0644 for '~/.ssh/id_ed25519' are too open
The private key is readable by the group or by everyone. Run chmod 600 ~/.ssh/id_ed25519 and retry.

Authentication refused: bad ownership or modes for directory /home/sara
OpenSSH checks the whole path. The home directory is group-writable, which lets another user replace .ssh. Run chmod go-w ~ on the server.

Public key copied but login still fails
Confirm the key was appended, not overwritten, in authorized_keys. Compare fingerprints with ssh-keygen -lf ~/.ssh/id_ed25519.pub on the client and ssh-keygen -lf ~/.ssh/authorized_keys on the server.

FAQ

Can I move ~/.ssh to a different path?
Yes, but you must configure the new path. On the client, pass -i or set IdentityFile for each host. On the server, set AuthorizedKeysFile in /etc/ssh/sshd_config. Keeping the default layout is usually simpler.

Is it safe to back up ~/.ssh?
Public keys can be backed up freely. The config and known_hosts files can expose account names and server addresses, so keep those backups private. Treat private keys like passwords: encrypt the backup and never store it in a public cloud bucket or Git repository.

Why does OpenSSH care about home-directory permissions?
If your home directory is group-writable, another user can replace ~/.ssh with their own. To prevent that class of attack, OpenSSH refuses to use a ~/.ssh reachable through a too-permissive path.

Conclusion

Use mode 700 for the directory, 600 for private keys and authorized_keys, and 644 for public keys and known_hosts. When key authentication fails after a file copy or restore, checking these modes is a good first step.

For related reading, see our guides on generating SSH keys and the ssh-copy-id command .

How to Generate SSH Keys on Linux with ssh-keygen

hello@linuxize.com (Linuxize) — Fri, 23 Jan 2026 14:00:00 +0100

Secure Shell (SSH) is a network protocol for creating a secure connection between a client and a server. With SSH, you can run commands on remote machines, create tunnels, forward ports, and more.

SSH provides multiple authentication mechanisms. The two most common authentication methods are password-based and public-key-based. Public-key authentication is more secure and convenient than traditional password authentication.

This guide shows you how to create SSH keys on Linux with ssh-keygen, which key type to pick, and where to install the public key once you have it.

Quick Reference

Command	Description
`ssh-keygen -t ed25519`	Generate Ed25519 key pair
`ssh-keygen -t rsa -b 4096`	Generate RSA key pair
`ssh-copy-id user@host`	Copy public key to server
`ssh-add ~/.ssh/id_ed25519`	Add key to SSH agent
`ssh-add -l`	List keys in agent
`ssh-add -D`	Remove all keys from the agent
`cat ~/.ssh/id_ed25519.pub`	Display public key

Prerequisites

Before you begin, make sure you have:

A Linux system with an SSH client installed (included by default on most distributions)
Somewhere to install the public key, such as a remote server, a Git hosting account, or a cloud provider

Check for Existing SSH Keys

Before generating a new key pair, check if you already have SSH keys on your system:

Terminal
ls -l ~/.ssh/id_*.pub

If you see files like id_rsa.pub or id_ed25519.pub, you already have SSH keys. You can either use the existing keys or generate new ones. Generating a new key pair with the same name will overwrite the old one.

If the command returns No such file or directory, you don’t have SSH keys and may proceed with generating a new pair.

Generate an SSH Key Pair

The ssh-keygen command creates a new SSH key pair. You can choose between different key types:

Ed25519 (recommended) - Modern, secure, and fast
RSA - Widely compatible, use 4096 bits for security

Generate an Ed25519 Key (Recommended)

Ed25519 keys are shorter, faster, and considered more secure than RSA keys:

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

Generate an RSA Key

If you need compatibility with legacy systems that don’t support Ed25519, use RSA with 4096 bits:

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

The -C flag adds a comment (usually your email) to help identify the key.

Key Generation Process

After running the command, you’ll be prompted to specify the file location:

output

Enter file in which to save the key (/home/username/.ssh/id_ed25519):

Press Enter to accept the default location, or specify a custom path.

Next, you’ll be prompted to enter a passphrase:

output

Enter passphrase (empty for no passphrase):

A passphrase adds another layer of security. If someone gets your private key, they’ll still need the passphrase to use it. Keep in mind, you’ll have to enter the passphrase each time you use the key unless you use an SSH agent.

Press Enter for no passphrase, or type a secure passphrase and confirm it.

The output will look similar to this:

output

Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:AbCdEf1234567890AbCdEf1234567890AbCdEf12 your_email@example.com

The command creates two files:

~/.ssh/id_ed25519 - Your private key (keep this secret)
~/.ssh/id_ed25519.pub - Your public key (safe to share)

Where to Put Your Public Key

Generating a key pair is only half the job. The public key (id_ed25519.pub) has to be installed wherever you want to authenticate, and the method depends on the destination. The private key never leaves your machine.

A Linux server you control. Install the key in the remote account’s authorized_keys file with ssh-copy-id:

Terminal
ssh-copy-id username@server_ip

You will be prompted for the remote user password once. After that the key is in place and the password prompts stop. Our guide on passwordless SSH login covers the full flow, including the manual copy method and how to disable password authentication afterwards.

GitHub, GitLab, or Bitbucket. These hosts have no shell account, so ssh-copy-id does not apply. Print the public key and paste the output into the SSH key settings of your account:

Terminal
cat ~/.ssh/id_ed25519.pub

output

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8k... your_email@domain.com

Then confirm the key works against the host endpoint. For GitHub:

Terminal
ssh -T git@github.com

A cloud provider. AWS, DigitalOcean, and Hetzner let you register a public key in the control panel and inject it into new instances at creation time. Paste the same output into the provider key form before launching the machine, and it lands in the default user’s authorized_keys automatically.

Using the SSH Agent

If you set a passphrase on your key, entering it for every connection can be tedious. The SSH agent stores your decrypted private key in memory, so you only need to enter the passphrase once per session.

Start the SSH agent:

Terminal
eval "$(ssh-agent -s)"

output

Agent pid 12345

Add your private key to the agent:

Terminal
ssh-add ~/.ssh/id_ed25519

You’ll be prompted for your passphrase. After entering it, subsequent SSH connections will use the cached key without asking for the passphrase again.

To list keys currently loaded in the agent:

Terminal
ssh-add -l

Managing SSH Keys

View Your Public Key

To display your public key (useful for adding to services like GitHub):

Terminal
cat ~/.ssh/id_ed25519.pub

List All Keys

To see all key files in your SSH directory:

Terminal
ls -la ~/.ssh/

Remove a Key from the Agent

To remove a specific key from the SSH agent:

Terminal
ssh-add -d ~/.ssh/id_ed25519

To remove all keys from the agent:

Terminal
ssh-add -D

Delete a Key Pair

To permanently delete a key pair, remove both the private and public key files:

Terminal
rm ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Troubleshooting

Permission Denied (publickey)

If you see this error, check the following:

Verify the public key is in the remote server’s ~/.ssh/authorized_keys:
Terminal
```
cat ~/.ssh/authorized_keys
```

Check permissions on the remote server:

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

Ensure the private key has correct permissions locally:
Terminal
```
chmod 600 ~/.ssh/id_ed25519
```

SSH Agent Not Running

If you get an error about the agent, start it with:

Terminal
eval "$(ssh-agent -s)"

Wrong Key Being Used

To specify which key to use for a connection:

Terminal
ssh -i ~/.ssh/my_custom_key username@server_ip

For permanent configuration, add an entry to ~/.ssh/config:

~/.ssh/configconf

Host myserver
HostName server_ip
User username
IdentityFile ~/.ssh/my_custom_key

Then connect using:

Terminal
ssh myserver

Conclusion

A single key pair works across every destination that accepts one, so generating a good key once and keeping the private half safe matters more than repeating the process per host.

To keep your SSH connections organized, check out our guide on using the SSH config file . You can also change the default SSH port for extra security. If a key stops working after you copy files to a new machine or restore a backup, our guide to the files and permissions in the ~/.ssh folder shows what each file should contain and the mode it needs.

If you have questions or feedback, feel free to leave a comment.

Generate SSH Keys on Windows with PuTTYgen

hello@linuxize.com (Linuxize) — Sun, 05 May 2019 03:40:24 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server and supports various authentication mechanisms.

The two most popular mechanisms are passwords based authentication and public key-based authentication. Using SSH keys is more secure and convenient than traditional password authentication.

This tutorial explains how to generate SSH keys on Windows with PuTTYgen. We will also show you how to set up an SSH key-based authentication and connect to your remote Linux servers without entering a password.

Downloading PuTTYgen

PuTTYgen is an open-source utility that allows you to generate SSH keys for the most popular Windows SSH client PuTTY .

PuTTYgen is available as a standalone executable file, and it is also a part of the PuTTY .msi installation package. If you don’t have PuTTYgen installed, head over to the PuTTY download page and download the PuTTY installation package. The installation is simple, double-click on the installation package and follow the instructions.

Creating SSH keys with PuTTYgen

To generate an SSH key pair on Windows using PuTTYgen, perform the following steps:

Launch PuTTYgen by double-clicking on its “.exe” file or by going to the Windows Start menu → PuTTY (64-bit) → PuTTYgen.

In the “Type of key to generate” block leave the default RSA. In the “Number of bits in a generated key” field leave the default value 2048, which is sufficient for most use cases. Optionally, you can change it to 4096.
Click the “Generate” button to start the process of generating the new key pair.

You will be asked to move your mouse over the blank area of the Key section to generate some randomness. As you move the pointer, the green progress bar will advance. The process should take a few seconds.
Once the public key is generated it will be displayed in the “Key” block.

If you want set a passphrase, type it in the “Key passphrase” field and confirm the same passphrase in the “Confirm passphrase” field. If you don’t want to use a passphrase leave the fields blank.

It is recommended to use a passphrase when the private key files are intended for interactive use. Otherwise, when generating a key for automation, it may be set without a passphrase.

A passphrase adds an extra layer of security by protecting the private key from unauthorized use.

When a passphrase is set, it needs to be typed each time the private key is used.
Save the private key by clicking the “Save private key” button. You can save the file in any directory as a “.ppk” file (PuTTY Private Key), but it is advisable to save in a place where you can easily find it. It’s common to use a descriptive name for the private key file.

Optionally, you can also save the public key, though it can be regenerated later by loading the private key.
Right-click in the text field labeled “Public key for pasting into OpenSSH authorized_keys file” and select all characters by clicking “Select all”. Open a text editor, paste the characters and save it. Be sure you are pasting the entire key. It is advisable to save the file in the same directory where you saved the private key, using the same name the private key and “.txt” or “.pub” as a file extension.

This is the key that you should add to your remote Linux server.

Copying the Public Key to the Server

Now that the SSH key pair is generated, the next step is to copy the public key to the server you want to manage.

Launch the PuTTY program and login to your remote Linux server.

If your user SSH directory does not exist, create it with the mkdir command and set the correct permissions:

Terminal
mkdir -p ~/.ssh
chmod 0700 ~/.ssh

Open a text editor and paste the public key that you copied in step 4 when generating the key pair into the ~/.ssh/authorized_keys file:

Terminal
nano ~/.ssh/authorized_keys

The entire public key text must be on a single line.

Run the following chmod command to ensure only your user can read and write the ~/.ssh/authorized_keys file:

Terminal
chmod 0600 ~/.ssh/authorized_keys

Pageant is a PuTTY SSH authentication agent that holds the private keys in the memory. Pageant binary is a part of the PuTTY .msi installation package and can be launch by going to the Windows Start menu → PuTTY (64-bit) → Pageant.

When you start Pageant, it will place an icon into the system tray. Double-click on the icon, and the Pageant window will open.

To load a key, press the “Add Key” button, which will open a new file dialog. Locate the private key file, and press “Open”. If you haven’t set a passphrase, the key will be loaded in immediately. Otherwise, you will be prompted to enter the passphrase.

Enter the password, and Pageant will load the private key.

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To test it out, open a new PuTTY SSH session and try to login into the remote server. PuTTY will use the loaded key, and you will be logged into the server without entering the password.

Disabling SSH Password Authentication

To add an extra layer of security to your server, you can disable password authentication for SSH.

Before disabling the SSH password authentication make sure you can log in to your server without a password, and the user you are logging in with has sudo privileges .

Log into the remote server and open the SSH configuration file:

Terminal
sudo nano /etc/ssh/sshd_config

Search for the following directives and modify as it follows:

/etc/ssh/sshd_configini
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Once you are done, save the file and restart the SSH service by typing:

Terminal
sudo systemctl restart ssh

At this point, the password-based authentication is disabled.

Conclusion

In this tutorial, you have learned how to generate a new SSH key pair and set up an SSH key-based authentication. You can add the same key to multiple remote servers. We have also shown you how to disable SSH password authentication and add an extra layer of security to your server.

By default, SSH listens on port 22. Changing the default SSH port will reduce the risk of automated attacks.

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on Ubuntu 18.04

hello@linuxize.com (Linuxize) — Sat, 22 Sep 2018 03:40:24 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server and supports various authentication mechanisms.

The two most popular mechanisms are passwords based authentication and public key-based authentication. Using SSH keys is more secure and convenient than traditional password authentication.

In this tutorial, we will walk through how to generate SSH keys on Ubuntu 18.04 machines. We will also show you how to set up an SSH key-based authentication and connect to your remote Linux servers without entering a password.

Creating SSH keys on Ubuntu

Before generating a new SSH key pair first, check for existing SSH keys on your Ubuntu client machine. You can do that by running the following ls command :

Terminal
ls -l ~/.ssh/id_*.pub

If the command above prints something like No such file or directory or no matches found it means that you don’t have SSH keys on your client machine and you can proceed with the next step, and generate SSH key pair.

If there are existing keys, you can either use those and skip the next step or backup up the old keys and generate new ones.

Generate a new 4096 bits SSH key pair with your email address as a comment by typing:

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

The output will look something like this:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

Press Enter to accept the default file location and file name.

Next, you’ll be prompted to type a secure passphrase. Whether you want to use a passphrase, it’s up to you. If you choose to use a passphrase you will get an extra layer of security.

output

Enter passphrase (empty for no passphrase):

If you don’t want to use a passphrase just press Enter.

The whole interaction looks like this:

To verify your new SSH key pair is generated, type:

Terminal
ls ~/.ssh/id_*

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

Copy the Public Key to the Server

Now that you generated your SSH key pair, the next step is to copy the public key to the server you want to manage.

The easiest and the recommended way to copy your public key to the server is to use a utility called ssh-copy-id. On your local machine terminal type:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the public key ~/.ssh/id_rsa.pub will be appended to the remote user ~/.ssh/authorized_keys file and connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If by some reason the ssh-copy-id utility is not available on your local computer, you can use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

After completing the steps above you should be able to log in to the remote server without being prompted for a password.

To test it, try to login to your server via SSH:

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase for the private key, you will be logged in immediately. Otherwise, you will be prompted to enter the passphrase.

Disabling SSH Password Authentication

Disabling the password authentication adds an extra layer of security to your server.

Before disabling SSH password authentication, make sure you can log in to your server without a password, and the user you are logging in with has sudo privileges .

Log into your remote server:

Terminal
ssh sudo_user@server_ip_address

Open the SSH configuration file /etc/ssh/sshd_config with your text editor :

Terminal
sudo nano /etc/ssh/sshd_config

Search for the following directives and modify as it follows:

/etc/ssh/sshd_configini
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Once you are done, save the file and restart the SSH service by typing:

Terminal
sudo systemctl restart ssh

At this point, the password-based authentication is disabled.

Conclusion

By default, SSH listens on port 22. Changing the default SSH port reduces the risk of automated attacks.

If you are regularly connecting to multiple systems, you can simplify your workflow by defining all of your connections in the SSH config file .

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on Ubuntu 20.04

hello@linuxize.com (Linuxize) — Mon, 27 Jul 2020 18:40:24 +0100

Secure Shell (SSH) is a network protocol for creating a secure connection between a client and a server. With SSH, you can run commands on remote machines, create tunnels, forward ports, and more.

SSH supports various authentication mechanisms. The two most common ones are password and public-key based authentication.

Authentication using a public key is based on the use of digital signatures, and it is more secure and convenient than traditional password authentication.

This article explains how to generate SSH keys on Ubuntu 20.04 systems. We’ll also show you how to set up an SSH key-based authentication and connect to remote Linux servers without entering a password.

Creating SSH keys on Ubuntu

The chances are that you already have an SSH key pair on your Ubuntu client machine. If you generate a new key pair, the old one will be overwritten. To check whether the key files exist, run the following ls command:

Terminal
ls -l ~/.ssh/id_*.pub

If the command returns something like No such file or directory, or no matches found, it means that the user does not have SSH keys, and you can proceed with the next step and generate SSH key pair. Otherwise, if you have an SSH key pair, you can either the existing ones or backup up the old keys and generate a new pair.

To generate a new 4096 bits SSH key pair with your email address as a comment, run:

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

You will be prompted to specify the file name:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

The default location and file name should be fine for most users. Press Enter to accept and continue.

Next, you’ll be asked to type a secure passphrase. A passphrase adds an extra layer of security. If you set a passphrase, you’ll be prompted to enter it each time you use the key to login to the remote machine.

If you don’t want to set a passphrase, press Enter.

output

Enter passphrase (empty for no passphrase):

The whole interaction looks like this:

To verify your new SSH key pair is generated, type:

Terminal
ls ~/.ssh/id_*

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

That’s it. You’ve successfully generated an SSH key pair on your Ubuntu client machine.

Copy the Public Key to the Remote Server

Now that you have an SSH key pair, the next step is to copy the public key to the remote server you want to manage.

The easiest and the recommended way to copy the public key to the server is to use the ssh-copy-id tool. On your local machine type:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote user password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the public key ~/.ssh/id_rsa.pub will be appended to the remote user ~/.ssh/authorized_keys file, and the connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If by some reason the ssh-copy-id utility is not available on your local computer, use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To test it, try to login to your server via SSH:

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase for the private key, you will be logged in immediately. Otherwise, you will be prompted to enter the passphrase.

Disabling SSH Password Authentication

Disabling the password authentication adds an extra layer of security to your server.

Before disabling SSH password authentication, make sure you can log in to your server without a password, and the user you are logging in with has sudo privileges .

Log into your remote server:

Terminal
ssh sudo_user@server_ip_address

Open the SSH configuration file with your text editor :

Terminal
sudo nano /etc/ssh/sshd_config

Search for the following directives and modify as it follows:

/etc/ssh/sshd_configini
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Once done, save the file and restart the SSH service by typing:

Terminal
sudo systemctl restart ssh

At this point, the password-based authentication is disabled.

Conclusion

We’ve shown you how to generate a new SSH key pair and set up an SSH key-based authentication. You can use the same key to manage multiple remote servers. You have also learned how to disable SSH password authentication and add an extra layer of security to your server.

By default, SSH listens on port 22. Changing the default SSH port reduces the risk of automated attacks. To simplify your workflow, use the SSH config file to define all your SSH connections.

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on CentOS 7

hello@linuxize.com (Linuxize) — Sun, 07 Oct 2018 13:40:24 +0100

Secure Shell (SSH) is a cryptographic network protocol designed for a secure connection between a client and a server.

The two most popular SSH authentication mechanisms are password based authentication and public-key based authentication. Using SSH keys is generally more secure and convenient than traditional password authentication.

This tutorial explains how to generate SSH keys on CentOS 7 systems. We will also show you how to set up an SSH key-based authentication and connect to your remote Linux servers without entering a password.

Creating SSH keys on CentOS

Before generating a new SSH key pair, it is a good idea to check for existing SSH keys on your CentOS client machine.

To do so, run the following ls command that lists all public keys if there are any:

Terminal
ls -l ~/.ssh/id_*.pub

If the output of the command returns something like No such file or directory or no matches found it means that you don’t have SSH keys on your client machine, and you can proceed with the next step and generate SSH key pair.

If there are existing keys, you can either use those and skip the next step or backup up the old keys and generate new ones.

Start by generating a new 4096 bits SSH key pair with your email address as a comment:

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

You will be prompted to specify the file name:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

Press Enter to accept the default file location and file name.

Next, you’ll be asked to type a secure passphrase. Whether you want to use a passphrase, it’s up to you. If you choose to use a passphrase, you will get an extra layer of security.

output

Enter passphrase (empty for no passphrase):

If you don’t want to use a passphrase just press Enter.

The whole interaction looks like this:

To verify your new SSH key pair is generated, type:

Terminal
ls ~/.ssh/id_*

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

Copy the Public Key to CentOS Server

Now that the SSH key pair is generated, the next step is to copy the public key to the server you want to manage.

The easiest and the recommended way to copy the public key to the remote server is by using a utility called ssh-copy-id. On your local machine terminal type:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

output

remote_username@server_ip_address's password:

Type the password, and once the user is authenticated, the public key ~/.ssh/id_rsa.pub will be appended to the remote user ~/.ssh/authorized_keys file. The connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If the ssh-copy-id utility is not available on your local computer, use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To verify it, try to login to your server via SSH :

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase for the private key, you will be logged in immediately. Otherwise, you will be asked to enter the passphrase.

Disabling SSH Password Authentication

To add an additional layer of security to your remote server, you can disable SSH password authentication.

Before continuing, make sure you can log in to your server without a password as a user with sudo privileges .

Follow the steps below to disable SSH password authentication:

Log into your remote server:
Terminal
```
ssh sudo_user@server_ip_address
```
Open the SSH configuration file /etc/ssh/sshd_config with your text editor :
Terminal
```
sudo nano /etc/ssh/sshd_config
```
Search for the following directives and modify as it follows:
/etc/ssh/sshd_configini
```
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
```
Once you are done save the file and restart the SSH service by typing:
Terminal
```
sudo systemctl restart ssh
```

At this point, the password-based authentication is disabled.

Conclusion

In this tutorial, you have learned how to generate a new SSH key pair and set up an SSH key-based authentication. You can add the same key to multiple remote servers.

We have also shown you how to disable SSH password authentication and add an additional layer of security to your server.

By default, SSH listens on port 22. Changing the default SSH port reducess the risk of automated attacks.

If you are regularly connecting to multiple systems, you can simplify your workflow by defining all of your connections in the SSH config file .

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on CentOS 8

hello@linuxize.com (Linuxize) — Wed, 22 Apr 2020 20:50:54 +0100

Secure Shell (SSH) is a cryptographic network protocol designed for a secure connection between a client and a server.

The two most popular SSH authentication mechanisms are password-based authentication and public-key based authentication. Using SSH keys is generally more secure and convenient than traditional password authentication.

This article describes how to generate SSH keys on CentOS 8 systems. We’ll also show you how to set up an SSH key-based authentication and connect to remote Linux servers without entering a password.

Creating SSH keys on CentOS

The chances are that you already have an SSH key pair on your CentOS client machine. If you are generating a new key pair, the old one will be overwritten.

Run the following ls command to check whether the key files exist:

Terminal
ls -l ~/.ssh/id_*.pub

If the output of the command returns something like No such file or directory, or no matches found it means that the user does not have SSH keys, and you can proceed with the next step and generate SSH key pair.

Otherwise, if you have an SSH key pair, you can either use those or backup up the old keys and generate new ones.

To generate a new 4096 bits SSH key pair with your email address as a comment, run:

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

You will be prompted to specify the file name:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

Press Enter to accept the default file location and file name.

Next, you’ll be asked to type a secure passphrase. Whether you want to use passphrase, it’s up to you. A passphrase will add an extra layer of security. If you don’t want to use passphrase just press Enter.

output

Enter passphrase (empty for no passphrase):

The whole interaction looks like this:

To verify your new SSH key pair is generated, type:

Terminal
ls ~/.ssh/id_*

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

That’s it. You’ve successfully generated an SSH key pair on your CentOS client machine.

Copy the Public Key to the Server

Now that the SSH key pair is generated, the next step is to copy the public key to the server you want to manage.

The easiest and the recommended way to copy the public key to the remote server is to use the ssh-copy-id utility. On your local machine terminal type:

Terminal
ssh-copy-id remote_username@server_ip_address

The command will ask you to enter the remote_username password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the content of the public key file (~/.ssh/id_rsa.pub) will be appended to the remote user ~/.ssh/authorized_keys file, and connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If ssh-copy-id is not available on your local computer, use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To verify it, try to login to your server via SSH :

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase for the private key, you will be logged in immediately. Otherwise, you will be asked to enter the passphrase.

Disabling SSH Password Authentication

To add an additional layer of security to your remote server, you can disable SSH password authentication.

Before continuing, make sure you can log in to your server without a password as a user with sudo privileges .

Follow the steps below to disable SSH password authentication:

Log into your remote server:
Terminal
```
ssh sudo_user@server_ip_address
```
Open the SSH configuration file /etc/ssh/sshd_config with your text editor :
Terminal
```
sudo nano /etc/ssh/sshd_config
```
Search for the following directives and modify as it follows:
/etc/ssh/sshd_configini
```
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
```
Once you are done save the file and restart the SSH service by typing:
Terminal
```
sudo systemctl restart ssh
```

At this point, the password-based authentication is disabled.

Conclusion

By default, SSH listens on port 22. Changing the default SSH port reduces the risk of automated attacks. To simplify your workflow, use the SSH config file to define all your SSH connections.

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on Debian 9

hello@linuxize.com (Linuxize) — Mon, 22 Oct 2018 03:40:24 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server and supports various authentication mechanisms.

The two most popular mechanisms are password based and public-key based authentication. Using SSH keys is more secure and convenient than traditional password authentication.

In this tutorial, we will describe how to generate SSH keys on Debian 9 systems. We will also show you how to set up an SSH key-based authentication and connect to your remote Linux servers without entering a password.

Creating SSH keys on Debian

Before generating a new SSH key pair first, check for existing SSH keys on your Debian client machine. You can do that by running the following ls command :

Terminal
ls -l ~/.ssh/id_*.pub

If the output of the command above contains something like No such file or directory or no matches found it means that you don’t have SSH keys, and you can continue with the next step and generate a new SSH key pair.

If there are existing keys, you can either use those and skip the next step or backup up the old keys and generate new ones.

Start by generating a new 4096 bits SSH key pair with your email address as a comment using the following command:

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

The output will look similar to the following:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

Press Enter to accept the default file location and file name.

Next, you’ll be prompted to type a secure passphrase. Whether you want to use a passphrase, it’s up to you. With a passphrase, an extra layer of security is added to your key.

output

Enter passphrase (empty for no passphrase):

If you don’t want to use a passphrase just press Enter.

The whole interaction looks like this:

To verify that the SSH key pair was generated, type:

Terminal
ls ~/.ssh/id_*

The output should look something like this:

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

Copy the Public Key to the Server

Now that you have your SSH key pair, the next step is to copy the public key to the server you want to manage.

The easiest and the recommended way to copy the public key to the remote server is to use the ssh-copy-id tool.

On your local machine terminal run the following command:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the public key ~/.ssh/id_rsa.pub will be appended to the remote user ~/.ssh/authorized_keys file, and connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If the ssh-copy-id utility is not available on your local computer, you can use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

At this point, you should be able to log in to the remote server without being prompted for a password.

To test it, try to connect to the server via SSH:

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase, you will be logged in immediately. Otherwise, you will be prompted to enter the passphrase.

Disabling SSH Password Authentication

To add an extra layer of security to your server, you can disable the password authentication for SSH.

Before disabling SSH password authentication, make sure you can log in to your server without a password, and the user you are logging in with has sudo privileges .

Log into your remote server:

Terminal
ssh sudo_user@server_ip_address

Open the SSH configuration file /etc/ssh/sshd_config:

Terminal
sudo vim /etc/ssh/sshd_config

Search for the following directives and modify as it follows:

/etc/ssh/sshd_configini
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Once you are done, save the file and restart the SSH service using the following command:

Terminal
sudo systemctl restart ssh

At this point, the password-based authentication is disabled.

Conclusion

In this tutorial, you have learned how to generate a new SSH key pair and set up an SSH key-based authentication. You can add the same key to multiple remote servers.

We have also shown you how to disable SSH password authentication and add an extra layer of security to your server.

By default, SSH listens on port 22. Changing the default SSH port reduces the risk of automated attacks.

If you are regularly connecting to multiple systems, you can simplify your workflow by defining all of your connections in the SSH config file .

If you have any questions or feedback, feel free to leave a comment.

How to Set Up SSH Keys on Debian 10

hello@linuxize.com (Linuxize) — Sun, 29 Mar 2020 21:45:28 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server and supports various authentication mechanisms. The encrypted connection can be used to execute commands on the server, X11 tunneling, port forwarding, and more.

Password and public-key based are the two most common mechanisms for authentications.

Authentication using a public key is based on the use of digital signatures, and it is more secure and convenient than traditional password authentication.

This article describes how to generate SSH keys on Debian 10 systems. We will also show you how to set up an SSH key-based authentication and connect to remote Linux servers without entering a password.

Creating SSH keys on Debian

The chances are that you already have an SSH key pair on your Debian client machine. If you are generating a new key pair, the old one will be overwritten.

Run the following ls command to check whether the key files exist:

Terminal
ls -l ~/.ssh/id_*.pub

If the output of the command above contains something like No such file or directory or no matches found, it means that you don’t have SSH keys, and you can continue with the next step and generate a new SSH key pair.

Otherwise, if you have an SSH key pair, you can either use those or backup up the old keys and generate new ones.

Generate a new 4096 bits SSH key pair with your email address as a comment by entering the following command:

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

The output will look something like this:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):

Press Enter to accept the default file location and file name.

Next, you’ll be prompted to type a secure passphrase. Whether you want to use a passphrase, it’s up to you. The passphrase adds an extra layer of security.

output

Enter passphrase (empty for no passphrase):

If you don’t want to use a passphrase, just press Enter.

The whole interaction looks like this:

To confirm the SSH key pair was generated, run the following command:

Terminal
ls ~/.ssh/id_*

The command will list the key files:

output

/home/yourusername/.ssh/id_rsa /home/yourusername/.ssh/id_rsa.pub

Copy the Public Key to the Server

Now that you have your SSH key pair, the next step is to copy the public key to the server you want to manage.

The easiest and the recommended way to copy the public key to the remote server is to use the ssh-copy-id tool.

Run the following command on your local machine:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the content of the public key file (~/.ssh/id_rsa.pub) will be appended to the remote user ~/.ssh/authorized_keys file, and connection will be closed.

output

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'username@server_ip_address'"
and check to make sure that only the key(s) you wanted were added.

If the ssh-copy-id utility is not available on your local machine, use the following command to copy the public key:

Terminal
cat ~/.ssh/id_rsa.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

At this point, you should be able to log in to the remote server without being prompted for a password.

To test it, try to connect to the server via SSH:

Terminal
ssh remote_username@server_ip_address

If you haven’t set a passphrase, you will be logged in immediately. Otherwise, you will be prompted to enter the passphrase.

Disabling SSH Password Authentication

To add an extra layer of security to your server, you can disable the SSH password authentication.

Before disabling the password authentication, make sure you can log in to your server without a password, and the user you are logging in with has sudo privileges .

Log into your remote server:

Terminal
ssh sudo_user@server_ip_address

Open the SSH server configuration file /etc/ssh/sshd_config:

Terminal
sudo nano /etc/ssh/sshd_config

Search for the following directives and modify as it follows:

/etc/ssh/sshd_configini
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Once done, save the file and restart the SSH service:

Terminal
sudo systemctl restart ssh

At this point, the password-based authentication is disabled.

Conclusion

By default, SSH listens on port 22. Changing the default SSH port reduces the risk of automated attacks. To simplify your workflow, use the SSH config file to define all your SSH connections.

If you have any questions or feedback, feel free to leave a comment.

ssh-copy-id Command: Copy SSH Keys to a Remote Server

hello@linuxize.com (Linuxize) — Sat, 31 Jan 2026 19:30:00 +0100

ssh-copy-id is a utility that copies your local SSH public key to a remote server’s authorized_keys file. This sets up key-based authentication, allowing you to log in without entering a password. The command connects to the remote host over SSH to perform the installation, using the same ssh client settings as a normal login, including any matching entry in your ~/.ssh/config.

In this guide, we will show you how to use the ssh-copy-id command with practical examples.

Prerequisites

Before using ssh-copy-id, you need to have an SSH key pair. If you do not have one, generate it with:

Terminal
ssh-keygen -t ed25519

This creates a private key (~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub). For more details, see our guide on how to generate SSH keys on Linux .

The command itself ships with the OpenSSH client, so it is already present on most systems. If your shell reports command not found, install the client package. On Ubuntu, Debian, and derivatives:

Terminal
sudo apt install openssh-client

On Fedora, RHEL, and derivatives:

Terminal
sudo dnf install openssh-clients

macOS includes the command at /usr/bin/ssh-copy-id, so there is nothing to install there.

Syntax

The basic syntax of ssh-copy-id is:

txt
ssh-copy-id [options] [user@]hostname

The command copies the public key to the remote server and appends it to the ~/.ssh/authorized_keys file. If the .ssh directory or authorized_keys file does not exist, ssh-copy-id creates it with restrictive permissions. It does not change the permissions of an existing directory or file.

Copying the Default Key

To copy your default public key to a remote server, run:

Terminal
ssh-copy-id user@remote_host

You will be prompted to enter the remote user’s password:

output

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.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
user@remote_host's password:
Number of key(s) added: 1

When you do not specify -i, ssh-copy-id uses the keys returned by ssh-add -L. If the agent has no keys, the command uses the most recently modified file that matches ~/.ssh/id*.pub, excluding certificate files. Before copying, it tests each key and skips any that are already installed. Run ssh-add -L to see which keys the agent provides, or use -i to copy a specific key.

After the key is copied, you can log in without a password:

Terminal
ssh user@remote_host

To confirm that the login uses a specific key, tell SSH to try public-key authentication only and specify the matching private key:

Terminal
ssh -o PreferredAuthentications=publickey -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@remote_host

If the connection succeeds, the server accepted that key. You may still be prompted for the private key’s passphrase, which is different from the remote user’s password. A Permission denied (publickey) error means the server rejected the tested key. Common causes include selecting the wrong key, incorrect ownership or permissions, a custom AuthorizedKeysFile path, or disabled public-key authentication. Our guide on fixing SSH Permission denied (publickey) covers these checks in detail.

Specifying a Key File

If you have multiple SSH keys, use the -i option to specify which public key to copy:

Terminal
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote_host

Using a Non-Standard Port

If the remote SSH server listens on a port other than the default 22, use the -p option:

Terminal
ssh-copy-id -p 2222 user@remote_host

You can combine -i and -p:

Terminal
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 user@remote_host

Copying Keys Manually

If ssh-copy-id is not available on your system, you can copy the key manually using cat and SSH:

Terminal
cat ~/.ssh/id_ed25519.pub | ssh user@remote_host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

This command does the following:

Creates the ~/.ssh directory on the remote server if it does not exist.
Sets the correct permissions (700) on the .ssh directory.
Appends the public key to the authorized_keys file.
Sets the correct permissions (600) on the authorized_keys file.

Common Options

Option	Description
`-i identity_file`	Specify the public key file to copy
`-p port`	Connect to a non-standard SSH port
`-o ssh_option`	Pass options to the underlying SSH connection
`-f`	Force copying the key even if it is already installed
`-n`	Dry run, print the key that would be copied without installing it
`-s`	Use SFTP instead of remote commands, for servers that allow only SFTP
`-t target_path`	Install the key somewhere other than `~/.ssh/authorized_keys`
`-F ssh_config`	Read connection settings from an alternative SSH config file
`-x`	Trace the script itself, for debugging the copy process

Troubleshooting

Permission denied
A “Permission denied” error during ssh-copy-id is almost always caused by the remote server rejecting the password login that the command needs in order to install the key. The most common reason is that password authentication is disabled. Check /etc/ssh/sshd_config on the remote server for:

/etc/ssh/sshd_configtxt
PasswordAuthentication yes

Restart the SSH service after making changes:

Terminal
sudo systemctl restart sshd

If password authentication is already enabled, double-check that you are using the correct username, that the user is not locked, and that no AllowUsers or AllowGroups directive in sshd_config is restricting who can log in over SSH.

Connection refused or timeout
If the connection is refused or hangs, the SSH server is either not reachable or not running on the port you are trying. Make sure that the SSH service is active on the remote host, and use the -p option if it listens on a non-standard port:

Terminal
ssh-copy-id -p 2222 user@remote_host

A firewall on the remote server or somewhere on the network path can also block port 22. Try a plain ssh user@remote_host first to confirm that you can reach the host before running ssh-copy-id.

Key already installed
If the key is already in the remote authorized_keys file, ssh-copy-id will skip it and display:

output

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.

Use the -f option to force installation if needed.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Task	Command
Copy default key	`ssh-copy-id user@host`
Copy specific key	`ssh-copy-id -i ~/.ssh/key.pub user@host`
Use non-standard port	`ssh-copy-id -p 2222 user@host`
Dry run	`ssh-copy-id -n user@host`
Force copy	`ssh-copy-id -f user@host`

FAQ

What does ssh-copy-id actually do?
It checks whether your public key is already installed, then appends it to the remote server’s ~/.ssh/authorized_keys file if needed. It also creates the .ssh directory and authorized_keys file when they do not exist.

Can I use ssh-copy-id on macOS?
Yes. macOS includes the command at /usr/bin/ssh-copy-id and has shipped it since macOS 10.13, so most users do not need to install anything. Homebrew also provides a separate, keg-only ssh-copy-id formula if you need a newer version.

Is ssh-copy-id safe to use?
Yes. It only copies your public key, not your private key. The public key is meant to be shared.

What permissions does ssh-copy-id set?
When ssh-copy-id creates the remote .ssh directory and authorized_keys file, its restrictive umask gives them 700 and 600 permissions. It does not reset permissions on existing paths. For a full breakdown of every file in ~/.ssh and the mode it needs, see the ~/.ssh folder guide .

Can I copy keys to multiple servers?
Yes. Run ssh-copy-id once for each server. There is no built-in option to copy to multiple hosts at once, but you can use a loop: for host in server1 server2; do ssh-copy-id user@$host; done.

Conclusion

The ssh-copy-id command is the simplest way to set up key-based SSH authentication. It checks for an existing key, installs it when needed, and creates the required remote path if it is missing.

After installing the key, test the SSH login in a new terminal before closing your current session. Once key-based login works for every account you need, disabling password authentication is the sensible next step, and our SSH hardening guide walks through that change.

How to Set Up Passwordless SSH Login

hello@linuxize.com (Linuxize) — Sat, 16 Jun 2018 03:40:24 +0100

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server. It supports various authentication mechanisms, the two most popular being password-based authentication and public-key-based authentication. If you are new to SSH, see our SSH command guide and SSH config file guide .

In this guide, we will show you how to set up SSH key-based authentication and connect to your Linux server without entering a password.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Task	Command
Generate Ed25519 key	`ssh-keygen -t ed25519 -C "email@example.com"`
Generate RSA key	`ssh-keygen -t rsa -b 4096 -C "email@example.com"`
Copy key to server	`ssh-copy-id user@server`
Log in with key	`ssh user@server`
Start SSH agent	`eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519`
List public keys	`ls -al ~/.ssh/id_*.pub`

Check for Existing SSH Keys

Before generating a new SSH key pair, check if you already have one on your client machine so you do not overwrite existing keys.

Run the following ls command to see if existing SSH keys are present:

Terminal
ls -al ~/.ssh/id_*.pub

If there are existing keys, you can either use those and skip the next step or back up the old keys and generate a new one.

If you see No such file or directory or no matches found, it means that you do not have an SSH key and you can proceed with the next step.

Generate a New SSH Key Pair

The recommended key type is Ed25519, which offers better security and performance than RSA with shorter keys:

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

If you need to work with older systems that do not support Ed25519, you can generate a 4096-bit RSA key instead:

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

Our guide on generating SSH keys with ssh-keygen goes deeper into key types, custom filenames, and managing more than one key pair.

Press Enter to accept the default file location and file name:

output

Enter file in which to save the key (/home/yourusername/.ssh/id_ed25519):

Next, the ssh-keygen tool will ask you to type a secure passphrase. Whether you want to use a passphrase is up to you. If you choose to use a passphrase, you will get an extra layer of security. In most cases, developers and system administrators use SSH without a passphrase because it is useful for fully automated processes. If you do not want to use a passphrase, just press Enter.

output

Enter passphrase (empty for no passphrase):

A sample interaction looks like this:

To verify that the SSH keys were generated, list your new private and public keys with:

Terminal
ls ~/.ssh/id_*

output

/home/yourusername/.ssh/id_ed25519 /home/yourusername/.ssh/id_ed25519.pub

Copy the Public Key to the Server

Now that you have generated an SSH key pair, you need to copy the public key to the server you want to manage.

The easiest way to copy your public key to your server is to use the ssh-copy-id command. On your local machine, type:

Terminal
ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

output

remote_username@server_ip_address's password:

Once the user is authenticated, the public key will be appended to the remote user’s authorized_keys file and the connection will be closed.

If for some reason the ssh-copy-id utility is not available on your local computer, you can use the following command to copy the public key:

Terminal
cat ~/.ssh/id_ed25519.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Info

The correct permissions are critical for SSH key authentication to work. The ~/.ssh directory must be 700 and the authorized_keys file must be 600.

Copy a Non-Default Key

If you generated a key with a custom filename, specify it with -i:

Terminal
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub remote_username@server_ip_address

Log In Using SSH Keys

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To test it, try to log in to your server via SSH:

Terminal
ssh remote_username@server_ip_address

If everything went well, you will be logged in immediately.

Using the SSH Agent

If you set a passphrase on your key, you will be asked to enter it every time you connect. To avoid this, you can use ssh-agent to cache your passphrase for the duration of your session:

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

The agent will remember your passphrase until you log out or the agent is stopped.

Loading Keys into the Agent Automatically

To load the key into the agent automatically on first use, add this block to ~/.ssh/config:

~/.ssh/configtxt
Host *
 AddKeysToAgent yes
 IdentityFile ~/.ssh/id_ed25519
 IdentitiesOnly yes

AddKeysToAgent yes pushes the key into a running ssh-agent the first time it is used, so the passphrase is requested only once per session. IdentityFile selects the key explicitly, and IdentitiesOnly yes prevents the client from offering every key from the agent and triggering Too many authentication failures on strict servers.

Generating SSH Keys on Windows

Windows 10 and later include a built-in OpenSSH client. You can use the same commands shown above directly in PowerShell or Command Prompt.

To generate a key on Windows, open PowerShell and run:

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

The keys will be stored in C:\Users\your_username\.ssh\. To copy the public key to the server, you can use the following PowerShell command:

powershell
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Disabling SSH Password Authentication

To add an extra layer of security to your server, you can disable password authentication for SSH.

Before disabling SSH password authentication, make sure you can log in to your server without a password and the user you are logging in with has sudo privileges.

The following tutorials describe how to configure sudo access:

Log into your remote server with SSH keys, either as a user with sudo privileges or root:

Terminal
ssh sudo_user@server_ip_address

Warning

Keep this session open while you make the changes below. If the new configuration locks you out, you will still have a working shell to revert it.

On Ubuntu 22.04, Debian 12, and other recent releases, /etc/ssh/sshd_config begins with an Include /etc/ssh/sshd_config.d/*.conf line. OpenSSH uses the first value it obtains for each keyword, and the included files are read in lexical order, so a directive set in a drop-in file wins over the same directive further down in the main file. Cloud images are where this bites most often: cloud-init writes /etc/ssh/sshd_config.d/50-cloud-init.conf with PasswordAuthentication yes, and editing sshd_config alone changes nothing.

Check whether your server uses drop-in files:

Terminal
ls /etc/ssh/sshd_config.d/

If the directory is empty or missing, edit /etc/ssh/sshd_config directly and set the following directives:

/etc/ssh/sshd_configini
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

If the directory already contains files, add your own drop-in with a name that sorts before them. A file named 99-hardening.conf is read after 50-cloud-init.conf and loses to it, so use a low number instead:

Terminal
sudo nano /etc/ssh/sshd_config.d/01-hardening.conf

/etc/ssh/sshd_config.d/01-hardening.conftxt
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Info

On older OpenSSH versions (before 8.7), the directive is called ChallengeResponseAuthentication instead of KbdInteractiveAuthentication.

Save the file and test the configuration syntax before restarting anything:

Terminal
sudo sshd -t

If the command prints no output, the syntax is valid. Confirm that the values you set are the ones OpenSSH will actually use:

Terminal
sudo sshd -T | grep -iE "passwordauthentication|pubkeyauthentication"

output

pubkeyauthentication yes
passwordauthentication no

This dumps the effective configuration after all includes are resolved, so it is the only reliable way to confirm that a drop-in file is not overriding you. Once the output is correct, restart the SSH service.

On Ubuntu or Debian servers:

Terminal
sudo systemctl restart ssh

On Fedora, RHEL, and derivatives:

Terminal
sudo systemctl restart sshd

Recent Ubuntu releases start SSH through socket activation, which spawns a fresh sshd for each connection. The authentication changes above apply to the next login either way. Before closing the session, open a second terminal and confirm that key login still works.

Troubleshooting

Permission denied (publickey)
The server did not accept the offered key. Check three things: the public key is appended to the remote ~/.ssh/authorized_keys, the remote ~/.ssh is 700 and authorized_keys is 600, and the username in ssh user@host matches the account that owns authorized_keys. Run ssh -v user@host to see which keys are being offered.

Authentication refused: bad ownership or modes for file
The remote authorized_keys file or ~/.ssh directory has loose permissions. Fix with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys on the server.

PasswordAuthentication no has no effect
A file under /etc/ssh/sshd_config.d/ sets the directive before the main file does, and OpenSSH keeps the first value it obtains. Run sudo sshd -T | grep -i passwordauthentication to see the effective value, then edit the drop-in that sets it or add one with a lower-numbered filename.

Too many authentication failures
The client is offering every key in ~/.ssh/ and the server cuts the session after the limit. Use ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@host for a one-shot fix, or set IdentitiesOnly yes for the host in ~/.ssh/config.

Could not open a connection to your authentication agent
ssh-agent is not running in the current shell. Start it with eval "$(ssh-agent -s)" and re-run ssh-add.

FAQ

What is the difference between Ed25519 and RSA keys?
Ed25519 keys are shorter, faster, and considered more secure than RSA. They are supported on OpenSSH 6.5+ (released 2014). Use RSA only if you need compatibility with very old systems.

Can I use the same key for multiple servers?
Yes. You can copy the same public key to as many servers as you want using ssh-copy-id.

What permissions should the SSH files have?
The ~/.ssh directory should be 700, the private key should be 600, and the authorized_keys file should be 600. Incorrect permissions will cause SSH to reject the key.

How do I use different keys for different servers?
You can configure per-host keys in your SSH config file (~/.ssh/config) using the IdentityFile directive.

Do I need to edit /etc/ssh/sshd_config to log in with a key?
No. Key-based login works out of the box on most distributions. You only edit the server configuration when you want to turn password authentication off afterwards.

Conclusion

SSH key-based authentication lets you log in without typing an account password while keeping access tied to your private key. After you confirm key login works from a second terminal, disabling password authentication reduces the attack surface for public SSH servers.

SSH Tunnel: Local, Remote, and Dynamic Port Forwarding

hello@linuxize.com (Linuxize) — Thu, 08 Aug 2019 20:31:47 +0100

SSH tunneling (SSH port forwarding) is a method of creating an encrypted SSH connection between a client and a server through which service ports can be relayed.

SSH tunneling is useful for transporting network data of services that use an unencrypted protocol, such as VNC or FTP , accessing geo-restricted content, or bypassing intermediate firewalls. You can forward any TCP port and tunnel the traffic over a secure SSH connection.

Common use cases for SSH port forwarding include secure remote access to internal services, creating a temporary SOCKS proxy for browsing, and exposing a local dev server to a remote machine.

There are three types of SSH port forwarding:

Local Port Forwarding: Forwards a connection from the client host to the SSH server host and then to the destination host port.
Remote Port Forwarding: Forwards a port from the server host to the client host and then to the destination host port.
Dynamic Port Forwarding: Creates a SOCKS proxy server that allows communication across a range of ports.

This guide explains how to set up local, remote, and dynamic encrypted SSH tunnels.

Quick Reference

For a printable quick reference, see the ssh cheatsheet .

Task	Command
Local port forwarding	`ssh -L 8080:localhost:80 user@server`
Remote port forwarding	`ssh -R 8080:localhost:3000 user@server`
Dynamic port forwarding (SOCKS)	`ssh -D 9090 user@server`
Run tunnel in background	`ssh -L 8080:localhost:80 -N -f user@server`
Multiple local forwards	`ssh -L 8080:host1:80 -L 8081:host2:80 user@server`
Jump host	`ssh -J jump.host user@destination`

Local Port Forwarding

Local port forwarding allows you to forward a port on the local (SSH client) machine to a port on the remote (SSH server) machine, which is then forwarded to a port on the destination machine.

In this forwarding type, the SSH client listens on a given port and tunnels any connection to that port to the specified port on the remote SSH server, which then connects to a port on the destination machine. The destination machine can be the remote SSH server or any other machine.

Local port forwarding is mostly used to connect to a remote service on an internal network, such as a database or VNC server.

In Linux, macOS, and other Unix systems, to create a local port forwarding, pass the -L option to the ssh client:

Terminal
ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

The options used are as follows:

[LOCAL_IP:]LOCAL_PORT - The local machine IP address and port number. When LOCAL_IP is omitted, the ssh client binds on the localhost.
DESTINATION:DESTINATION_PORT - The IP or hostname and the port of the destination machine.
[USER@]SSH_SERVER - The remote SSH user and server IP address.

You can use any port number 1024 or higher as a LOCAL_PORT. Port numbers below 1024 are privileged ports and can be used only by root. If your SSH server is listening on a port other than 22 (the default), use the -p [PORT_NUMBER] option.

The destination hostname must be resolvable from the SSH server.

Say you have a MySQL database server running on machine db001.host on an internal (private) network, on port 3306, which is accessible from the machine pub001.host, and you want to connect using your local machine’s MySQL client to the database server. To do so, you can forward the connection using the following command:

Terminal
ssh -L 3336:db001.host:3306 user@pub001.host

Once you run the command, you will be prompted to enter the remote SSH user password. Once entered, you will be logged into the remote server, and the SSH tunnel will be established. It is also a good idea to set up an SSH key-based authentication and connect to the server without entering a password.

Now, if you point your local machine database client to 127.0.0.1:3336, the connection will be forwarded to the db001.host:3306 MySQL server through the pub001.host machine that acts as an intermediate server. For a full walkthrough of this setup, including the client commands on Linux, macOS, and Windows, see how to connect to a remote MySQL server over an SSH tunnel .

You can forward multiple ports to multiple destinations in a single ssh command. For example, if you have another MySQL database server running on machine db002.host and you want to connect to both servers from your local client, you would run:

Terminal
ssh -L 3336:db001.host:3306 -L 3337:db002.host:3306 user@pub001.host

To connect to the second server, you would use 127.0.0.1:3337.

When the destination host is the same as the SSH server, instead of specifying the destination host IP or hostname, you can use localhost.

Say you need to connect to a remote machine through VNC, which runs on the same server, and it is not accessible from the outside. The command you would use is:

Terminal
ssh -L 5901:127.0.0.1:5901 -N -f user@remote.host

The -f option tells the ssh command to run in the background and -N not to execute a remote command. We are using 127.0.0.1 because the VNC and the SSH server are running on the same host.

Remote Port Forwarding

Remote port forwarding is the opposite of local port forwarding. It allows you to forward a port on the remote (SSH server) machine to a port on the local (SSH client) machine, which is then forwarded to a port on the destination machine. This is also called a reverse SSH tunnel, because the traffic travels back toward the client instead of away from it.

In this forwarding type, the SSH server listens on a given port and tunnels any connection to that port to the specified port on the local SSH client, which then connects to a port on the destination machine. The destination machine can be the local or any other machine.

In Linux, macOS, and other Unix systems, to create a remote port forwarding, pass the -R option to the ssh client:

Terminal
ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

The options used are as follows:

[REMOTE:]REMOTE_PORT - The bind address and port number on the remote SSH server. If REMOTE is omitted, the listening address is controlled by the SSH server’s GatewayPorts setting. To make the port reachable from other hosts, use an explicit bind address such as 0.0.0.0 when the server allows it.
DESTINATION:DESTINATION_PORT - The IP or hostname and the port of the destination machine.
[USER@]SSH_SERVER - The remote SSH user and server IP address.

Remote port forwarding is mostly used to give access to an internal service to someone from the outside.

Say you are developing a web application on your local machine, and you want to show a preview to your fellow developer. You do not have a public IP, so the other developer cannot access the application via the Internet.

If you have access to a remote SSH server, you can set up a remote port forwarding as follows:

Terminal
ssh -R 8080:127.0.0.1:3000 -N -f user@remote.host

The command above will make the ssh server listen on port 8080, and tunnel all traffic from this port to your local machine on port 3000.

Once the port is reachable from the outside, your fellow developer can type the_ssh_server_ip:8080 in their browser and preview your application.

By default, however, the SSH server binds a remotely forwarded port to its loopback interface only, so nothing outside the server can reach it. That behavior is controlled by the GatewayPorts directive in /etc/ssh/sshd_config, which is set to no unless you change it. Setting it to yes binds remote forwards on all interfaces, while clientspecified lets the client choose the bind address itself:

Terminal
ssh -R 0.0.0.0:8080:127.0.0.1:3000 -N -f user@remote.host

An explicit bind address such as 0.0.0.0 only takes effect when GatewayPorts is enabled on the server. Without it, the client reports no error and the port quietly stays on loopback. Restart the SSH service after editing the directive, and enable it only for as long as the port needs to be reachable from the outside.

Dynamic Port Forwarding

Dynamic port forwarding allows you to create a socket on the local (SSH client) machine, which acts as a SOCKS proxy server. When a client connects to this port, the connection is forwarded to the remote (SSH server) machine, which is then forwarded to a dynamic port on the destination machine.

This way, all the applications using the SOCKS proxy will connect to the SSH server, and the server will forward all the traffic to its actual destination.

In Linux, macOS, and other Unix systems, to create a dynamic port forwarding (SOCKS), pass the -D option to the ssh client:

Terminal
ssh -D [LOCAL_IP:]LOCAL_PORT [USER@]SSH_SERVER

The options used are as follows:

[LOCAL_IP:]LOCAL_PORT - The local machine IP address and port number. When LOCAL_IP is omitted, the SSH client binds on localhost.
[USER@]SSH_SERVER - The remote SSH user and server IP address.

A typical example of dynamic port forwarding is tunneling web browser traffic through an SSH server.

The following command will create a SOCKS tunnel on port 9090:

Terminal
ssh -D 9090 -N -f user@remote.host

Once the tunneling is established, you can configure your application to use it. This article explains how to configure Firefox and Google Chrome browser to use the SOCKS proxy.

The port forwarding has to be separately configured for each application that you want to tunnel the traffic through.

Using SSH Config File for Tunnels

Instead of typing long ssh commands each time, you can define tunnels in your SSH config file (~/.ssh/config):

sh
Host tunnel-db
 HostName pub001.host
 User user
 LocalForward 3336 db001.host:3306

Host tunnel-socks
 HostName remote.host
 User user
 DynamicForward 9090

With this configuration, you can start a tunnel by simply running:

Terminal
ssh -N tunnel-db

Set up SSH Tunneling in Windows

Windows 10 and later include a built-in OpenSSH client. You can use the same ssh commands shown above directly in PowerShell or Command Prompt.

To verify that OpenSSH is installed, open PowerShell and run:

powershell
ssh -V

If the command returns a version number, OpenSSH is available and you can use all the -L, -R, and -D options described in the previous sections.

Using PuTTY

Alternatively, you can use the PuTTY SSH client. You can download PuTTY here .

Launch PuTTY and enter the SSH server IP Address in the Host name (or IP address) field.
Under the Connection menu, expand SSH and select Tunnels. Check the Local radio button to set up local, Remote for remote, and Dynamic for dynamic port forwarding.
- When setting up local forwarding, enter the local forwarding port in the Source Port field and in Destination enter the destination host and IP, for example, localhost:5901.
- For remote port forwarding, enter the remote SSH server forwarding port in the Source Port field and in Destination enter the destination host and IP, for example, localhost:3000.
- If setting up dynamic forwarding, enter only the local SOCKS port in the Source Port field.
Click on the Add button, as shown in the image below.
Go back to the Session page to save the settings so that you do not need to enter them each time. Enter the session name in the Saved Session field and click on the Save button.
Select the saved session and log in to the remote server by clicking on the Open button.

A new window asking for your username and password will show up. Once you enter your username and password, you will be logged in to your server, and the SSH tunnel will be started.

Setting up public key authentication allows you to connect to your server without entering a password.

Common SSH Tunneling Options

Here are some useful options you can combine with SSH tunnels:

-N - Do not execute a remote command. Useful when you only want to forward ports.
-f - Run SSH in the background after authentication.
-L - Set up local port forwarding.
-R - Set up remote port forwarding.
-D - Set up dynamic port forwarding (SOCKS proxy).
-o ExitOnForwardFailure=yes - Exit if the tunnel cannot be established.
-o ServerAliveInterval=60 - Send keep-alives to keep long-lived tunnels up.
-p - Specify the SSH server port (if not the default 22).
-J - Use a jump host (ProxyJump) to reach a server through an intermediate host. For example: ssh -J jump.host user@destination.host.

Troubleshooting

channel 2: open failed: connect failed: Connection refused
The tunnel is up, but SSH could not reach the destination host and port. With local forwarding (-L), the SSH server connects to the destination, so test the service from that server. With remote forwarding (-R), the SSH client connects to the destination, so test it from your local machine. Confirm that the service is running and listening on the address you specified. The SSH connection refused error guide covers the same failure when it happens on the SSH port itself.

bind: Address already in use
Another process is already listening on the local port you picked. Check what holds it with ss -tlnp 'sport = :8080', then stop that process or choose a different local port.

Warning: remote port forwarding failed for listen port 8080
The SSH server refused to bind the requested port. The port may already be in use on the server, or it may be a privileged port below 1024 that your remote user cannot bind. Pick a higher port, or check for a stale tunnel left behind by an earlier session.

channel 1: open failed: administratively prohibited: open failed
The SSH server rejected the forwarding request. Check /etc/ssh/sshd_config for AllowTcpForwarding, DisableForwarding, PermitOpen, and PermitListen restrictions. Also check whether the key entry in ~/.ssh/authorized_keys uses restrict or no-port-forwarding.

The tunnel drops after a period of inactivity
Add -o ServerAliveInterval=60 -o ServerAliveCountMax=3 so the client disconnects after three unanswered keep-alives. Use -o ExitOnForwardFailure=yes separately so SSH exits when it cannot create a requested forwarding at startup. For tunnels that must survive network drops, use autossh to restart them automatically.

FAQ

What is the difference between local and remote port forwarding?
Local forwarding listens on your local machine and forwards traffic to a remote destination. Remote forwarding listens on the remote server and forwards traffic back to your local machine or another host.

Can I forward UDP traffic through an SSH tunnel?
No, SSH tunnels only support TCP traffic. For UDP forwarding, you would need tools like socat or a VPN solution.

How do I close a background SSH tunnel?
Find the process with ps aux | grep "ssh -" and terminate it with kill <PID>. You can also match the forwarding rule directly, for example pkill -f "ssh -L 3336". A tunnel running in the foreground closes with Ctrl+C in the terminal where it was started.

Is SSH tunneling secure?
Yes, all traffic through the tunnel is encrypted by the SSH connection. However, the traffic between the SSH server and the final destination is not encrypted by the tunnel itself.

Conclusion

For ease of use, define your tunnels in the SSH config file so you can start any tunnel with ssh -N tunnel-name instead of typing the full command each time.

SSH SOCKS Proxy: Create a SOCKS5 Tunnel for Browsing

hello@linuxize.com (Linuxize) — Mon, 29 Oct 2018 20:31:47 +0100

There are times when you want to route browser traffic through a remote server, access content from another network, or bypass an intermediate firewall.

One option is to use a VPN, but that requires installing client software on your machine and setting up your own VPN server or subscribing to a VPN service.

The simpler alternative is to route your local browser traffic through an encrypted SSH SOCKS proxy. Applications configured to use the proxy connect to the SSH server first, and the server forwards the traffic to the final destination.

An SSH SOCKS proxy changes the exit IP address and encrypts traffic between your computer and the SSH server. It does not make browsing anonymous, and DNS requests can still leak unless your browser is configured to proxy DNS through the tunnel.

This tutorial walks you through the process of creating an encrypted SSH tunnel and configuring Firefox and Google Chrome web browsers to use a SOCKS proxy.

Quick Reference

Task	Command
Create SOCKS tunnel	`ssh -N -D 127.0.0.1:9090 user@server`
Run tunnel in background	`ssh -fN -D 127.0.0.1:9090 user@server`
Use custom SSH port	`ssh -N -D 127.0.0.1:9090 -p 2222 user@server`
Check local listener	`ss -ltnp \| grep 9090`
Test through tunnel	`curl --socks5-hostname 127.0.0.1:9090 https://ifconfig.me`

Prerequisites

Server running any flavor of Linux, with SSH access to route your traffic through it.
Web browser.
SSH client.

Set Up the SSH Tunnel

We will create an SSH tunnel that opens a local SOCKS proxy on 127.0.0.1:9090 and forwards traffic through the SSH server. You can use any local port number greater than 1024; only root can open privileged ports.

Linux and macOS

If you run Linux, macOS or any other Unix-based operating system on your local machine, you can easily start an SSH tunnel with the following ssh command:

Terminal
ssh -N -D 127.0.0.1:9090 user@server

The options used are as follows:

-N - Tells SSH not to execute a remote command.
-D 127.0.0.1:9090 - Opens a SOCKS tunnel bound to localhost on port 9090.
user@server - Your remote SSH user and server IP address or hostname.
To run the command in the background, use ssh -fN -D 127.0.0.1:9090 user@server.
If your SSH server is listening on a port other than 22 , add -p PORT_NUMBER.

Binding the SOCKS listener to 127.0.0.1 keeps it available only on your local machine. Once you run the command, you will be prompted to enter your user password. After entering it, the SSH tunnel will be established.

You can set up an SSH key-based authentication and connect to your server without entering a password.

Windows

Windows users can create an SSH tunnel using the PuTTY SSH client. You can download PuTTY here .

Launch Putty and enter your server IP Address in the Host name (or IP address) field.
Under the Connection menu, expand SSH and select Tunnels. Enter the port 9090 in the Source Port field, and check the Dynamic radio button.
Click on the Add button as shown in the image below.
Go back to the Session page to save the settings so that you do not need to enter them each time. Enter the session name in the Saved Session field and click on the Save button.
Select the saved session and log in to the remote server by clicking on the Open button.

A new window asking for your username and password will show up. Once you enter your username and password you will be logged in to your server and the SSH tunnel will be started.

Setting up public key authentication will allow you to connect to your server without entering a password.

Configuring Your Browser to Use Proxy

Now that you have opened the SSH SOCKS tunnel, the last step is to configure your preferred browser to use it.

Firefox

The steps below are the same for Windows, macOS, and Linux.

In the upper right-hand corner, click on the hamburger icon ☰ to open Firefox’s menu:
Click on the ⚙ Settings link.
Scroll down to the Network Settings section and click on the Settings... button.
A new window will open.
- Select the Manual proxy configuration radio button.
- Enter 127.0.0.1 in the SOCKS Host field and 9090 in the Port field.
- Check the Proxy DNS when using SOCKS v5 checkbox.
- Click on the OK button to save the settings.

At this point, Firefox is configured and you can browse through the SSH tunnel. To verify, open a search engine and search for “what is my ip”. The displayed IP address should be the IP address of your SSH server.

To revert back to the default settings go to Network Settings, select the Use system proxy settings radio button and save the settings.

There are also several plugins that can help you to configure Firefox’s proxy settings such as FoxyProxy .

Google Chrome

Google Chrome uses the default system proxy settings. Instead of changing your operating system proxy settings, you can start Chrome from the command line with a separate profile.

To launch Chrome using a new profile and your SSH tunnel use the following command:

Linux :

sh
/usr/bin/google-chrome \
 --user-data-dir="$HOME/proxy-profile" \
 --proxy-server="socks5://127.0.0.1:9090"

macOS :

sh
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
 --user-data-dir="$HOME/proxy-profile" \
 --proxy-server="socks5://127.0.0.1:9090"

Windows :

sh
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^
 --user-data-dir="%USERPROFILE%\proxy-profile" ^
 --proxy-server="socks5://127.0.0.1:9090"

The profile will be created automatically if it does not exist. This way you can run multiple instances of Chrome at the same time.

To confirm the SSH tunnel is working properly, search for “what is my ip”. The IP shown in your browser should be the IP address of your SSH server.

Verifying the SOCKS Proxy

You can verify the local SOCKS listener from the terminal:

Terminal
ss -ltnp | grep 9090

To test the tunnel without changing browser settings, send a request through the SOCKS proxy:

Terminal
curl --socks5-hostname 127.0.0.1:9090 https://ifconfig.me

The output should show the public IP address of your SSH server. The --socks5-hostname option sends DNS lookups through the SOCKS proxy, which helps avoid local DNS leaks.

Troubleshooting

bind: Address already in use
Another process is already using port 9090. Pick a different local port, such as 1080, and update the browser proxy settings to match.

Permission denied (publickey)
The SSH server did not accept your key. Check that your public key is installed on the server, or connect with the correct username and key file.

The browser still shows your local IP
Confirm the tunnel is running with ss -ltnp | grep 9090, then check that the browser is using 127.0.0.1 as the SOCKS host and 9090 as the port.

DNS still resolves locally
In Firefox, make sure Proxy DNS when using SOCKS v5 is enabled. For command-line tests, use curl --socks5-hostname instead of curl --socks5.

The tunnel closes when the terminal closes
Run the SSH command with -fN, define the tunnel in your SSH config, or start it inside tmux or screen .

Conclusion

For easier reuse, define the tunnel in your SSH config file or wrap it in a Bash alias that starts the tunnel and browser together.

scp Command in Linux: Secure File Transfer Examples

hello@linuxize.com (Linuxize) — Wed, 19 Sep 2018 00:31:47 +0100

When you need to copy files to or from a remote server over SSH, scp does the job with a single command. It encrypts both the transferred data and the authentication credentials, so nothing extra is needed if SSH access is already in place.

This guide explains how to use the scp command with practical examples and detailed explanations of the most common options.

Before You Begin

Before using scp, keep the following in mind:

SCP relies on SSH for data transfer. You need either an SSH key or a password to authenticate on the remote system.
The colon (:) is how scp distinguishes between local and remote paths. A path without a colon is treated as local.
You must have read permission on the source and write permission on the destination.
SCP overwrites files without warning when the source and destination share the same name.
When transferring large files, run the scp command inside a screen or tmux session to keep the transfer running if your terminal disconnects.

SCP Command Syntax

The general syntax of the scp command is:

txt
scp [OPTIONS] [[user@]host:]source [[user@]host:]destination

[[user@]host:]source — Source path. Include the username and hostname (or IP address) when the file is on a remote machine.
[[user@]host:]destination — Destination path. Same format as the source.

Local paths can be absolute or relative. Remote paths must include the host and colon.

The most commonly used scp options are:

-P — Remote host SSH port (uppercase P)
-p — Preserve modification time, access time, and mode
-r — Copy directories recursively
-C — Compress data during transfer
-q — Suppress the progress meter and non-error messages
-i — Path to the SSH private key (identity file)
-l — Limit bandwidth in Kbit/s
-o — Pass an SSH option (e.g., -o StrictHostKeyChecking=no)
-3 — Route traffic between two remote hosts through the local machine
-O — Force the legacy SCP protocol instead of SFTP

Copy a Local File to a Remote System

To copy a file from the local machine to a remote server, run:

Terminal
scp file.txt remote_username@10.10.0.2:/remote/directory

In this example, file.txt is the local file, remote_username is the user on the remote server, and 10.10.0.2 is the server IP address. The file is copied to /remote/directory on the remote host. If you omit the remote directory, the file is copied to the remote user’s home directory.

You will be prompted to enter the user password, and the transfer process will start:

output

remote_username@10.10.0.2's password:
file.txt 100% 14KB 82.1KB/s 00:00

To save the file under a different name on the remote host, specify the new filename in the destination path:

Terminal
scp file.txt remote_username@10.10.0.2:/remote/directory/newfilename.txt

If SSH on the remote host is listening on a port other than the default 22, use the -P option:

Terminal
scp -P 2322 file.txt remote_username@10.10.0.2:/remote/directory

To copy a directory and all its contents, use the -r flag for recursive copy:

Terminal
scp -r /local/directory remote_username@10.10.0.2:/remote/directory

When you want to copy multiple local files that match a pattern, let the local shell expand the wildcard before scp runs. In the following example, all .txt files from the local Projects directory are copied to the remote Projects directory:

Terminal
scp "$HOME"/Projects/*.txt remote_username@10.10.0.2:/home/user/Projects/

To preserve file metadata (modification time, access time, and mode), use the -p option:

Terminal
scp -p file.txt remote_username@10.10.0.2:/remote/directory/

To use a specific SSH key for authentication, pass it with the -i option:

Terminal
scp -i ~/.ssh/id_ed25519 file.txt remote_username@10.10.0.2:/remote/directory/

Copy a Remote File to the Local System

To copy a file from a remote server to the local machine, use the remote location as the source and the local path as the destination:

Terminal
scp remote_username@10.10.0.2:/remote/file.txt /local/directory

If you have not set up passwordless SSH login , you will be prompted to enter the user password.

To copy an entire remote directory, add the -r flag:

Terminal
scp -r remote_username@10.10.0.2:/remote/directory /local/directory

Copy Files Between Two Remote Systems

With scp, you do not need to log in to either server to transfer files between two remote machines. The following command copies /files/file.txt from host1.com to the /files directory on host2.com:

Terminal
scp user1@host1.com:/files/file.txt user2@host2.com:/files

You will be prompted to enter the passwords for both remote accounts. By default, the data flows directly between the two remote hosts.

To route the traffic through the local machine instead, use the -3 option:

Terminal
scp -3 user1@host1.com:/files/file.txt user2@host2.com:/files

Using an SSH Config File

If you regularly connect to the same hosts, defining them in the SSH config file simplifies your scp commands. Create or edit the file at ~/.ssh/config:

~/.ssh/configssh

Host myserver
HostName 10.10.0.2
User leah
Port 2222
IdentityFile ~/.ssh/id_ed25519

With this configuration, you can use the alias instead of the full connection details:

Terminal
scp file.txt myserver:/remote/directory

Setting up SSH key-based authentication removes the password prompt entirely, making transfers faster and easier to script.

Troubleshooting

Permission denied (publickey)
The remote server does not accept your SSH key. Verify that the correct key is offered with -i, or check that the public key is in the remote user’s ~/.ssh/authorized_keys file.

Connection refused
The SSH daemon is not running or is listening on a different port. Confirm the port with -P and ensure the firewall allows SSH traffic.

Not a regular file
You are trying to copy a directory without the -r flag. Add -r to copy directories recursively.

Host key verification failed
The remote host key does not match the entry in ~/.ssh/known_hosts. If the server was reinstalled, remove the old key with ssh-keygen -R hostname and try again.

Transfer is slow
Enable compression with -C to speed up transfers over slow connections. You can also limit bandwidth with -l to avoid saturating the link on shared networks.

Quick Reference

For a printable quick reference, see the scp cheatsheet .

Command	Description
`scp file.txt user@host:/path`	Copy local file to remote
`scp user@host:/path/file.txt .`	Copy remote file to local
`scp -r dir/ user@host:/path`	Copy directory recursively
`scp -P 2222 file.txt user@host:/path`	Use custom SSH port
`scp -i ~/.ssh/key file.txt user@host:/path`	Use specific SSH key
`scp -p file.txt user@host:/path`	Preserve timestamps and mode
`scp -C file.txt user@host:/path`	Compress during transfer
`scp -l 5000 file.txt user@host:/path`	Limit bandwidth to 5000 Kbit/s
`scp -3 user1@host1:/f user2@host2:/f`	Copy between two remotes via local
`scp -O file.txt user@host:/path`	Force legacy SCP protocol

FAQ

Does scp overwrite existing files?
Yes. SCP overwrites destination files without prompting. There is no built-in confirmation flag, so verify the destination path before running the command.

What is the difference between scp and sftp?
Both use SSH for encryption. SFTP is an interactive file transfer protocol that supports resuming transfers, directory listings, and file removal. SCP is a simpler one-shot copy command. Modern OpenSSH versions run the SFTP protocol internally when you use scp.

Is scp still recommended?
The scp command is still widely available and works the same way from the user’s perspective. Starting with OpenSSH 9.0, it uses the SFTP protocol internally rather than the legacy SCP/RCP protocol. For new scripts or automation, sftp or rsync may be a better long-term choice.

Can I resume an interrupted scp transfer?
No. SCP does not support resuming partial transfers. If the connection drops, you must start the transfer over. For resumable transfers, use rsync with the --partial flag.

How do I copy files without a password prompt?
Set up SSH key-based authentication between the local and remote machines. Once the public key is installed on the remote host, SCP authenticates automatically.

What does the -O flag do?
The -O flag forces scp to use the legacy SCP/RCP protocol instead of the SFTP protocol. This is sometimes needed when connecting to very old servers that do not support SFTP.

Conclusion

SCP is a straightforward tool for copying files between local and remote systems over SSH. While modern OpenSSH versions now use the SFTP protocol internally, the scp command remains widely available and works the same way from the user’s perspective.

For advanced workflows, use rsync for resumable transfers and large directory trees, or follow the --link-dest backup guide to create dated incremental snapshots. For interactive file management over SSH, use sftp .

sftp Command in Linux: Transfer Files Securely

hello@linuxize.com (Linuxize) — Sat, 17 Nov 2018 20:31:47 +0100

When you need to move files to or from a remote server over SSH, SFTP (SSH File Transfer Protocol) gives you an interactive file transfer shell. You can browse remote directories, upload and download files, resume interrupted transfers, and manage files without opening a full SSH shell.

Compared to FTP , SFTP provides the same core functionality while being significantly more secure and easier to configure.

Unlike SCP , which supports only file transfers, SFTP supports a full range of file operations on remote files, including resuming interrupted transfers.

This guide shows you how to use the sftp command on Linux with practical examples for everyday file transfers.

Prerequisites

To upload or modify files via SFTP, you need write permission on the remote system.

For large transfers, it is recommended to run the sftp command inside a screen or tmux session to prevent interruptions.

The directory from which you run the sftp command becomes your local working directory.

Info

Do not confuse SFTP with FTPS. Both protocols serve the same purpose. However, FTPS stands for FTP Secure, and it is an extension to the standard FTP protocol that adds TLS/SSL encryption.

SFTP Command Syntax

The basic syntax of the sftp command is:

txt
sftp [OPTIONS] [user@]host[:path]

You can also use an SFTP URI:

txt
sftp://[user@]host[:port][/path]

The user value is the remote username, and host is the server hostname or IP address. If you add a path after the host, SFTP opens that remote directory after login. When the path points to a file and non-interactive authentication is available, SFTP can retrieve the file directly.

Connecting to a Remote Server

SFTP works on a client-server model. It is a subsystem of SSH and supports all SSH authentication methods.

To connect to a remote system, run the sftp command followed by the remote server username and the IP address or domain name:

Terminal
sftp remote_username@server_ip_or_hostname

If you are connecting to the host using password authentication, you will be prompted to enter the user password.

Once authenticated, you will be presented with the sftp prompt, and you can start interacting with the remote server:

output

Connected to remote_username@server_ip_or_hostname.
sftp>

If the remote SSH server listens on a non-standard port (for example, 2222), use the -P option to specify the port:

Terminal
sftp -P 2222 remote_username@server_ip_or_hostname

Common SFTP Options

The sftp command accepts several options that modify its behavior. Here are the most commonly used ones:

-P port - Specifies the port to connect to on the remote host.
-i identity_file - Selects the private key file for public key authentication.
-o ssh_option - Passes options to SSH in the format used in the SSH config file .
-C - Enables compression, which can speed up transfers over slow connections.
-v - Prints debugging messages about the connection and authentication process.
-b batchfile - Reads SFTP commands from a file instead of the terminal.
-p - Preserves modification times, access times, and file modes during transfers.
-r - Recursively copies entire directories when uploading and downloading. SFTP does not follow symbolic links during the traversal.
-a - Attempts to continue interrupted transfers instead of overwriting existing partial copies. Use it only when the existing partial contents match the source, or the resulting file may be corrupt.
-l limit - Limits bandwidth in Kbit/s.
-J destination - Connects through a jump host.

For example, to connect with verbose output and compression enabled:

Terminal
sftp -v -C remote_username@server_ip_or_hostname

Basic SFTP Commands

Most SFTP commands are similar or identical to the Linux shell commands.

To get a list of all available SFTP commands, type help, or ?.

Terminal
help

The output will include a long list of all available commands, including a short description of each command:

output

Available commands:
bye Quit sftp
cd path Change remote directory to 'path'
...
...
version Show SFTP version
!command Execute 'command' in local shell
! Escape to local shell
? Synonym for help

Navigating Directories with SFTP

When you are logged in to the remote server, your current working directory is the remote user’s home directory. You can check that by typing:

Terminal
pwd

output

Remote working directory: /home/remote_username

To list the remote files and directories, use the ls command:

Terminal
ls

To navigate to another directory, use the cd command. For example, to switch to the /tmp directory, you would type:

Terminal
cd /tmp

The above commands are used to navigate and work on the remote location.

The SFTP shell also provides commands for local navigation, information, and file management. The local commands are prefixed with the letter l.

For example, to print the local working directory, you would type:

Terminal
lpwd

output

Local working directory: /home/local_username

To list local files:

Terminal
lls

The lcd command changes the local working directory, which is where downloaded files are written. If you want everything you fetch to land in ~/Downloads, switch to it before running get:

Terminal
lcd ~/Downloads

When you need something the SFTP shell does not provide, prefix a command with ! to run it in your local shell. Typing ! on its own drops you into a local shell, and exit brings you back to the SFTP prompt:

Terminal
!tar -czf archive.tar.gz project/

The progress command toggles the transfer progress meter. Turning it off keeps the output readable when you are piping a session to a log file:

Terminal
progress

Downloading Files

To download a single file from the remote server, use the get command:

Terminal
get filename.zip

The output should look something like this:

output

Fetching /home/remote_username/filename.zip to filename.zip
/home/remote_username/filename.zip 100% 24MB 1.8MB/s 00:13

When downloading files with sftp, the files are saved in the directory from which you typed the sftp command, or in whichever directory you last set with lcd.

If you want to save the downloaded file with a different name, specify the new name as the second argument:

Terminal
get filename.zip local_filename.zip

To download a directory from the remote system, use the recursive -r option:

Terminal
get -r remote_directory

If a file transfer fails or is interrupted, you can resume it using the reget command.

The syntax of reget is the same as the syntax of get:

Terminal
reget filename.zip

To resume a recursive directory download, add -r:

Terminal
reget -r remote_directory

Uploading Files

To upload a file from the local machine to the remote SFTP server, use the put command:

Terminal
put filename.zip

The output should look something like this:

output

Uploading filename.zip to /home/remote_username/filename.zip
filename.zip 100% 12MB 1.7MB/s 00:06

The first line confirms the local source and the remote destination, and the second line reports the progress, the transferred size, the average speed, and the elapsed time. The file lands in the remote working directory, which is the remote user’s home directory unless you moved somewhere else with cd.

If the file you want to upload is not located in your current working directory, use the absolute path to the file:

Terminal
put /home/local_username/backups/filename.zip

To store the file under a different name on the remote server, pass the new name as the second argument:

Terminal
put filename.zip archive-2026.zip

You can also send a file straight into a specific remote directory without changing the remote working directory first. End the path with a slash so SFTP treats it as a directory:

Terminal
put filename.zip /var/www/uploads/

When working with put, you can use the same options that are available with the get command.

To upload a local directory, use -r:

Terminal
put -r local_directory

To resume an interrupted upload:

Terminal
reput filename.zip

To resume a recursive directory upload, run:

Terminal
reput -r local_directory

Transferring Multiple Files

Both get and put accept glob patterns, so you do not need a separate command to move several files at once. To download every .txt file from the remote working directory:

Terminal
get *.txt

Uploading works the same way:

Terminal
put *.log

If you are coming from ftp or from PuTTY’s psftp, you will probably reach for mget and mput. OpenSSH SFTP accepts both names, but they are undocumented aliases, so mget *.csv and get *.csv do exactly the same thing. Prefer the documented names, because the aliases appear neither in the man page nor in the help output.

There is also no prompt command to switch off. Wildcard transfers always run for every matching file without asking for confirmation, so check the pattern before you point it at a large directory.

File Manipulations with SFTP

Typically, to perform tasks on a remote server, you would connect via SSH and run your commands in the shell. However, in some situations, the user may have only SFTP access (no full SSH shell) to the remote server. This is what an SFTP chroot jail gives you: an account that can move files but cannot log in to a shell.

SFTP allows you to perform some basic file manipulation commands. Below are some examples of how to use the SFTP shell:

Get information about the remote system’s disk usage :

Terminal
df

output

 Size Used Avail (root) %Capacity
20616252 1548776 18002580 19067476 7%

Create a new directory on the remote server:
Terminal
```
mkdir directory_name
```
Rename a file on the remote server:
Terminal
```
rename file_name new_file_name
```
Delete a file on the remote server:
Terminal
```
rm file_name
```
Delete a directory on the remote server:
Terminal
```
rmdir directory_name
```
Change the permissions of a file on the remote system:
Terminal
```
chmod 644 file_name
```
Change the owner of a file on the remote system:
Terminal
```
chown user_id file_name
```
You must supply the user ID to the chown and chgrp commands.
Change the group owner of a remote file with:
Terminal
```
chgrp group_id file_name
```

Transferring Files Without the Interactive Shell

You do not always need the SFTP prompt. When the destination includes a path that points to a file rather than a directory, sftp fetches it and exits:

Terminal
sftp remote_username@server_ip_or_hostname:/var/log/nginx/access.log

The file is saved in your current local directory under the same name. To save it somewhere else, or under a different name, add a local path as a second argument:

Terminal
sftp remote_username@server_ip_or_hostname:/var/log/nginx/access.log ~/logs/access-copy.log

With non-interactive public-key authentication and host verification already configured, the whole transfer runs unattended. With password authentication, sftp asks for the password first and then fetches the file.

If the path points to a directory, SFTP logs in and opens the interactive shell there instead of transferring anything. Add a trailing slash when you want to force that behavior for a name that could be read either way:

Terminal
sftp remote_username@server_ip_or_hostname:/var/www/

Batch Mode

You can use batch mode to automate file transfers in scripts. Create a file containing SFTP commands, one per line, then execute it with the -b option.

In the following example, we create a batch file with commands to download files:

sftp_commands.txttxt
cd /var/www
get database_backup.sql
get config.php
bye

Run the batch file:

Terminal
sftp -b sftp_commands.txt remote_username@server_ip_or_hostname

For batch mode to work without manual intervention, you must use SSH key-based authentication .

If one of the batch commands fails, SFTP terminates immediately. To continue after a specific command fails, prefix that command with - inside the batch file:

sftp_commands.txttxt
cd /var/www
-get optional-report.csv
get database_backup.sql
bye

In this example, SFTP continues if optional-report.csv is missing, but it still stops if cd /var/www or get database_backup.sql fails.

Disconnecting

Once you are done with your work, close the connection by typing bye or quit. Both commands end the session:

Terminal
bye

Tips for Frequent Use

Set up an SSH key-based authentication and connect to your Linux servers without entering a password.
If you regularly connect to the same hosts, simplify your workflow by defining all of your connections in the SSH config file .
~/.ssh/configssh
```
Host myserver_name
HostName 10.10.0.2
User leah
Port 2222
```

Quick Reference

For a printable quick reference, see the SFTP cheatsheet .

Task	Command
Connect to server	`sftp user@host`
Connect on custom port	`sftp -P 2222 user@host`
Download one file and exit	`sftp user@host:/path/file`
Download one file to a local path	`sftp user@host:/path/file ./local.txt`
Download file	`get filename`
Download directory	`get -r directory`
Resume download	`reget filename`
Resume directory download	`reget -r directory`
Upload file	`put filename`
Upload under a different name	`put filename newname`
Upload into a remote directory	`put filename /remote/dir/`
Upload directory	`put -r directory`
Resume upload	`reput filename`
Resume directory upload	`reput -r directory`
Download multiple files	`get *.txt`
Upload multiple files	`put *.log`
List remote files	`ls`
List local files	`lls`
Change remote directory	`cd /path`
Change local directory	`lcd /path`
Print remote directory	`pwd`
Print local directory	`lpwd`
Create remote directory	`mkdir dirname`
Delete remote file	`rm filename`
Delete remote directory	`rmdir dirname`
Rename remote file	`rename oldname newname`
Change permissions	`chmod 644 filename`
Run a local shell command	`!command`
Run batch file	`sftp -b sftp_commands.txt user@host`
Disconnect	`bye` or `quit`

Troubleshooting

Connection refused
The SSH server may not be running, or a firewall is blocking port 22 (or your custom port). Verify the server is accessible and the SSH service is running.

Permission denied (publickey)
Your SSH key is not authorized on the remote server, or you are using the wrong key. Use -i /path/to/key to specify the correct identity file, or check that your public key is in the remote user’s ~/.ssh/authorized_keys.

No such file or directory
The file or directory you are trying to access does not exist. Use ls to verify the path and check for typos.

Permission denied when uploading
You do not have write permission to the destination directory. Contact the server administrator or choose a directory where you have write access.

Connection timed out
Network issues or firewall rules are preventing the connection. Check your network connection and verify the server IP address is correct.

Broken pipe or connection reset
The connection was interrupted, often due to network instability or server-side timeouts. Use reget or reput to resume interrupted transfers.

FAQ

What is the default SFTP port?
SFTP uses port 22 by default, the same as SSH. You can specify a different port with the -P option.

What is the difference between SFTP and SCP?
Both use SSH for secure transfers. SCP is simpler and only transfers files, while SFTP provides an interactive shell with directory navigation, file manipulation, and the ability to resume interrupted transfers.

What is the difference between SFTP and FTPS?
SFTP runs over SSH (port 22), while FTPS is FTP with TLS/SSL encryption (typically port 990 or 21). SFTP is generally easier to configure since it uses a single port.

Can I use SFTP without a password?
Yes, by setting up SSH key-based authentication . This is also required for batch mode automation.

How do I transfer an entire directory?
Use the -r (recursive) option with get or put inside the SFTP prompt. For example: get -r remote_directory or put -r local_directory.

How do I resume a failed transfer?
Use reget to resume downloads and reput to resume uploads. For recursive directory transfers, use reget -r or reput -r.

Conclusion

The sftp command is useful when you need secure, interactive file transfers over SSH. For one-time copies, scp may be faster to type, but SFTP is a better fit when you need to browse directories, resume transfers, or automate a set of file operations with batch mode.

If you are working on a desktop machine, you can use a GUI SFTP client like WinSCP or FileZilla to connect to the remote server and download or upload files.

How to Change the SFTP Port

hello@linuxize.com (Linuxize) — Fri, 24 Jul 2020 21:40:24 +0100

SFTP (SSH File Transfer Protocol) is a secure file protocol for transferring files between two hosts over an encrypted connection. It also allows you to perform various file operations on remote files and to resume file transfers.

SFTP can be used as a replacement for the legacy FTP protocol. It has all the functionality of FTP but with a more secure connection.

This article explains how to change the default SFTP port in Linux. We will also show you how to configure your firewall to allow connections on the new port.

Info

Do not confuse SFTP with FTPS. Both protocols serve the same purpose. However, FTPS stands for FTP Secure, and it is an extension to the standard FTP protocol with support for TLS.

What Port Does SFTP Use

SFTP is a subsystem of SSH and shares the same port and the same level of security as SSH.

The default SFTP port is 22.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Command	Description
`sudo ufw allow 4422/tcp`	Open port in UFW
`sudo firewall-cmd --permanent --zone=public --add-port=4422/tcp`	Open port in FirewallD
`sudo sshd -t`	Test sshd_config for syntax errors
`sudo systemctl restart ssh`	Restart SSH service (Debian, Ubuntu)
`sudo systemctl restart sshd`	Restart SSH service (Fedora, RHEL)
`ss -an \| grep 4422`	Verify SSH is listening on the new port
`sftp -P 4422 user@host`	Connect via SFTP on a custom port

Changing the SFTP Port

Changing the default SFTP/SSH port adds an extra layer of security to your server by reducing the risk of automated attacks.

Info

The best way to protect your server from attacks is to configure your firewall to allow access to port 22 only from trusted hosts and set up SSH key-based authentication . For a broader set of hardening steps, see SSH Hardening Best Practices .

The following steps describe how to change the SSH port on Linux machines.

1. Choosing a New Port Number

In Linux, port numbers below 1024 are reserved for well-known services and can only be bound to by root. Although you can use a port within the 1–1024 range for the SSH service, it is recommended to choose a port above 1024 to avoid conflicts with other services. The range 49152–65535 consists of ephemeral ports not assigned to any standard service and is a safe choice.

Before picking a port, verify it is not already in use:

Terminal
ss -tlnp | grep 4422

If the command returns no output, the port is free. This example uses port 4422, but you can choose any available port.

2. Adjusting the Firewall

Before changing the SFTP/SSH port, you will need to open the new port in your firewall.

If you are using UFW , run the following command to open the port:

Terminal
sudo ufw allow 4422/tcp

On Fedora, RHEL, and derivatives, the default firewall management tool is FirewallD. To open the port, run:

Terminal
sudo firewall-cmd --permanent --zone=public --add-port=4422/tcp
sudo firewall-cmd --reload

On Fedora, RHEL, and derivatives, you may also need to update the SELinux policy to allow the new SSH port:

Terminal
sudo semanage port -a -t ssh_port_t -p tcp 4422

If you are using another Linux distribution that runs iptables, run:

Terminal
sudo iptables -A INPUT -p tcp --dport 4422 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

3. Configuring SFTP/SSH

The SSH server configuration is stored in the /etc/ssh/sshd_config file. Open the file with your text editor:

Terminal
sudo vim /etc/ssh/sshd_config

Search for the line starting with Port 22. Typically, this line is commented out using the hash (#) symbol. Remove the hash and enter your new SSH port number:

/etc/ssh/sshd_configini
Port 4422

Before restarting the service, test the configuration file for syntax errors:

Terminal
sudo sshd -t

If the command returns no output, the configuration is valid. An incorrect configuration will prevent the SSH service from starting, so always run this check before restarting.

Once done, save the file and restart the SSH service for the changes to take effect.

On Debian and Ubuntu:

Terminal
sudo systemctl restart ssh

On Fedora, RHEL, and derivatives, the SSH service is named sshd:

Terminal
sudo systemctl restart sshd

Verify that the SSH daemon is listening on the new port:

Terminal
ss -an | grep 4422

The output should look something like this:

output

tcp LISTEN 0 128 0.0.0.0:4422 0.0.0.0:*
tcp ESTAB 0 0 192.168.121.108:4422 192.168.121.1:57638
tcp LISTEN 0 128 [::]:4422 [::]:*

Using the New SFTP Port

To specify the port number, invoke the sftp command with the -P option followed by the new port number:

Terminal
sftp -P 4422 username@remote_host_or_ip

If you are using a GUI SFTP client, enter the new port number in the client interface.

To avoid specifying the port on every connection, you can define it in the SSH config file :

~/.ssh/configini
Host myserver
 HostName remote_host_or_ip
 Port 4422
 User username

With this in place, you can connect with just sftp myserver.

Troubleshooting

SSH service fails to restart after changing the port
A syntax error in sshd_config will prevent the service from starting. Run sudo sshd -t to check for errors before restarting. Fix any reported issues, then retry.

Cannot connect on the new port
The firewall rule may not have been applied correctly. Run ss -tlnp | grep 4422 to confirm the SSH daemon is listening, and run sudo ufw status or sudo firewall-cmd --list-ports to confirm the port is open in the firewall.

SELinux denying the new port on RHEL or Fedora
SELinux restricts SSH to ports it knows about. Register the new port with sudo semanage port -a -t ssh_port_t -p tcp 4422. If semanage is not installed, install it with sudo dnf install policycoreutils-python-utils.

Locked out of the server after changing the port
Do not close your existing SSH session until you have verified the new port works by opening a second session with ssh -p 4422 user@host. If you are locked out, use the server provider’s emergency console or out-of-band access to revert the port change.

FAQ

Does changing the SSH port also change the SFTP port?
Yes. SFTP is a subsystem of SSH and runs on the same port. Changing the SSH port in sshd_config automatically changes the port for both SSH and SFTP connections.

Can SSH listen on multiple ports at the same time?
Yes. Add multiple Port lines to /etc/ssh/sshd_config, one per port:

/etc/ssh/sshd_configini
Port 22
Port 4422

This lets you keep port 22 open temporarily while you verify the new port works.

What port number should I choose?
Choose a port above 1024 to avoid conflicts with reserved services. Ports in the range 49152–65535 are not assigned to any standard service. Avoid commonly scanned alternatives such as 2222 or 8022.

Will changing the port stop all brute-force attacks?
It significantly reduces automated scan traffic but is not a substitute for proper security measures. Use SSH key-based authentication and restrict access by IP address in your firewall for effective protection.

Conclusion

Changing the default SFTP/SSH port is a simple step that reduces exposure to automated scanning. Combined with SSH key-based authentication and firewall rules, it forms part of a solid baseline for securing remote access. For more ways to restrict SFTP access, see How to Set Up an SFTP Chroot Jail .

If you have any questions, feel free to leave a comment below.

How to Set Up SFTP Chroot Jail

hello@linuxize.com (Linuxize) — Sun, 07 Apr 2019 13:40:24 +0100

If you are a system administrator managing a Linux server, you may need to grant SFTP access to some users to upload files to their home directories. By default, users that can log in to the system via SSH, SFTP, and SCP can browse the entire filesystem, including other users’ directories.

This may not be a problem if these users are trusted. If you do not want logged-in users to navigate around the system, you will need to restrict user access to their home directory. This adds an extra layer of security, especially on systems with multiple users.

In this guide, we will explain how to set up an SFTP Chroot Jail environment that will restrict users to their home directories. The users will have SFTP access only; SSH access will be disabled. These instructions work for any modern Linux distribution including Ubuntu, Debian, and Fedora.

Quick Reference

Task	Command
Create SFTP group	`sudo groupadd sftponly`
Create chroot user	`sudo useradd -g sftponly -s /bin/false -m -d /home/user user`
Set home directory ownership	`sudo chown root: /home/user`
Set home directory permissions	`sudo chmod 755 /home/user`
Restart SSH (Debian/Ubuntu)	`sudo systemctl restart ssh`
Restart SSH (Fedora/RHEL)	`sudo systemctl restart sshd`
Test SSH config syntax	`sudo sshd -t`

For a printable quick reference, see the SSH cheatsheet .

Creating an SFTP Group

Instead of configuring the OpenSSH server for each user individually, we will create a new group and add all our chrooted users to this group.

Run the following groupadd command to create the sftponly user group:

Terminal
sudo groupadd sftponly

Tip

You can name the group as you like.

Adding Users to the SFTP Group

The next step is to add the users you want to restrict to the sftponly group.

If this is a new setup and the user does not exist, you can create a new user account by typing:

Terminal
sudo useradd -g sftponly -s /bin/false -m -d /home/username username

The -g sftponly option will add the user to the sftponly group.
The -s /bin/false option sets the user’s login shell. By setting the login shell to /bin/false, the user will not be able to log in to the server via SSH.
The -m -d /home/username options tell useradd to create the user home directory.

Set a strong password for the newly created user:

Terminal
sudo passwd username

If the user you want to restrict already exists, add the user to the sftponly group and change the user’s shell:

Terminal
sudo usermod -G sftponly -s /bin/false username2

The user home directory must be owned by root and have 755 permissions :

Terminal
sudo chown root: /home/username
sudo chmod 755 /home/username

Since the user home directories are owned by the root user, these users will not be able to create files and directories in their home directories. If there are no directories in the user’s home, you will need to create new directories to which the user will have full access. For example, you can create the following directories:

Terminal
sudo mkdir /home/username/{public_html,uploads}
sudo chmod 755 /home/username/{public_html,uploads}
sudo chown username:sftponly /home/username/{public_html,uploads}

If a web application is using the user’s public_html directory as document root, these changes may lead to permissions issues. For example, if you are running WordPress you will need to create a PHP pool that will run as the user owning the files and add the web server to the sftponly group.

Configuring SSH

SFTP is a subsystem of SSH and supports all SSH authentication mechanisms.

Open the SSH configuration file /etc/ssh/sshd_config with your text editor :

Terminal
sudo nano /etc/ssh/sshd_config

Search for the line starting with Subsystem sftp, usually at the end of the file. If the line starts with a hash #, remove the hash and modify it to look like the following:

/etc/ssh/sshd_configini
Subsystem sftp internal-sftp

Towards the end of the file, add the following block of settings:

/etc/ssh/sshd_configini
Match Group sftponly
 ChrootDirectory %h
 ForceCommand internal-sftp
 AllowTcpForwarding no
 X11Forwarding no

The ChrootDirectory directive specifies the path to the chroot directory. %h means the user home directory. This directory must be owned by the root user and not writable by any other user or group.

Be extra careful when modifying the SSH configuration file. An incorrect configuration may cause the SSH service to fail to start. You can test the configuration syntax before restarting the service:

Terminal
sudo sshd -t

Once you are done, save the file and restart the SSH service to apply the changes. On Ubuntu and Debian:

Terminal
sudo systemctl restart ssh

On Fedora, RHEL, and derivatives, the SSH service is named sshd:

Terminal
sudo systemctl restart sshd

Testing the Configuration

Now that you have configured SFTP chroot, you can try to log in to the remote machine through SFTP using the credentials of the chrooted user. In most cases, you will use a desktop SFTP client like FileZilla , but in this example, we will use the sftp command .

Open an SFTP connection using the sftp command followed by the remote server username and the server IP address or domain name:

Terminal
sftp username@192.168.121.30

You will be prompted to enter the user password. Once connected, the remote server will display a confirmation message and the sftp> prompt:

output

username@192.168.121.30's password:
sftp>

Run the pwd command, and if everything is working as expected the command should return /:

output

sftp> pwd
Remote working directory: /

You can also list the remote files and directories using the ls command, and you should see the directories that we have previously created:

output

sftp> ls
public_html uploads

Troubleshooting

“bad ownership or modes for chroot directory” error The chroot directory must be owned by root and must not be writable by the group or other users. Run sudo chown root: /home/username and sudo chmod 755 /home/username to fix ownership and permissions.

SSH service fails to start after editing sshd_config Run sudo sshd -t before restarting the service to check the configuration for syntax errors. Fix any reported errors before restarting.

User can still log in via SSH Verify the user shell is set to /bin/false with getent passwd username. Also confirm the ForceCommand internal-sftp line is present inside the Match Group sftponly block in sshd_config.

SFTP connection is refused or times out Ensure the Subsystem sftp internal-sftp line is uncommented in sshd_config and the SSH service has been restarted. Check the SSH service status with sudo systemctl status ssh.

On Fedora, RHEL, and derivatives, use sudo systemctl status sshd instead.

FAQ

Can I allow SFTP access without granting SSH shell access? Yes. Set the user’s login shell to /bin/false and add ForceCommand internal-sftp inside the Match Group block. This allows SFTP connections while blocking interactive SSH sessions.

Does SFTP chroot support SSH key authentication? Yes. SFTP is a subsystem of SSH and supports all SSH authentication mechanisms, including key-based authentication.

Can multiple users share the same chroot setup? Yes. Add all users to the sftponly group and set ChrootDirectory %h so each user is jailed to their own home directory.

Why must the chroot directory be owned by root? OpenSSH requires the chroot directory to be owned by root and not writable by anyone else. If this condition is not met, the connection will fail with a “bad ownership or modes” error.

Conclusion

You have now set up an SFTP Chroot Jail on your Linux server, restricting SFTP users to their own home directories while blocking SSH shell access. For additional security, consider changing the default SSH port or enabling SSH key-based authentication to further harden your server.

How to Use SSHFS to Mount Remote Directories over SSH

hello@linuxize.com (Linuxize) — Sun, 12 May 2019 19:40:24 +0100

SSHFS (SSH Filesystem) is a filesystem client based on FUSE for mounting remote directories over an SSH connection. SSHFS uses the SFTP protocol, which is a subsystem of SSH and is enabled by default on most SSH servers.

When compared to other network file system protocols such as NFS and Samba , the advantage of SSHFS is that it does not require any additional configuration on the server side. To use SSHFS you only need SSH access to the remote server.

Because SSHFS uses SFTP , all data transmitted between the server and the client is encrypted and decrypted. This results in slightly degraded performance compared to NFS and higher CPU usage on both the client and server.

This guide explains how to install SSHFS on Linux, macOS, and Windows and how to mount a remote directory.

Quick Reference

Task	Command
Mount remote directory	`sshfs user@host:/remote/dir /local/mountpoint`
Mount with SSH key	`sshfs -o IdentityFile=~/.ssh/id_rsa user@host:/remote/dir /local/mountpoint`
Mount with custom port	`sshfs -o port=2222 user@host:/remote/dir /local/mountpoint`
Mount with reconnect	`sshfs -o reconnect,ServerAliveInterval=15 user@host:/remote/dir /local/mountpoint`
Unmount	`fusermount -u /local/mountpoint`
List SSHFS mounts	`mount \| grep fuse.sshfs`
Install on Ubuntu/Debian	`sudo apt install sshfs`
Install on Fedora/RHEL	`sudo dnf install fuse-sshfs`

Installing SSHFS

SSHFS packages are available for all major operating systems.

Ubuntu, Debian, and Derivatives

SSHFS is available from the default Ubuntu and Debian repositories. Update the packages index and install the sshfs client:

Terminal
sudo apt update
sudo apt install sshfs

Fedora, RHEL, and Derivatives

On Fedora, RHEL, and derivatives, run the following command to install SSHFS:

Terminal
sudo dnf install fuse-sshfs

macOS

On macOS, SSHFS requires macFUSE. Install macFUSE first, then install an SSHFS build from the official SSHFS releases:

Terminal
brew install --cask macfuse

Warning

Homebrew no longer ships a maintained sshfs formula for macOS. After installing macFUSE, download a compatible SSHFS package from the official SSHFS releases or follow the current instructions in the macFUSE SSHFS guide .

Windows

Windows users need to install two packages:

WinFsp — a Windows filesystem driver required by SSHFS-Win
SSHFS-Win — the SSHFS client for Windows

Install WinFsp first, then install SSHFS-Win.

Mounting a Remote File System

The following instructions apply to Linux and macOS.

To mount a remote directory, the SSH user must have access to it. The sshfs command takes the following form:

txt
sshfs [user@]host:[remote_directory] mountpoint [options]

The sshfs command reads the SSH config file and applies per-host settings automatically. If the remote directory is not specified, it defaults to the remote user’s home directory.

For example, to mount the home directory of a user named linuxize on a remote host with IP address 192.168.121.121, first create a directory to use as a mount point:

Terminal
mkdir ~/linuxizeremote

Then mount the remote directory:

Terminal
sshfs linuxize@192.168.121.121:/home/linuxize ~/linuxizeremote

You will be prompted for the user’s password. To avoid entering the password each time you mount, set up passwordless SSH login using SSH keys.

Once mounted, you can interact with the remote files as if they were local — edit, delete, rename, or create new files and directories.

Verify the mount is active:

Terminal
mount | grep fuse.sshfs

output

linuxize@192.168.121.121:/home/linuxize on /home/linuxize/linuxizeremote type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Common Mount Options

You can pass options to sshfs with the -o flag. Multiple options are separated by commas:

Terminal
sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 linuxize@192.168.121.121:/home/linuxize ~/linuxizeremote

Useful options:

-o reconnect — reconnect automatically if the connection is interrupted
-o ServerAliveInterval=15 — send a keep-alive packet every 15 seconds
-o ServerAliveCountMax=3 — disconnect after 3 unanswered keep-alive packets
-o allow_other — allow other users on the local machine to access the mount (requires user_allow_other in /etc/fuse.conf)
-o follow_symlinks — follow symbolic links on the remote host
-o IdentityFile=~/.ssh/id_rsa — specify which SSH private key to use
-o port=2222 — connect to a non-standard SSH port
-o compression=yes — enable compression (useful on slow connections)

Persistent Mount with /etc/fstab

To mount a remote directory automatically at boot, add an entry to the local machine’s /etc/fstab file. Use fuse.sshfs as the filesystem type.

When creating a persistent mount, SSH key-based authentication is required since there is no interactive prompt at boot time.

/etc/fstabsh
user@host:/remote/dir /local/mountpoint fuse.sshfs defaults,_netdev,nofail,x-systemd.automount,IdentityFile=/home/user/.ssh/id_rsa,reconnect,ServerAliveInterval=15 0 0

The key options for SSHFS fstab entries:

_netdev — tells the system this is a network mount; wait for the network before mounting
nofail — do not report an error if the remote host is unreachable at boot
x-systemd.automount — mount on first access rather than at boot (avoids boot delays)
IdentityFile — path to the SSH private key

After editing /etc/fstab, test the entry without rebooting:

Terminal
sudo mount -a

Mounting a Remote Directory on Windows

Windows users can use Windows Explorer to map a network drive to the remote directory.

Open Windows Explorer, right-click on “This PC”, and select “Map network drive”. Choose a drive letter and enter the remote path in the following format in the “Folder” field:

txt
\\sshfs\user@host[\PATH]

Unmounting a Remote File System

To detach a mounted SSHFS filesystem, use either fusermount or umount followed by the mount point:

Terminal
fusermount -u ~/linuxizeremote

Terminal
umount ~/linuxizeremote

If the mount is unresponsive (for example, after a network interruption), add the -z flag to force a lazy unmount:

Terminal
fusermount -uz ~/linuxizeremote

Troubleshooting

“Transport endpoint is not connected”
This error appears when the SSHFS connection dropped but the mount point was not cleaned up. Unmount with fusermount -uz /local/mountpoint and remount. To prevent this, use the -o reconnect,ServerAliveInterval=15 options when mounting.

“Connection reset by peer” or mount goes unresponsive
The SSH server dropped the connection due to inactivity. Add -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 to your mount command or fstab entry to keep the connection alive and reconnect automatically.

“Permission denied (publickey)”
SSH key-based authentication failed. Check that the correct key is being used with -o IdentityFile=~/.ssh/id_rsa and that the public key is present in ~/.ssh/authorized_keys on the remote host.

Mount disappears after reboot
If the mount was created manually with sshfs, it does not survive a reboot. Add an entry to /etc/fstab with the _netdev and x-systemd.automount options as shown in the persistent mount section.

Other users cannot access the mount
By default, only the user who created the SSHFS mount can access it. To allow other users, mount with -o allow_other and ensure /etc/fuse.conf contains the line user_allow_other.

FAQ

What is the difference between SSHFS and SCP or rsync?
SCP and rsync transfer files between systems — they copy files from one place to another. SSHFS mounts the remote directory so you can access it in place, using any application or tool as if the files were local. No copying is needed.

Does SSHFS work with password authentication?
Yes, for manual mounts. You will be prompted for a password on each mount. For persistent fstab mounts or automated scripts, SSH key-based authentication is required since there is no prompt at boot time.

Is SSHFS suitable for high-performance file transfers?
SSHFS has higher latency than NFS or direct access because all data is encrypted over SSH. It is well suited for occasional file access and editing. For large-scale or performance-critical transfers, use rsync or NFS.

How do I mount as a different user?
Specify the remote username in the mount command: sshfs remoteuser@host:/path /local/mountpoint. The remote user must have read access to the directory being mounted.

Conclusion

SSHFS is a simple way to access remote files over SSH without any server-side configuration. For a complete list of options, run man sshfs in your terminal. To further secure your SSH server, consider setting up an SFTP chroot jail for restricted users and changing the default SSH port .

How to Transfer Files with Rsync over SSH

hello@linuxize.com (Linuxize) — Mon, 19 Aug 2019 20:11:37 +0100

rsync over SSH is one of the most efficient ways to copy and synchronize files between Linux systems. It combines secure transport with fast incremental transfers, making it useful for backups, deployments, and routine file sync tasks.

This guide explains how to transfer files with rsync over SSH, including local-to-remote and remote-to-local copies, custom SSH ports, dry runs, and directory synchronization.

If you want to keep dated backup versions instead of one synchronized copy, see our guide to rsync incremental backups with --link-dest .

Our interactive rsync command builder generates these commands for you, including the -e "ssh -p PORT" option for custom ports.

Quick Reference

Common rsync over SSH patterns. For a printable quick reference, see the rsync cheatsheet .

Command	Description
`rsync -a file.txt user@host:/dest/`	Copy a file to remote
`rsync -a user@host:/src/file.txt /dest/`	Copy a file from remote
`rsync -a /src/ user@host:/dest/`	Sync directory contents to remote
`rsync -a -n /src/ user@host:/dest/`	Dry run: preview changes without transferring
`rsync -a -P /src/ user@host:/dest/`	Show progress bar during transfer
`rsync -a -z /src/ user@host:/dest/`	Enable compression
`rsync -a --delete /src/ user@host:/dest/`	Mirror: delete extra files on remote
`rsync -a --exclude="*.log" /src/ user@host:/dest/`	Exclude files by pattern
`rsync -a -e "ssh -p PORT" /src/ user@host:/dest/`	Use a custom SSH port

Requirements

The rsync utility must be installed on both the destination and the source systems. If it is not installed you can install it using your distribution’s package manager:

Ubuntu and Debian:
Terminal
```
sudo apt install rsync
```
Fedora, RHEL, and Derivatives:
Terminal
```
sudo dnf install rsync
```
SSH access to the remote computer.
The user running the rsync command and the remote SSH user must have appropriate permissions to read and write files.

Using `rsync` to Transfer Files over SSH

With rsync, you can transfer files and directories over SSH from and to remote servers.

The general syntax for transferring files with rsync is as follows:

txt
Local to Remote: rsync [OPTION]... -e ssh [SRC]... [USER@]HOST:DEST
Remote to Local: rsync [OPTION]... -e ssh [USER@]HOST:SRC... [DEST]

Where SRC is the source directory, DEST is the destination directory USER is the remote SSH username and HOST is the remote SSH host or IP Address.

The newer versions of rsync are configured to use SSH as default remote shell so you can omit the -e ssh option.

For example, to transfer a single file /opt/file.zip from the local system to the /var/www/ directory on the remote system with IP 12.12.12.12 you would run:

Terminal
rsync -a /opt/file.zip user@12.12.12.12:/var/www/

The -a option stands for archive mode which syncs directories recursively, transfers special and block devices, preserves symbolic links, modification times, group, ownership, and permissions.

If you haven’t set a passwordless SSH login to the remote machine, you will be prompted to enter the user password.

If the file exists on the remote server it will be overwritten. If you want to save the file under a different name, specify the new name:

Terminal
rsync -a /opt/file.zip user@12.12.12.12:/var/www/file2.zip

To transfer data from a remote to a local machine, use the remote location as the source and the local location as destination:

Terminal
rsync -a user@12.12.12.12:/var/www/file.zip /opt/

Transferring directories with rsync over SSH is the same as transferring files.

One of the most important rsync behaviors to understand is how a trailing slash on the source path changes the result.

It is important to know that rsync gives different treatment to the source directories with a trailing slash /. When the source directory has a trailing slash, rsync will copy only the contents of the source directory to the destination directory. When the trailing slash is omitted the source directory will be copied inside the destination directory.

For example to transfer the local /opt/website/images/ directory to the /var/www/images/ directory on a remote machine you would type:

Terminal
rsync -a /home/linuxize/images/ user@12.12.12.12:/var/www/images/

Use the --delete option if you want to synchronize the local and remote directory. Be careful when using this option as it will delete files in the destination directory if they do not exist in the source directory.

Terminal
rsync -a --delete /home/linuxize/images/ user@12.12.12.12:/var/www/images/

If SSH on the remote host is listening on a port other than the default 22, specify the port using the -e option. For example, if SSH is listening on port 3322 you would use:

Terminal
rsync -a -e "ssh -p 3322" /home/linuxize/images/ user@12.12.12.12:/var/www/images/

When transferring large amounts of data it is recommended to run the rsync command inside a screen session or use the -P option which tells rsync to show a progress bar during the transfer and keep the partially transferred files:

Terminal
rsync -a -P /home/linuxize/images/ user@12.12.12.12:/var/www/images/

To reduce bandwidth usage on slow connections, add the -z flag to enable compression during the transfer:

Terminal
rsync -a -z /home/linuxize/images/ user@12.12.12.12:/var/www/images/

Before running a destructive operation such as --delete, use the -n (or --dry-run) flag to preview exactly what rsync would transfer or remove without making any changes:

Terminal
rsync -a -n --delete /home/linuxize/images/ user@12.12.12.12:/var/www/images/

To exclude files or directories from the transfer, use the --exclude option.

Troubleshooting

rsync: command not found rsync is not installed on the local or remote system. Install it on both machines; see the Requirements section above.

Permission denied (publickey) The SSH key is missing or not authorized on the remote host. Set up passwordless SSH login or pass the password interactively.

ssh: connect to host port 22: Connection refused SSH is running on a non-default port. Use -e "ssh -p PORT" to specify the correct port.

Files are not syncing as expected Check the trailing slash on the source path. rsync -a /src/ dest/ copies the contents of src; rsync -a /src dest/ copies the src directory itself into dest.

Transfer is slow over a high-latency connection Add -z to enable compression. For large files this can significantly reduce transfer time.

FAQ

What does the -a flag do? Archive mode (-a) is equivalent to -rlptgoD. It syncs recursively and preserves symbolic links, permissions, timestamps, group, owner, and device files, making it the most common choice for backups and migrations.

How do I preview what rsync will do before transferring? Add -n or --dry-run to your command. rsync will print every file it would transfer or delete without making any actual changes. Combine it with -v for verbose output.

What is the difference between rsync and scp? scp always copies the full file. rsync compares source and destination and transfers only the differences, which makes repeat transfers of large directories much faster.

Can I use rsync with an SSH config file? Yes. If you have a host alias defined in ~/.ssh/config, you can use it directly (for example, rsync -a /src/ myserver:/dest/) and rsync will pick up the port, key, and username from the config entry.

Conclusion

We have shown you how to use rsync over SSH to copy and synchronize files and directories. Use -n to preview any operation before running it, and -z to speed up transfers over slow connections.

SSH Hardening Guide: Best Practices for Linux Servers

hello@linuxize.com (Linuxize) — Sun, 01 Feb 2026 11:40:00 +0100

SSH makes remote Linux server administration easy, but defaults are not always safe. A poorly configured SSH server can be an easy target for brute-force attacks, exposed accounts, and unauthorized access.

This guide covers practical SSH hardening best practices for Linux servers. We will adjust sshd_config, test the configuration before restarting the service, and add protections that reduce the attack surface without making the server hard to manage.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Setting	Value	Purpose
`PasswordAuthentication`	`no`	Force key-based authentication
`KbdInteractiveAuthentication`	`no`	Disable keyboard-interactive password prompts
`PermitRootLogin`	`no`	Disable root SSH login
`AllowUsers`	`deploy admin`	Restrict SSH access to listed users
`PermitEmptyPasswords`	`no`	Block empty passwords
`LoginGraceTime`	`30`	Shorten the authentication window
`MaxAuthTries`	`3`	Limit failed login attempts
`X11Forwarding`	`no`	Disable X11 forwarding
`AllowAgentForwarding`	`no`	Disable agent forwarding
`AllowTcpForwarding`	`no`	Disable SSH tunnels for users who do not need them
`ClientAliveInterval`	`300`	Set idle timeout interval
`ClientAliveCountMax`	`2`	Disconnect after 2 missed keep-alives

Prerequisites

A server running Linux with SSH access
Root or sudo privileges
A working SSH key pair (see how to generate SSH keys )

All SSH server settings are configured in /etc/ssh/sshd_config. Some distributions also load files from /etc/ssh/sshd_config.d/, which is useful when you want to keep local changes separate from package defaults.

Warning

Before applying any of these changes, keep your current SSH session open and make sure you have an alternative way to access your server, such as a console connection, in case you lock yourself out.

Before editing the SSH configuration, create a backup:

Terminal
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

After each change, test the configuration before restarting SSH:

Terminal
sudo sshd -t

If the command prints no output, the configuration syntax is valid. Then restart the SSH service:

Terminal
sudo systemctl restart ssh

On some distributions the service is named sshd:

Terminal
sudo systemctl restart sshd

Use Key-Based Authentication

Password authentication is vulnerable to brute-force attacks. Key-based authentication is more secure because it requires possession of the private key.

First, make sure you have copied your SSH key to the server and can log in without a password.

Then disable password authentication in /etc/ssh/sshd_config:

/etc/ssh/sshd_configini
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

This forces users to authenticate with SSH keys and disables keyboard-interactive password prompts. Keep password authentication enabled until you have confirmed that your key login works from a new terminal session.

Allowing direct root login over SSH is a security risk. Attackers commonly target the root account in brute-force attacks.

Disable root login in /etc/ssh/sshd_config:

/etc/ssh/sshd_configini
PermitRootLogin no

If you need root access, log in as a regular user and use sudo or su .

If you still need root login with keys only, use:

/etc/ssh/sshd_configini
PermitRootLogin prohibit-password

This allows root login only with SSH keys, not passwords.

Restrict SSH by Firewall

If only a few IP addresses need SSH access, restrict the SSH port at the firewall. This is usually stronger than only changing the SSH port because unwanted hosts cannot reach the daemon at all.

With UFW, allow SSH from a trusted IP address:

Terminal
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

If you manage the server from more than one location, add each trusted IP address before removing broader SSH rules. Do not close the current SSH port until you have tested a new connection.

Change the Default Port

The default SSH port is 22. Changing it does not provide real security, but it reduces noise from automated bots that scan port 22.

Change the port in /etc/ssh/sshd_config:

/etc/ssh/sshd_configini
Port 2222

Make sure to open the new port in your firewall before restarting SSH:

Terminal
sudo ufw allow 2222/tcp

For more details, see our guide on how to change the SSH port .

Limit User Access

By default, all system users can log in via SSH. You can restrict access to specific users with the AllowUsers directive:

/etc/ssh/sshd_configini
AllowUsers deploy admin

Only the listed users will be able to connect. All others will be denied.

To restrict access by group instead:

/etc/ssh/sshd_configini
AllowGroups sshusers

Disable Empty Passwords

Make sure accounts with empty passwords cannot log in via SSH:

/etc/ssh/sshd_configini
PermitEmptyPasswords no

The LoginGraceTime setting controls how long the server waits for a user to authenticate before disconnecting. The default is 120 seconds, which is too long:

/etc/ssh/sshd_configini
LoginGraceTime 30

Limit Authentication Attempts

Reduce the number of authentication attempts per connection to slow down brute-force attacks:

/etc/ssh/sshd_configini
MaxAuthTries 3

Disable X11 Forwarding

If you do not need to forward graphical applications over SSH, disable X11 forwarding:

/etc/ssh/sshd_configini
X11Forwarding no

OpenSSH disables X11 forwarding by default on many systems, but setting it explicitly keeps the intended policy clear.

Disable Agent Forwarding

Agent forwarding lets a remote server use your local SSH agent for onward connections. Disable it unless users need to connect from this server to other hosts with forwarded credentials:

/etc/ssh/sshd_configini
AllowAgentForwarding no

Disable TCP Forwarding

If your users do not need to create SSH tunnels, disable TCP forwarding:

/etc/ssh/sshd_configini
AllowTcpForwarding no

This blocks SSH port forwarding requests. It does not stop users with shell access from running their own forwarding tools, but it removes the built-in SSH tunneling path.

Use Strong Key Types

When generating SSH keys, use Ed25519 or RSA with at least 4096 bits. Ed25519 is the recommended choice for new keys:

Terminal
ssh-keygen -t ed25519

For RSA:

Terminal
ssh-keygen -t rsa -b 4096

Older key types like DSA and ECDSA with small key sizes should be avoided.

Set Idle Timeout

Disconnect idle SSH sessions after a period of inactivity. This prevents abandoned sessions from remaining open:

/etc/ssh/sshd_configini
ClientAliveInterval 300
ClientAliveCountMax 2

This sends a keep-alive message every 300 seconds (5 minutes) and disconnects after 2 missed responses, giving a total timeout of 10 minutes.

Set Up Fail2Ban

Fail2Ban monitors authentication logs and bans IP addresses that show malicious activity, such as repeated failed login attempts. It is most useful on public SSH servers that still receive frequent connection attempts.

Install Fail2Ban:

Terminal
sudo apt install fail2ban

Create a jail override file:

Terminal
sudo nano /etc/fail2ban/jail.d/sshd.local

Add the SSH jail configuration:

/etc/fail2ban/jail.d/sshd.localini
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
bantime = 3600
findtime = 600

This configuration bans an IP address for 1 hour after 3 failed login attempts within 10 minutes. The default sshd jail usually knows where your distribution writes SSH authentication logs, so you do not need to set logpath unless your server uses a custom logging setup.

If you changed SSH to a custom port, set port to that value in the jail file:

/etc/fail2ban/jail.d/sshd.localini
port = 2222

Start and enable Fail2Ban:

Terminal
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

To check the status of the SSH jail:

Terminal
sudo fail2ban-client status sshd

You can display a legal warning banner before authentication. Create a banner file:

Terminal
sudo nano /etc/ssh/banner

Add your warning text:

/etc/ssh/bannertext
Authorized access only. All activity is monitored and logged.

Then enable it in /etc/ssh/sshd_config:

/etc/ssh/sshd_configini
Banner /etc/ssh/banner

Troubleshooting

SSH does not restart after editing sshd_config
Run sudo sshd -t to find syntax errors. If you need to revert quickly, restore the backup with sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config, then test the configuration again before restarting SSH.

Password login still works after setting PasswordAuthentication no
Check whether KbdInteractiveAuthentication is still enabled. On PAM-based systems, keyboard-interactive authentication can still ask for a password, so set both PasswordAuthentication no and KbdInteractiveAuthentication no.

The service name is different on your system
Ubuntu and Debian commonly use ssh.service, while RHEL, Fedora, and many other distributions use sshd.service. Check the active unit with systemctl status ssh or systemctl status sshd.

You changed the port but cannot connect
Make sure the firewall allows the new port before restarting SSH. If you use Ubuntu socket activation, ssh.socket may still listen on port 22 unless the socket configuration is updated.

Fail2Ban does not show bans for SSH
Check the jail status with sudo fail2ban-client status sshd. If the jail is active but no failures are detected, review your authentication logs with sudo journalctl -u ssh or sudo journalctl -u sshd and confirm that Fail2Ban is using the correct backend for your distribution.

FAQ

Should I change the SSH port?
Changing the port reduces automated scanning noise but does not provide real security. It is useful as part of a defense-in-depth strategy, not as a standalone measure.

Can I lock myself out by disabling password authentication?
Yes. Before disabling password authentication, make sure you can log in with your SSH key. Keep a console connection available as a backup.

Is Fail2Ban necessary if I use key-only authentication?
It is not strictly necessary, but it still helps. Fail2Ban reduces log noise and blocks IPs that repeatedly attempt to connect, even if they cannot authenticate.

What is the most important hardening step?
Disabling password authentication and using key-based authentication. This eliminates the most common attack vector: brute-force password guessing.

How do I check my current SSH configuration?
Run sudo sshd -T to display the effective SSH server configuration, including all defaults and overrides.

Conclusion

SSH hardening starts with safe configuration changes: key-based authentication, no direct root login, limited users, firewall restrictions, timeouts, and tested sshd_config edits. Apply the settings that fit your server, and always test a new SSH session before closing the old one.

SSH Permission Denied (publickey): Causes and Fixes

hello@linuxize.com (Linuxize) — Mon, 02 Feb 2026 10:30:00 +0100

The “Permission denied (publickey)” error occurs when the SSH server rejects your connection because it cannot verify your identity using public key authentication.

output

user@remote_host: Permission denied (publickey).

This is one of the most common SSH errors. Seeing it is actually a good sign for the network path, because the server answered and reached the authentication stage; a connection that stops earlier with connection refused is a different problem. In this guide, we will go through the most frequent causes and how to fix them.

Debugging the Connection

Before trying specific fixes, run SSH in verbose mode to see exactly where the authentication fails:

Terminal
ssh -v user@remote_host

For even more detail, use -vv or -vvv:

Terminal
ssh -vvv user@remote_host

Look for lines like:

output

debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Server accepts key: /home/user/.ssh/id_ed25519

or:

output

debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: No more authentication methods to try.

The verbose output tells you which keys are being tried and where the process fails.

Common Causes and Fixes

1. Public Key Not on the Remote Server

The most common cause is that your public key is not in the remote server’s ~/.ssh/authorized_keys file.

Copy your public key to the server:

Terminal
ssh-copy-id user@remote_host

If ssh-copy-id is not available, copy it manually:

Terminal
cat ~/.ssh/id_ed25519.pub | ssh user@remote_host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

For more details, see our guide on how to copy SSH keys with ssh-copy-id .

2. Wrong File Permissions

SSH is strict about file permissions. If the permissions are too open, the SSH server will reject the key.

On the remote server, set the correct permissions:

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

On the local machine, set the correct permissions on your private key:

Terminal
chmod 600 ~/.ssh/id_ed25519

The SSH server will also reject keys if the home directory is writable by others:

Terminal
chmod 755 ~

These checks are enforced by the StrictModes yes setting in /etc/ssh/sshd_config, which is enabled by default. Do not disable it; fix the permissions instead.

3. Wrong User or Hostname

Make sure you are connecting as the correct user. The key must be in that user’s authorized_keys file:

Terminal
ssh deploy@remote_host

If you have a host alias in your SSH config file , verify it points to the correct hostname and user.

4. SSH Agent Not Running

If your key is protected with a passphrase and the SSH agent is not running, the key will not be offered to the server.

Start the SSH agent and add your key:

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

To list the keys currently loaded in the agent:

Terminal
ssh-add -l

5. Wrong Key Being Used

If you have multiple SSH keys, the client may be offering the wrong one. Specify the key explicitly:

Terminal
ssh -i ~/.ssh/id_ed25519 user@remote_host

Or configure it in your ~/.ssh/config:

~/.ssh/configtxt
Host remote_host
 HostName 192.168.1.10
 User deploy
 IdentityFile ~/.ssh/id_ed25519

6. Public Key Authentication Disabled on the Server

If public key authentication is disabled on the server, key-based login will not work regardless of your key setup. Check /etc/ssh/sshd_config on the server:

/etc/ssh/sshd_configtxt
PasswordAuthentication no
PubkeyAuthentication yes

If PubkeyAuthentication is set to no, key-based login will not work. Change it to yes and restart SSH:

Terminal
sudo systemctl restart sshd

7. Key Type Not Accepted

Some servers are configured to accept only certain key types. If your key type is not allowed, the server will reject it.

Check the PubkeyAcceptedAlgorithms setting in /etc/ssh/sshd_config:

/etc/ssh/sshd_configtxt
PubkeyAcceptedAlgorithms +ssh-rsa

If you are using an older RSA key, the server may require you to explicitly allow it. This should be a last resort because ssh-rsa is deprecated on modern OpenSSH. A better solution is to generate a new Ed25519 key:

Terminal
ssh-keygen -t ed25519

8. SELinux Blocking Access

On systems with SELinux enabled (Fedora, RHEL, and derivatives), SELinux may prevent the SSH server from reading the authorized_keys file.

Check for SELinux denials:

Terminal
sudo ausearch -m avc -ts recent

Restore the correct SELinux context:

Terminal
sudo restorecon -R ~/.ssh

9. Home Directory on Network Storage

If the user’s home directory is on NFS or another network filesystem, the SSH server may not be able to read the authorized_keys file before the filesystem is mounted.

You can configure an alternative location for authorized keys in /etc/ssh/sshd_config:

/etc/ssh/sshd_configtxt
AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Then place the user’s keys in /etc/ssh/authorized_keys/username.

Server-Side Debugging

If you have access to the server, check the authentication log for the exact reason SSH rejected the connection.

On Ubuntu and Debian:

Terminal
sudo tail -f /var/log/auth.log

On Fedora, RHEL, and derivatives:

Terminal
sudo tail -f /var/log/secure

The log entries usually show whether the issue is permissions, a missing key, or a configuration mismatch on the server side.

For the most detailed output, run the SSH server in debug mode temporarily on a different port:

Terminal
sudo /usr/sbin/sshd -d -p 2222

Then connect to it from the client:

Terminal
ssh -p 2222 user@remote_host

The server will print every step of the authentication exchange to the terminal, which makes it easy to see exactly where the login fails.

Quick Reference

Problem	Fix
Key not on server	`ssh-copy-id user@host`
Wrong permissions on `~/.ssh`	`chmod 700 ~/.ssh`
Wrong permissions on `authorized_keys`	`chmod 600 ~/.ssh/authorized_keys`
Wrong permissions on private key	`chmod 600 ~/.ssh/id_ed25519`
SSH agent not running	`eval "$(ssh-agent -s)" && ssh-add`
Wrong key offered	`ssh -i ~/.ssh/key user@host`
SELinux blocking access	`sudo restorecon -R ~/.ssh`
Check auth log (Ubuntu)	`sudo tail -f /var/log/auth.log`
Debug SSH connection	`ssh -vvv user@host`

FAQ

Why does SSH care about file permissions?
SSH refuses to use keys with overly permissive file permissions because other users on the system could read your private key or modify your authorized_keys file. This is a security feature, not a bug.

I copied my key but it still does not work. What should I check?
Check the permissions on the remote ~/.ssh directory (700), the authorized_keys file (600), and the home directory (755 or stricter). Also verify you are connecting as the correct user.

How do I check which keys the SSH client is trying?
Run ssh -v user@host and look for lines starting with debug1: Offering public key or debug1: Trying private key. This shows which keys are being offered to the server.

Does this error always mean a key problem?
Not always. If the server has PasswordAuthentication no and PubkeyAuthentication no, all authentication methods are disabled and you will see this error regardless.

Can I temporarily enable password login to fix the key?
Yes. If you have console access, set PasswordAuthentication yes in /etc/ssh/sshd_config, restart SSH, copy your key with ssh-copy-id, then disable password authentication again.

I get this error on an AWS, GCP, or Azure instance. What should I check?
Cloud instances use a specific key pair set during provisioning. Make sure you are using that key: ssh -i ~/.ssh/my-cloud-key.pem user@host. The default username also varies by provider (e.g., ec2-user on Amazon Linux, ubuntu on Ubuntu instances, azureuser on Azure). Check your provider’s documentation for the correct username.

Conclusion

Before disabling password authentication or closing your current session, open a second terminal and confirm that key-based login works end-to-end. Otherwise, a small mistake in sshd_config or in the authorized_keys file can lock you out of the server.

SSH Connection Refused: Causes and Fixes

hello@linuxize.com (Linuxize) — Thu, 23 Jul 2026 14:20:00 +0200

You try to log in and SSH stops immediately with connect to host example.com port 22: Connection refused. The failure happens before SSH checks your key or password, so changing authentication settings will not fix it.

An immediate refusal means the target address has no process listening on that port, or a firewall or network device actively rejected the request. The usual causes are a stopped SSH server, the wrong host or port, a listener bound to another address, a firewall reject rule, or port forwarding to the wrong machine. A connection that hangs and then times out is different because no response came back.

This guide starts with checks you can run from the client, then moves to the SSH service, listening port, firewall, and network path on the server.

Quick Reference

For a printable quick reference, see the SSH cheatsheet .

Check	Command
Confirm the destination address	`getent ahosts example.com`
Show SSH connection details	`ssh -vvv user@example.com`
Test the default SSH port	`nc -vz example.com 22`
Check for a listener on port 22	`sudo ss -ltnp 'sport = :22'`
Show the effective SSH port and addresses	`sudo sshd -T \| grep -E '^(port\|listenaddress) '`
Check SSH on Ubuntu or Debian	`sudo systemctl status ssh.service ssh.socket`
Check SSH on Fedora or RHEL	`sudo systemctl status sshd`
Check UFW rules	`sudo ufw status numbered`
Check firewalld services	`sudo firewall-cmd --list-services`

Confirm the Host and Port from the Client

Before changing the server, confirm that the hostname resolves to the address you expect:

Terminal
getent ahosts example.com

If the result points to an old server or the wrong public address, correct the DNS record or connect to the intended IP address directly. Reaching the wrong host can produce a refusal even when SSH is working on the real server.

Next, run SSH with verbose output:

Terminal
ssh -vvv user@example.com

The relevant lines look like this:

output

debug1: Connecting to example.com [203.0.113.10] port 22.
ssh: connect to host example.com port 22: Connection refused

The client resolved example.com to 203.0.113.10 and received an immediate refusal from port 22. You can test the TCP port without starting an SSH login:

Terminal
nc -vz example.com 22

If the server uses a custom port, test and connect to that port instead:

Terminal
nc -vz example.com 2222
ssh -p 2222 user@example.com

A hostname can also have separate IPv4 and IPv6 addresses. Test each address family when one DNS record may point to the wrong server:

Terminal
ssh -4 user@example.com
ssh -6 user@example.com

The remaining checks require access to the server through a cloud console, virtual machine console, physical terminal, or another management channel.

Check Whether SSH Is Listening

The listening socket is the quickest way to tell whether the server can accept SSH connections on port 22. Run this command on the server:

Terminal
sudo ss -ltnp 'sport = :22'

A working listener appears as either sshd or systemd, depending on whether the distribution runs the daemon continuously or uses socket activation. If the command returns nothing, no process is accepting connections on port 22.

To see the port and addresses from the effective OpenSSH configuration, run:

Terminal
sudo sshd -T | grep -E '^(port|listenaddress) '

Typical output looks like this:

output

port 22
listenaddress [::]:22
listenaddress 0.0.0.0:22

The output shows that SSH is configured for port 22 on all IPv6 and IPv4 addresses. If it reports another port, connect with the -p option and verify that the firewall allows that port. See our guide on changing the SSH port if you need to correct the configuration.

Check the SSH Service or Socket

Linux distributions use different systemd unit names for OpenSSH. Ubuntu and Debian use ssh.service, while Fedora, RHEL, and their derivatives use sshd.service.

On Ubuntu and Debian, check the service:

Terminal
sudo systemctl status ssh.service

Ubuntu 22.10 and later use ssh.socket by default, so check that unit as well:

Terminal
sudo systemctl status ssh.socket

When ssh.socket is active and owns port 22, ssh.service may remain inactive until a client connects. In that setup, an inactive service alone does not indicate a problem. If the socket is disabled or stopped, enable it and start it:

Terminal
sudo systemctl enable --now ssh.socket

On systems without ssh.socket, enable and start the service instead:

Terminal
sudo systemctl enable --now ssh

On Fedora, RHEL, and derivatives, check and start sshd:

Terminal
sudo systemctl status sshd
sudo systemctl enable --now sshd

If the unit reports failed, validate the SSH server configuration:

Terminal
sudo sshd -t

No output means the configuration passed the test. If OpenSSH prints an error, correct the reported line before restarting the unit. You can also inspect the current boot logs on Ubuntu and Debian:

Terminal
sudo journalctl -u ssh.service -u ssh.socket -b

For Fedora and RHEL, use the sshd unit name:

Terminal
sudo journalctl -u sshd -b

Install the OpenSSH Server

Some minimal installations include the SSH client but not the server. If systemctl reports that the SSH unit does not exist, install the openssh-server package.

Ubuntu, Debian, and Derivatives

Update the package index and install the server package:

Terminal
sudo apt update
sudo apt install openssh-server

The package normally starts the appropriate SSH service or socket during installation. Check port 22 again with ss instead of assuming that the listener started successfully.

Fedora, RHEL, and Derivatives

Install the server package, then enable and start sshd:

Terminal
sudo dnf install openssh-server
sudo systemctl enable --now sshd

Check the Listening Address

SSH can run normally but listen only on the loopback interface or one private address. In that case, a local connection works while connections to other server addresses are refused.

Review the listenaddress lines from sshd -T. A value such as 127.0.0.1:22 accepts only local IPv4 connections. OpenSSH reads its main configuration from /etc/ssh/sshd_config and may also read files under /etc/ssh/sshd_config.d/. A listener on a loopback address is reachable from the server itself and from nowhere else.

Before changing Port or ListenAddress, keep console access open and validate the new configuration with sudo sshd -t. On Ubuntu systems using socket activation, the socket must also reload the generated listening configuration. The port-change guide linked above covers the service and socket steps in order.

Check the Firewall

A firewall is less likely to cause an immediate refusal than a missing listener. Rules that silently drop traffic usually end with Connection timed out, while an explicit REJECT rule can return Connection refused. Check the firewall after confirming the service and port.

If the server uses UFW, list its rules with numbers:

Terminal
sudo ufw status numbered

Allow the standard OpenSSH profile when SSH uses port 22:

Terminal
sudo ufw allow OpenSSH

For a custom port, allow the exact TCP port instead:

Terminal
sudo ufw allow 2222/tcp

On a server using firewalld, first check the services allowed in the active zone:

Terminal
sudo firewall-cmd --list-services

Add SSH to both the runtime and permanent configurations if it is missing:

Terminal
sudo firewall-cmd --add-service=ssh
sudo firewall-cmd --permanent --add-service=ssh

For a custom port, use --add-port=2222/tcp in both commands. Our UFW firewall guide explains how to review and manage rules in more detail.

Check Port Forwarding and External Firewalls

If SSH works from the same machine or local network but fails from the internet, the OpenSSH listener may already be correct. Check that the router or virtualization platform forwards the external port to the server’s current private address and SSH port.

The same issue can occur with a virtual machine, container, load balancer, or cloud firewall. Confirm that public DNS points to the expected system and that each forwarding rule uses the same port you pass to ssh. Cloud firewall rules often drop traffic and cause a timeout, but an edge device that rejects the request or forwards it to the wrong host can produce a refusal.

Troubleshooting

Connection refused started after an SSH configuration change
Run sudo sshd -t and correct every reported error. On Ubuntu with socket activation, reload systemd and restart ssh.socket after a valid Port or ListenAddress change, then verify the listener with ss before closing console access.

SSH works with localhost but not the server address
Check the effective ListenAddress values and the firewall rules for the external interface. A listener restricted to 127.0.0.1 or ::1 cannot accept remote connections.

IPv4 works but IPv6 is refused
The server may have an AAAA record without an IPv6 listener. Compare ssh -4 and ssh -6, then correct the DNS record or configure SSH to listen on the intended IPv6 address.

Only one client address is refused
A source-specific firewall rule or a tool such as Fail2ban may be rejecting that address. Review the firewall rules and, if Fail2ban is installed, check the SSH jail with sudo fail2ban-client status sshd.

SSH reaches the server but reports Permission denied
The network path and listener are working, and the failure has moved to authentication. Follow the SSH Permission denied (publickey) guide instead.

Conclusion

Once the port test succeeds, SSH should move on to host-key verification or authentication. Before exposing the restored service to the internet, review our SSH hardening best practices and restrict firewall access where possible.

SSH Essentials on Linuxize

ssh Command in Linux: Connect to Remote Servers

Installing OpenSSH Client #

Install OpenSSH on Ubuntu, Debian, and Derivatives #

Install OpenSSH on Fedora, RHEL, and Derivatives #

Install OpenSSH on Windows 10 and 11 #

Install OpenSSH on macOS #

ssh Command Syntax #

Connecting to a Remote Server #

Running Remote Commands #

ssh Command Options #

Passing Configuration Options with -o #

Connecting Through a Jump Host with -J #

Forwarding X11 with -X #

SSH Config File #

Public Key Authentication #

Port Forwarding #

Local Port Forwarding #

Remote Port Forwarding #

Dynamic Port Forwarding #

Troubleshooting #

Quick Reference #

FAQ #

Conclusion #

How to Enable SSH on Ubuntu 18.04

Prerequisites #

Enabling SSH on Ubuntu #

Connecting to SSH Over LAN #

Connecting to SSH Over Internet #

Disabling SSH on Ubuntu #

Conclusion #

How to Enable SSH on Ubuntu

Quick Reference #

Enabling SSH on Ubuntu #

Connecting to the SSH Server #

Connecting to SSH behind NAT #

Disabling SSH on Ubuntu #

Troubleshooting #

FAQ #

Conclusion #

How to Enable SSH on Raspberry Pi

Enabling SSH During OS Installation #

Enabling SSH on a Pre-Imaged SD Card (Headless) #

Enabling SSH With a Monitor Attached #

From the Raspberry Pi Configuration Tool #

From raspi-config in the Terminal #

Connecting to Raspberry Pi via SSH #

Troubleshooting #

Conclusion #

Using the SSH Config File

SSH Config File Location #

SSH Config File Structure and Patterns #

Basic Example #

Advanced Example: Patterns and Precedence #

Overriding Options #

Common SSH Config Options #

Quick Reference #

Troubleshooting #

FAQ #

Conclusion #

How to Change the SSH Port in Linux

Quick Reference #

Changing the SSH Port #

1. Choosing a New Port Number #

2. Adjusting Firewall #

3. Configuring SSH #

Using the New SSH Port #

Troubleshooting #

Conclusion #

The ~/.ssh Folder: Files, Permissions, and Layout

Quick Reference #

Where the Folder Lives #

Private and Public Keys #

authorized_keys #

known_hosts #

config #

Reset SSH Permissions #

Client vs Server Layout #

Troubleshooting #

FAQ #

Installing OpenSSH Client

Install OpenSSH on Ubuntu, Debian, and Derivatives

Install OpenSSH on Fedora, RHEL, and Derivatives

Install OpenSSH on Windows 10 and 11

Install OpenSSH on macOS

ssh Command Syntax

Connecting to a Remote Server

Running Remote Commands

ssh Command Options

Passing Configuration Options with -o

Connecting Through a Jump Host with -J

Forwarding X11 with -X

SSH Config File

Public Key Authentication

Port Forwarding

Local Port Forwarding

Remote Port Forwarding

Dynamic Port Forwarding

Troubleshooting

Quick Reference

FAQ

Conclusion

Prerequisites

Enabling SSH on Ubuntu

Connecting to SSH Over LAN

Connecting to SSH Over Internet

Disabling SSH on Ubuntu

Conclusion

Quick Reference

Enabling SSH on Ubuntu

Connecting to the SSH Server

Connecting to SSH behind NAT

Disabling SSH on Ubuntu

Troubleshooting

FAQ

Conclusion

Enabling SSH During OS Installation

Enabling SSH on a Pre-Imaged SD Card (Headless)

Enabling SSH With a Monitor Attached

From the Raspberry Pi Configuration Tool

From raspi-config in the Terminal

Connecting to Raspberry Pi via SSH

Troubleshooting

Conclusion

SSH Config File Location

SSH Config File Structure and Patterns

Basic Example

Advanced Example: Patterns and Precedence

Overriding Options

Common SSH Config Options

Quick Reference

Troubleshooting

FAQ

Conclusion

Quick Reference

Changing the SSH Port

1. Choosing a New Port Number

2. Adjusting Firewall

3. Configuring SSH

Using the New SSH Port

Troubleshooting

Conclusion

Quick Reference

Where the Folder Lives

Private and Public Keys

authorized_keys

known_hosts

config

Reset SSH Permissions

Client vs Server Layout

Troubleshooting

FAQ

Conclusion

Quick Reference

Prerequisites

Check for Existing SSH Keys

Generate an SSH Key Pair

Generate an Ed25519 Key (Recommended)

Generate an RSA Key

Key Generation Process