SSH Essentials on Linuxize

ssh Command in Linux: Connect to Remote Servers

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

Secure Shell (SSH) is a cryptographic network protocol used for an encrypted connection between a client and a server. The ssh client creates a secure connection to the SSH server on a remote machine. The encrypted connection can be used to 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. Type yes to store the remote 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 'sudo apt update && sudo apt upgrade -y'

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 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 — it is faster and more secure 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:

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. Key-based authentication simplifies the login process and significantly improves server security.

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.

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.

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 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 is faster, produces shorter keys, and is considered more secure than RSA. Use RSA only if you need to connect to a legacy system that does 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 for security, the SSH config file to manage multiple hosts, and the -v flag when troubleshooting connection issues.

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

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, and 24.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`
Start SSH	`sudo systemctl start ssh`
Stop SSH	`sudo systemctl stop ssh`
Enable SSH on boot	`sudo systemctl enable ssh`
Disable SSH	`sudo systemctl disable --now ssh`
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 the installation is complete, the SSH service starts automatically. Verify that SSH is running:
Terminal
```
sudo systemctl status ssh
```
The output should tell you that the service is 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 Mon 2025-06-01 12:34:00 CEST; 9h ago
...
```
Press q to exit the status screen and get back to the command line prompt.
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.
ECDSA key fingerprint is SHA256:Vybt22mVXuNuB5unE++yowF7lgA/9/2bLSiO3qmYWBY.
Are you sure you want to continue connecting (yes/no)?

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

output

Warning: Permanently added '10.0.2.15' (ECDSA) 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’re 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 your Ubuntu system, stop the SSH service by running:

Terminal
sudo systemctl disable --now ssh

Later, to re-enable it, type:

Terminal
sudo systemctl enable --now ssh

Troubleshooting

SSH service fails to start
Run sudo journalctl -u ssh 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.

Connection refused on port 22
Confirm the SSH service is running with sudo systemctl status ssh. 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.

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 22.04 and 24.04?
Yes. The openssh-server package and systemctl commands are the same across Ubuntu 20.04, 22.04, and 24.04.

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.

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, copy them to remote servers, and set up passwordless SSH login.

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)
Access to a remote server you want to connect to

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)

Copy the Public Key to the Remote Server

To use SSH key authentication, you need to copy your public key to the remote server.

Using ssh-copy-id (Recommended)

The easiest way is to use the ssh-copy-id command:

Terminal
ssh-copy-id username@server_ip

You’ll be prompted for the remote user’s password:

output

username@server_ip's password:

After entering the password, your public key will be added to the remote server’s ~/.ssh/authorized_keys file:

output

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

Manual Method

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

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

This command:

Reads your public key
Connects to the remote server
Creates the .ssh directory if it doesn’t exist
Appends the key to the authorized_keys file
Sets the correct permissions

Test SSH Key Authentication

After copying your public key, check the connection:

Terminal
ssh username@server_ip

If everything is set up correctly, you’ll be logged in without being prompted for a password. If you set a passphrase for your key, you’ll be asked to enter it.

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

Disable Password Authentication (Optional)

For better security, you can disable password authentication on your server after setting up SSH keys.

Warning

Before disabling password authentication, make sure you can log in with your SSH key. Otherwise, you may lock yourself out of the server.

Connect to your server and edit the SSH configuration file:

Terminal
sudo nano /etc/ssh/sshd_config

Find and modify the following settings:

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

Save the file and restart the SSH service:

Terminal
# Debian/Ubuntu
sudo systemctl restart ssh

# CentOS/RHEL/Fedora
sudo systemctl restart sshd

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

You’ve learned how to create SSH keys on Linux, copy them to remote servers, and set up passwordless login. SSH keys are safer than passwords and make connecting to remote servers easier.

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

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 ~/.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"

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:

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

Terminal
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

Open the SSH configuration file /etc/ssh/sshd_config and set the following directives:

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

Info

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

Once you are done, save the file and restart the SSH service.

On Ubuntu or Debian servers:

Terminal
sudo systemctl restart ssh

On CentOS or Fedora servers:

Terminal
sudo systemctl restart sshd

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.

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.

What to check if key login does not work?
Verify the permissions: ~/.ssh should be 700, your private key 600, and authorized_keys 600. Also confirm PubkeyAuthentication is enabled on the server and you are using the correct user and key.

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 greater than 1024 as a LOCAL_PORT. Port numbers less than 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.

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.

If you are having trouble setting up tunneling, check your remote SSH server configuration and make sure AllowTcpForwarding is not set to no. By default, forwarding is allowed.

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.

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.

Now your fellow developer can type the_ssh_server_ip:8080 in their browser and preview your application.

If you are having trouble setting up remote port forwarding, make sure GatewayPorts is set to yes in the remote SSH server configuration.

To bind the remote forwarding port on all interfaces, specify an explicit bind address, for example:

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

Binding to 0.0.0.0 makes the forwarded port accessible from outside the SSH server, so use it only when necessary.

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:

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

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>. Alternatively, use -o ExitOnForwardFailure=yes and -o ServerAliveInterval=60 to make tunnels self-managing.

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 such as resumable transfers, incremental backups, or syncing large directory trees, consider using rsync or sftp instead.

How to Use SFTP Command to Transfer Files

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 directories when the command-line destination includes a path.
-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

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 downloaded to the directory from which you typed the sftp command.

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

If the file you want to upload is not located in your current working directory, use the absolute path to the file.

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

You can use wildcard patterns to transfer multiple files at once with the mget and mput commands.

To download multiple files matching a pattern:

Terminal
mget *.txt

To upload multiple files:

Terminal
mput *.log

You do not need a separate prompt off command for mget or mput in OpenSSH SFTP. Wildcard transfers run for all matching files:

Terminal
mget *.csv

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.

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
```

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 file	`get filename`
Download directory	`get -r directory`
Resume download	`reget filename`
Resume directory download	`reget -r directory`
Upload file	`put filename`
Upload directory	`put -r directory`
Resume upload	`reput filename`
Resume directory upload	`reput -r directory`
Download multiple files	`mget *.txt`
Upload multiple files	`mput *.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 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.

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

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 .

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. It also sets the correct permissions on the remote .ssh directory and authorized_keys 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

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

Terminal
ssh user@remote_host

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

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

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 appends your public key to the ~/.ssh/authorized_keys file on the remote server and sets the correct file permissions. This enables key-based authentication.

Can I use ssh-copy-id on macOS?
Yes. ssh-copy-id is available through Homebrew: brew install ssh-copy-id. It is not included in macOS by default.

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?
It sets 700 on the ~/.ssh directory and 600 on the authorized_keys file. These permissions are required by the SSH server for security.

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 copies your public key to a remote server and sets the correct permissions automatically.

After installing the key, test the SSH login in a new terminal before changing server authentication settings or closing your current session.

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

How to Generate SSH Keys on Linux with ssh-keygen

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 #

Copy the Public Key to the Remote Server #

Using ssh-copy-id (Recommended) #

Manual Method #

Test SSH Key Authentication #

Using the SSH Agent #

Managing SSH Keys #

View Your Public Key #

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

Prerequisites

Check for Existing SSH Keys

Generate an SSH Key Pair

Generate an Ed25519 Key (Recommended)

Generate an RSA Key

Key Generation Process

Copy the Public Key to the Remote Server

Using ssh-copy-id (Recommended)

Manual Method

Test SSH Key Authentication

Using the SSH Agent

Managing SSH Keys

View Your Public Key

List All Keys

Remove a Key from the Agent

Delete a Key Pair

Disable Password Authentication (Optional)

Troubleshooting

Permission Denied (publickey)

SSH Agent Not Running

Wrong Key Being Used