For our Blog Visitor only Get Additional 3 Month Free + 10% OFF on TriAnnual Plan YSBLOG10
Grab the Deal

How to Use SSH on Linux Server in 2026? – Secure Access Guide

SSH (Secure Shell) is the encrypted protocol used to securely access and manage a Linux server from anywhere.

To use SSH on a Linux server, install OpenSSH, ensure the SSH service is running and reachable through the firewall, connect with ssh user@server, and secure access with SSH keys, hardened settings, and best practices.

Learning how to use SSH on a Linux server is essential for safe remote administration, deployments, and file transfers.

In this guide, you’ll get a practical, step by step walkthrough from your first SSH connection to key based authentication, hardening, tunnels, and troubleshooting written with hands on server experience to help you work faster and more securely.

What is SSH and Why it Matters?

SSH (Secure Shell) creates an encrypted channel between your device (client) and a remote Linux server. It replaces insecure protocols like Telnet by protecting passwords, commands, and data in transit.

SSH uses public key cryptography, supports password and key based logins, and enables secure shell access, file transfers, and encrypted tunnels.

SSH vs. Telnet and RDP

  • Security: SSH encrypts traffic; Telnet does not. RDP is graphical; SSH is command-line.
  • Use Cases: SSH is ideal for server administration, automation, Git operations, and tunneling.
  • Portability: SSH clients are built into Linux and macOS; Windows 10+ includes OpenSSH.

Prerequisites and Quick Start

1. Ensure SSH Client and Server Are Installed

On most Linux and macOS systems, the OpenSSH client is preinstalled. On servers, install and enable the OpenSSH server package:

# Debian/Ubuntu
sudo apt update && sudo apt install -y openssh-server
sudo systemctl enable --now ssh

# RHEL/CentOS/AlmaLinux/Rocky
sudo dnf install -y openssh-server
sudo systemctl enable --now sshd

# Check service
systemctl status ssh || systemctl status sshd

2. Allow SSH Through the Firewall

Open TCP port 22 (or your custom port) on the server. Example with UFW (Debian/Ubuntu):

sudo ufw allow 22/tcp
sudo ufw reload
sudo ufw status

First Connection: Password Authentication

Connect for the first time using the server’s IP or hostname. Replace user with your Linux account (often root on fresh VPS, then switch to a sudo user):

ssh user@your_server_ip
# Custom port
ssh -p 2222 user@your_server_ip

On first connect, SSH asks you to verify the server’s fingerprint (host key). Type yes to trust it, and it’s recorded in ~/.ssh/known_hosts to prevent man-in-the-middle attacks. If you later see a changed host key warning, investigate before proceeding.

SSH keys enable secure, passwordless login and are far stronger than passwords. Generate a key pair on your local machine, then install the public key on the server.

Generate a Key Pair

# Modern, fast, secure:
ssh-keygen -t ed25519 -C "your_email@example.com"

# If your environment requires RSA:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Accept the default path (~/.ssh/id_ed25519) and set a strong passphrase. Your public key is .pub; your private key must remain secret and never be shared.

Copy Your Public Key to the Server

# Easiest method
ssh-copy-id user@your_server_ip

# Manual method if ssh-copy-id isn't available
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Test key login:

ssh user@your_server_ip

Secure Your SSH Server (Hardening Checklist)

Harden sshd_config

Edit the server’s SSH daemon configuration at /etc/ssh/sshd_config:

# Change default port (optional but reduces noise)
Port 2222

# Protocol and host keys
Protocol 2

# Disable root password login (use sudo user + keys)
PermitRootLogin prohibit-password

# Enforce key-based auth
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Restrict users or groups
AllowUsers deploy adminuser

# Secure algorithms (OpenSSH defaults are strong; ensure modern ciphers/MACs if customizing)
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
# MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Limit auth attempts and add login grace
MaxAuthTries 3
LoginGraceTime 20

# Reduce info leakage
PermitEmptyPasswords no
X11Forwarding no
UsePAM yes

Apply changes:

sudo sshd -t        # syntax check
sudo systemctl restart ssh || sudo systemctl restart sshd

Firewall, Rate Limiting, and 2FA

  • Firewall: Allow only your SSH port; optionally restrict by source IP.
  • Fail2ban/SSHGuard: Ban repeated failed logins to block brute-force attempts.
  • 2 Factor Auth: Use PAM modules (e.g., Google Authenticator) for high-security environments.
  • Updates: Keep OpenSSH and the OS updated to patch vulnerabilities.

Day-to-Day SSH Usage

Run Remote Commands and Manage Sessions

# Interactive shell
ssh user@host

# One-off command (no interactive shell)
ssh user@host "uname -a && df -h"

# Allocate TTY for sudo or interactive tools
ssh -t user@host "sudo systemctl status nginx"

End a session with exit or Ctrl+D. For long-running commands, consider tmux or screen to keep tasks alive after disconnects.

Secure File Transfers: SCP, SFTP, rsync

# Copy a file to server
scp file.tar.gz user@host:/var/www/

# Copy a directory from server
scp -r user@host:/etc/nginx/ conf_backup/

# SFTP interactive session
sftp user@host

# rsync over SSH (fast, resumes, excludes)
rsync -avz -e ssh --progress ./site/ user@host:/var/www/site/

Port Forwarding and Tunneling

  • Local Forward (-L): Access a remote service through a local port.
  • Remote Forward (-R): Expose a local service on the remote server.
  • Dynamic Proxy (-D): Create a SOCKS proxy for secure browsing through the server.

# Local: open localhost:8080 to reach remote-db:5432 via the server
ssh -L 8080:remote-db:5432 user@server

# Remote: expose local service:8000 on server port 9000
ssh -R 9000:localhost:8000 user@server

# Dynamic: SOCKS5 proxy on localhost:1080
ssh -D 1080 user@server

Use cases include safely viewing admin panels, connecting to databases without exposing their ports, or browsing securely in untrusted networks.

Speed Up SSH with Config and Multiplexing

Create a per-host config to simplify commands and speed up connections via multiplexing:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/config

# Example
Host prod
  HostName 198.51.100.10
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

Now connect with ssh prod. Multiplexing reuses a single TCP connection for speed across multiple sessions, SCP, and rsync.

Troubleshooting SSH on Linux Server

Common Errors and Fixes

  • Permission denied (publickey): Ensure ~/.ssh/authorized_keys exists, set chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys, and confirm you’re using the correct key and user.
  • Connection refused or timed out: Verify the SSH service is running, the correct port is open in the firewall/security group, and you have the right IP/DNS.
  • Host key changed: Confirm if the server was reinstalled or IP reassigned. Compare fingerprints out-of-band; only then remove the old entry from ~/.ssh/known_hosts.
  • Agent/Passphrase issues: Start ssh-agent and add your key with ssh-add. On macOS, use the Keychain integration; on Linux, use your desktop’s keyring or ssh-agent.

Useful Diagnostics

# Client-side verbose output
ssh -vvv user@host

# Server logs (Debian/Ubuntu)
sudo journalctl -u ssh -f
# Server logs (RHEL family)
sudo journalctl -u sshd -f

# Test if port is listening
sudo ss -tlnp | grep ssh
sudo lsof -i :22

Best Practices for Teams and Production

  • Use unique user accounts with sudo, not shared root.
  • Enforce SSH key authentication and disable password logins.
  • Rotate keys on offboarding; use AuthorizedKeysCommand with centralized IAM for larger teams.
  • Use a bastion/jump host and restrict direct internet access to private servers.
  • Limit SSH by source IP where possible; monitor and alert on auth logs.
  • Automate hardened baselines via Ansible/Terraform and test changes in staging first.
  • Back up critical configs (sshd_config, authorized_keys) and document your process.

If you need a reliable environment to practice and deploy, YouStable’s VPS hosting provides full root access, IPv4, fast NVMe storage, and SSH pre-enabled out of the box. Our support team can help you get secure, key-based access running smoothly without guesswork.

SSH Commands Cheat Sheet

# Basic connect
ssh user@host

# Custom port
ssh -p 2222 user@host

# One-off command
ssh user@host "uptime && whoami"

# Generate keys
ssh-keygen -t ed25519

# Copy key
ssh-copy-id user@host

# File transfer
scp local.txt user@host:/tmp/
rsync -avz -e ssh dir/ user@host:/srv/dir/

# Tunnels
ssh -L 8080:localhost:80 user@host
ssh -D 1080 user@host

# Multiplexing (config)
# ControlMaster auto; ControlPersist 10m

# Restart sshd after changes
sudo systemctl restart ssh   # Debian/Ubuntu
sudo systemctl restart sshd  # RHEL family

FAQ’s

What port does SSH use, and should I change it?

SSH listens on TCP port 22 by default. Changing the port (for example, to 2222) can reduce automated scans and log noise but isn’t a substitute for strong security. Always pair a nonstandard port with key-only authentication, firewall rules, and intrusion prevention like Fail2ban.

How do I fix “Permission denied (publickey)” on SSH?

Ensure your public key is in ~/.ssh/authorized_keys on the server, with permissions 700 for ~/.ssh and 600 for authorized_keys. Confirm you’re using the right user, key file (-i), and host. Check server logs with journalctl -u ssh(-d) and test with ssh -vvv.

Is SSH safe to use over public Wi‑Fi?

Yes—SSH encrypts traffic end to end. Use key-based logins with a passphrase, verify host keys, and avoid bypassing warnings. For extra protection, enable two-factor authentication and consider a SOCKS proxy (ssh -D) to tunnel your browsing through your server.

What’s the difference between SSH, SFTP, and SCP?

SSH provides the secure channel and shell access. SFTP is a file transfer subsystem over SSH with interactive commands. SCP is a simpler copy protocol over SSH. For large or incremental transfers, rsync -e ssh is often preferred due to speed and resume capability.

Sanjeet Chauhan

Sanjeet Chauhan is a blogger & SEO expert, dedicated to helping websites grow organically. He shares practical strategies, actionable tips, and insights to boost traffic, improve rankings, & maximize online presence.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top