DEV Community

Cover image for Understanding SSH: A Beginner's Guide
Divyanshu Soni
Divyanshu Soni

Posted on

Understanding SSH: A Beginner's Guide

#ssh #beginners #security #softwaredevelopment

When you hear people in tech talk about SSH, they're usually referring to a way of securely connecting to another computer over the internet or a network. The full form of SSH is Secure Shell.

At first, that might sound abstract, so let's start with a simple picture.

Imagine you have a computer at home, and another one sitting in a data center somewhere far away. You want to log into that remote computer and run commands, just as if you were sitting in front of it. That's exactly what SSH allows you to do, but in a safe and encrypted way.

What Exactly Is SSH?

SSH stands for Secure Shell. It's a cryptographic network protocol that lets you:

  • Log into remote computers securely
  • Execute commands on machines you can't physically touch
  • Transfer files without anyone snooping
  • Create encrypted tunnels for other network traffic

When you hear "I'll SSH into the server," someone is saying they're about to securely connect to a remote machine and control it through the command line.

Image describing SSH

Why SSH Was Invented

Before SSH existed, system administrators used tools like:

Protocol Problem
Telnet Sent everything in plain text: passwords, commands, everything
rlogin No encryption, trusted hosts based on IP (easily spoofed)
FTP Passwords transmitted in clear text

Here's how bad it was: Anyone on the same network could run a packet sniffer and see:

USER: admin
PASS: supersecret123
Enter fullscreen mode Exit fullscreen mode

Literally readable. No encryption. Nothing.

In 90s, a Finnish researcher created SSH after his university network was attacked. The attacker had sniffed passwords right off the wire.

SSH was born from a real security incident and not theoretical paranoia.

The analogy: Telnet was like shouting your bank PIN across a crowded room. SSH is like whispering it through an encrypted radio; only you and your bank can decode.

SSH Protocol Versions

There are two versions of SSH:

Version Status Notes
SSH-1 Deprecated Has known vulnerabilities. Never use it.
SSH-2 Current Standard Complete protocol redesign. What everyone uses today.

SSH-2 isn't just an update, but it's a complete rewrite with:

  • Better key exchange algorithms
  • Improved integrity checking
  • Support for multiple authentication methods in one session

Always ensure your systems use SSH-2. Most modern systems do by default, but legacy systems might not.

How SSH Actually Works

Let's demystify what happens when you type ssh user@server.com and press Enter.

Phase 1: TCP Connection

SSH runs over TCP, typically on port 22. Your client initiates a standard TCP handshake:

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK
Enter fullscreen mode Exit fullscreen mode

Connection established. Now the SSH protocol begins.

Phase 2: Protocol Version Exchange

Both sides announce their SSH version:

Client: SSH-2.0-OpenSSH_8.9
Server: SSH-2.0-OpenSSH_8.4
Enter fullscreen mode Exit fullscreen mode

They agree to use SSH-2. If either only supports SSH-1, modern clients will (and should) refuse to connect.

Phase 3: Key Exchange (The Magic)

This is where cryptographic wizardry happens. The goal: create a shared secret key that no eavesdropper can know.

The most common algorithm is Elliptic Curve Diffie-Hellman (ECDH):

########### Key Exchange (Simplified version) ###########           

1. Client and Server agree on mathematical parameters         

2. Client generates: private value (a), public value (A)      
     Server generates: private value (b), public value (B)      

3. They exchange public values (A and B)                      
     [Attacker can see A and B - doesn't help them]             

4. Client computes: shared_secret = B^a                       
     Server computes: shared_secret = A^b                       
     [Both arrive at the SAME secret!]                          

5. This shared secret derives the session encryption keys
Enter fullscreen mode Exit fullscreen mode

The crux here is: The shared secret is never transmitted. An attacker watching every packet still can't compute it.

Phase 4: Server Authentication (Host Keys)

Here's something many beginners miss: before you authenticate to the server, the server authenticates to you.

When you connect to a server for the first time, you see:

The authenticity of host 'server.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf1234567890...
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Enter fullscreen mode Exit fullscreen mode

This is critical. The server is proving its identity using its host key.

  • If you type yes, the fingerprint is saved to ~/.ssh/known_hosts
  • Future connections verify the server's key matches
  • If it doesn't match, SSH screams at you, like this: 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Enter fullscreen mode Exit fullscreen mode

This protects against man-in-the-middle attacks. If an attacker intercepts your connection and presents their own server, the fingerprint won't match.

Pro tip: On first connection, verify the fingerprint through an out-of-band channel (ask your hosting provider, check their documentation, etc.)

Phase 5: User Authentication

Now you prove who you are. SSH supports several methods:

Method 1: Password Authentication 

ssh user@server.com
# Prompts for password
Enter fullscreen mode Exit fullscreen mode

Simple, but not recommended for several reasons:

  • Passwords can be brute-forced
  • Vulnerable to keyloggers
  • You have to type it every time (no automation)

Method 2: Public Key Authentication (Preferred)

This uses asymmetric cryptography, which is a key pair:

Key Location Purpose
Private Key Your computer (~/.ssh/id_ed25519) Never leaves your machine. Proves your identity.
Public Key Server (~/.ssh/authorized_keys) Can be shared freely. Verifies signatures from your private key.

How it works:

Public Key Authentication flow

The private key never leaves your machine. The server only sees proof that you have it.

Method 3: Certificate-Based Authentication

Used in enterprise environments. A Certificate Authority (CA) signs user keys, and servers trust the CA rather than individual keys.

Phase 6: Encrypted Session

After authentication, everything is encrypted using symmetric encryption (AES-256, ChaCha20, etc.).

Why switch from asymmetric to symmetric? Speed. Symmetric encryption is ~1000x faster.

Every packet also includes a MAC (Message Authentication Code): a cryptographic checksum that detects tampering.

SSH Key Types

When generating keys, you'll need to choose an algorithm:

Algorithm Key Size Status Recommendation
RSA 2048-4096 bits Still secure Use 4096 bits if you must use RSA
DSA 1024 bits Deprecated Never use
ECDSA 256/384/521 bits Secure Good, but some concerns about NIST curves
Ed25519 256 bits Highly recommended Fast, secure, small keys

This command creates a new SSH key pair using the Ed25519 algorithm.

ssh-keygen -t ed25519 -C "your_email@example.com"
Enter fullscreen mode Exit fullscreen mode

Ed25519 advantages:

  • Faster than RSA
  • Smaller keys (easier to manage)
  • No concerns about weak random number generators
  • Designed to be resistant to side-channel attacks

Commands Every Developer Must Know

Generating SSH Keys 

# Generate an Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "your_email@example.com"


# Generate an RSA key (if Ed25519 isn't supported)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Enter fullscreen mode Exit fullscreen mode

You'll be asked for:

  1. File location - Press Enter for default (~/.ssh/id_ed25519)
  2. Passphrase - Encrypts your private key. Use one!

Here,

-t: type - Specifies the type of key to generate → here it's ed25519.

-C: comment - Adds a comment/label to the key → usually your email to identify the key later.

Copying Your Public Key to a Server 

# The easy way
ssh-copy-id user@server.com

# Manual way (if ssh-copy-id isn't available)
cat ~/.ssh/id_ed25519.pub | ssh user@server.com "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Enter fullscreen mode Exit fullscreen mode

Basic Connection 

# Standard connection
ssh user@server.com

# Specify a different port
ssh -p 2222 user@server.com

# Use a specific key
ssh -i ~/.ssh/my_special_key user@server.com

# Connect with verbose output (debugging)
ssh -v user@server.com      # Basic
ssh -vv user@server.com     # More detail
ssh -vvv user@server.com    # Maximum verbosity
Enter fullscreen mode Exit fullscreen mode

SSH Escape Sequences

While in an SSH session, press ~ after a newline for special commands:

Sequence Action
~. Disconnect (kill frozen session)
~^Z Background SSH
~# List forwarded connections
~? Show all escape sequences
~~ Send literal ~

Life saver: When a session freezes, press Enter then ~. to force disconnect.

SSH Security Best Practices

1. Use Key-Based Authentication Only 

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
Enter fullscreen mode Exit fullscreen mode

sshd_config is the main configuration file for the SSH server daemon (sshd).

2. Disable Root Login 

# /etc/ssh/sshd_config
PermitRootLogin no
Enter fullscreen mode Exit fullscreen mode

3. Change the Default Port (Security Through Obscurity) 

# /etc/ssh/sshd_config
Port 2222
Enter fullscreen mode Exit fullscreen mode

This doesn't make you "secure," but it reduces automated attack noise significantly.

4. Limit User Access 

# /etc/ssh/sshd_config
AllowUsers alice bob
# or
AllowGroups sshusers
Enter fullscreen mode Exit fullscreen mode

5. Use Strong Key Types 

# /etc/ssh/sshd_config
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
Enter fullscreen mode Exit fullscreen mode

6. Enable Two-Factor Authentication

Use tools like google-authenticator-libpam to require TOTP codes.

7. Set Up Fail2Ban

Automatically ban IPs with too many failed attempts:

sudo apt install fail2ban
Enter fullscreen mode Exit fullscreen mode

8. Keep SSH Updated 

# Check version
ssh -V

# Update
sudo apt update && sudo apt upgrade openssh-server
Enter fullscreen mode Exit fullscreen mode

9. Audit Your authorized_keys

Regularly review who has access:

cat ~/.ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode

Remove keys from former employees, old devices, etc.

10. Use a Passphrase on Your Private Key

If someone steals your key file, the passphrase is your last defense.

Troubleshooting Common SSH Problems

"Permission denied (publickey)"

Causes:

  1. Key not added to authorized_keys
  2. Wrong permissions on ~/.ssh or key files
  3. Wrong key being used

Fix permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode

Debug:

ssh -vvv user@server.com 2>&1 | grep -i "offering\|trying"
Enter fullscreen mode Exit fullscreen mode

"Connection refused"

Causes:

  1. SSH server not running
  2. Firewall blocking port 22
  3. Wrong port

Check:

# Is SSH running on the server?
sudo systemctl status sshd

# Is the port open?
sudo netstat -tlnp | grep 22
Enter fullscreen mode Exit fullscreen mode

"Host key verification failed"

Cause: Server's host key changed (or you're being attacked).

If legitimate (server rebuilt, etc.):

ssh-keygen -R server.com
Enter fullscreen mode Exit fullscreen mode

Connection Timeout

Try:

# Keep connection alive
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@server.com
Enter fullscreen mode Exit fullscreen mode

Or in ~/.ssh/config:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
Enter fullscreen mode Exit fullscreen mode

SSH in the Real World: Common Scenarios

Scenario 1: Git over SSH

Most developers use SSH for Git:

# Clone using SSH
git clone git@github.com:username/repo.git

# Test your GitHub SSH connection
ssh -T git@github.com
Enter fullscreen mode Exit fullscreen mode

Scenario 2: Deploying Applications 

# Deploy script using SSH
ssh deploy@prod "cd /var/www/app && git pull && npm install && pm2 restart all"
Enter fullscreen mode Exit fullscreen mode

Scenario 3: Database Access 

# Tunnel to access remote PostgreSQL
ssh -L 5432:localhost:5432 user@dbserver.com

# Now connect locally
psql -h localhost -U dbuser -d mydb
Enter fullscreen mode Exit fullscreen mode

Scenario 4: Accessing Cloud Instances 

# AWS EC2
ssh -i ~/.ssh/aws-key.pem ec2-user@ec2-xx-xx-xx-xx.compute.amazonaws.com

# Google Cloud
gcloud compute ssh instance-name

# Azure
ssh azureuser@vm-public-ip
Enter fullscreen mode Exit fullscreen mode

SSH Quick Reference

Connections

• ssh user@host - basic

• ssh -p 2222 user@host - custom port

• ssh -i key user@host - specific key

• ssh -J jump user@host - jump host

Key Management

• ssh-keygen -t ed25519 - generate key

• ssh-copy-id user@host - copy key

• ssh-add ~/.ssh/key - add key

• ssh-add -l - list keys

Escape Sequences (run after pressing Enter)

• ~. - disconnect

• ~^Z - background

• ~# - list forwards

Debugging

• ssh -v user@host - verbose

• ssh -vvv user@host - max verbose

Important Files

• ~/.ssh/config - client config

• ~/.ssh/known_hosts - server fingerprints

• ~/.ssh/authorized_keys - allowed public keys

• /etc/ssh/sshd_config - server config

Permissions

• chmod 700 ~/.ssh

• chmod 600 ~/.ssh/id_ed25519 - private key

• chmod 644 ~/.ssh/id_ed25519.pub - public key

• chmod 600 ~/.ssh/authorized_keys

Conclusion

SSH is one of those technologies that seems simple on the surface: ssh user@server, done. But underneath lies decades of cryptographic engineering designed to keep your connections secure.

What you should remember:

  1. SSH encrypts everything - your credentials never travel in plain text.
  2. Key-based auth beats passwords - always use Ed25519 keys.
  3. Host verification matters - that fingerprint warning exists for a reason.
  4. The config file is your friend - stop typing long commands.
  5. Security is ongoing - audit keys, update software, limit access.

Whether you're managing cloud infrastructure, deploying applications, or just pushing code to GitHub, SSH is the secure foundation that makes it all possible.

Top comments (0)