How to Install SSH on Linux Server (Complete Step-by-Step Guide 2026)

To install SSH on a Linux server, install the OpenSSH server package, start and enable the sshd service, and allow TCP port 22 in your firewall and cloud security group. On Ubuntu/Debian: apt install openssh-server; on RHEL/CentOS/AlmaLinux: dnf install openssh-server; then systemctl enable –now sshd and test with ssh user@server-ip.

Secure Shell (SSH) is the standard way to manage Linux servers remotely and safely. In this guide, you’ll learn how to install SSH on a Linux server, open the right ports, harden your configuration, use SSH keys, and troubleshoot common issues. Whether you’re on Ubuntu, Debian, CentOS, AlmaLinux, Rocky, or SUSE, this step-by-step tutorial keeps things simple and secure.

What Is SSH and Why It Matters?

SSH (Secure Shell) encrypts remote logins, file transfers, and command execution between your computer and a server. It replaces insecure protocols like Telnet and rsh. With SSH installed and configured correctly, you can administer your Linux server safely over the internet, automate tasks, and deploy code without exposing credentials in plain text.

Quick Start: Install SSH on Popular Linux Distributions

OpenSSH is the most common SSH implementation on Linux. Use the appropriate command for your distribution to install the OpenSSH server component.

Ubuntu and Debian

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh
# On some Debian/Ubuntu releases the service is 'ssh' not 'sshd'
# Verify:
systemctl status ssh || systemctl status sshd

RHEL, CentOS, AlmaLinux, and Rocky Linux

sudo dnf install -y openssh-server
sudo systemctl enable --now sshd
systemctl status sshd

SUSE / openSUSE

sudo zypper refresh
sudo zypper install -y openssh
sudo systemctl enable --now sshd
systemctl status sshd

Fedora

sudo dnf install -y openssh-server
sudo systemctl enable --now sshd
systemctl status sshd

Alpine Linux

sudo apk update
sudo apk add openssh
sudo rc-update add sshd default
sudo service sshd start

After installing, test connectivity from your local machine:

ssh username@server_public_ip

Open the Firewall and Network Security

SSH uses TCP port 22 by default. You must allow the port in your host firewall and in any cloud security groups.

UFW (Ubuntu/Debian)

sudo ufw allow OpenSSH
# or explicitly:
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

firewalld (RHEL, CentOS, AlmaLinux, Rocky, Fedora)

sudo firewall-cmd --permanent --add-service=ssh
# or:
sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Cloud Security Groups and Providers

On AWS, GCP, Azure, and similar platforms, open TCP/22 in your instance’s security group or firewall rules. Prefer allowing only your office or VPN IPs, not 0.0.0.0/0. If you change the SSH port later, update these rules accordingly.

Verify the SSH Service

• Check process: ps aux | grep sshd
• Confirm listening port: sudo ss -tulnp | grep 22
• Tail logs (Debian/Ubuntu): sudo tail -f /var/log/auth.log
• Tail logs (RHEL-based): sudo tail -f /var/log/secure

Basic SSH Usage

From your workstation, connect with your username and the server IP or DNS:

# Interactive shell
ssh user@203.0.113.10

# Run a single command remotely
ssh user@203.0.113.10 "uptime && df -h"

# Copy files with scp
scp file.txt user@203.0.113.10:/tmp/

# Or with rsync (more efficient)
rsync -avz ~/site/ user@203.0.113.10:/var/www/site/

Configure OpenSSH Server (sshd_config)

The main configuration file is /etc/ssh/sshd_config. Always back it up before editing, then restart sshd after changes.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
# or: sudo vim /etc/ssh/sshd_config

# Restart after changes:
sudo systemctl restart sshd  # or 'ssh' on Ubuntu/Debian

Recommended baseline options:

# Change default port (optional)
Port 22

# Listen on specific interfaces (optional)
#ListenAddress 0.0.0.0
#ListenAddress ::

# Protocol and key exchange defaults are generally safe on current OpenSSH
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin devops
# or AllowGroups sshusers

# Reduce brute-force surface
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# SFTP Subsystem
Subsystem sftp /usr/lib/openssh/sftp-server

If you change the SSH port, remember to add a matching firewall rule before restarting sshd; otherwise, you can lock yourself out. For SELinux-enabled systems, add the new port to the ssh_port_t type.

# Example: change SSH to port 2222
# firewalld
sudo firewall-cmd --permanent --add-port=2222/tcp && sudo firewall-cmd --reload

# UFW
sudo ufw allow 2222/tcp

# SELinux (RHEL-based)
sudo semanage port -a -t ssh_port_t -p tcp 2222 || sudo semanage port -m -t ssh_port_t -p tcp 2222

# Then edit /etc/ssh/sshd_config and restart
sudo systemctl restart sshd

Set Up SSH Key-Based Authentication

SSH keys are more secure and convenient than passwords. Generate a key pair on your local machine and install the public key on the server.

Generate Keys (Linux/macOS/WSL)

ssh-keygen -t ed25519 -C "your_email@example.com"
# Press Enter to accept defaults, set a passphrase for extra security

Copy the Public Key to the Server

# Easiest:
ssh-copy-id user@server_ip

# Manual method if ssh-copy-id is unavailable:
cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Windows (PuTTY/PowerShell)

• Windows 10/11 with OpenSSH client: use PowerShell and run the same ssh-keygen and ssh-copy-id commands as above (install OpenSSH Client if needed).
• Using PuTTY: run PuTTYgen to create an ED25519 key, save the private key (.ppk), copy the public key to ~/.ssh/authorized_keys, and connect via PuTTY specifying your username and server IP.

After verifying key login works, you can disable password-based logins in sshd_config to reduce brute-force risk:

PasswordAuthentication no
sudo systemctl restart sshd

Best Practices to Secure SSH

• Disable root SSH login: PermitRootLogin no
• Use SSH keys, not passwords: PasswordAuthentication no
• Change the default port to reduce noise (e.g., 2222) and update firewall/SELinux.
• Limit access: use AllowUsers/AllowGroups and restrict by IP in firewall or security groups.
• Enable Fail2ban to block brute-force attempts.
• Keep OpenSSH and the OS updated regularly.
• Use a VPN or bastion host for administrative access on sensitive servers.
• Audit logs: monitor /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL-based).

Install and Configure Fail2ban (Optional but Recommended)

# Debian/Ubuntu
sudo apt install -y fail2ban

# RHEL-based (EPEL may be required)
sudo dnf install -y fail2ban
sudo systemctl enable --now fail2ban

# Basic jail for SSH
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
maxretry = 3
bantime = 3600
EOF

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Common Troubleshooting Steps

• Connection refused: Is sshd running? Check with systemctl status sshd and ensure port 22 (or your custom port) is open in firewall and security groups.
• Permission denied (publickey): Verify that the server has your public key in ~/.ssh/authorized_keys with correct permissions (dir 700, file 600, user-owned).
• SELinux blocking non-default port: Use semanage port -a -t ssh_port_t -p tcp <port> and confirm with semanage port -l | grep ssh.
• Host key changed warnings: If you rebuilt a server, remove the old entry from ~/.ssh/known_hosts or use ssh-keygen -R server_ip.
• Verbose client logs: Use ssh -vvv user@server_ip to see detailed negotiation and auth steps.
• Cloud NAT/Port forwarding: If behind a router or hypervisor, ensure port forwarding maps external port to the server’s internal IP and port.

Real-World Tips From Hosting and DevOps

• Bootstrap users with cloud-init: On new cloud VMs, add your public key via cloud-init or provider UI so SSH works immediately without passwords.
• Use a bastion host: Place production servers in private subnets and reach them through a hardened bastion with strict IP allowlists and MFA on your VPN/IdP.
• Automate with Ansible: Manage sshd_config, authorized_keys, and firewalls at scale using Infrastructure as Code to maintain consistency.
• Rotate keys: Treat SSH keys like passwords—rotate, revoke, and track ownership. Consider SSH certificates for large teams.
• Audit ciphers periodically: Modern OpenSSH defaults are safe; avoid re-enabling deprecated algorithms for legacy tools.

If You Host With YouStable

On YouStable’s Linux VPS and dedicated servers, OpenSSH is preinstalled and configured with sane defaults. Our support team can help you enable key-only access, set up Fail2ban, and lock down firewalls. If you need a hardened, ready-to-use environment with SSH out of the box, our engineers can tailor it to your stack.

Step-by-Step: From Zero to Secure SSH

• Install OpenSSH server for your distro.
• Enable and start sshd; confirm it’s listening.
• Allow the SSH port in UFW or firewalld and in cloud security groups.
• Generate SSH keys locally and install your public key on the server.
• Disable root login and password authentication.
• Optionally change the SSH port and update firewall/SELinux.
• Install Fail2ban to block brute-force attempts.
• Document your access model and back up sshd_config securely.

FAQs: Install and Secure SSH on Linux Server

Conclusion

Installing SSH on a Linux server is straightforward: install OpenSSH server, start and enable sshd, and open the firewall. The real power comes from securing it—SSH keys, restricted access, and vigilant logging. Follow the steps above and you’ll have fast, reliable, and hardened remote access suitable for production workloads.