SSH

Linux hub

SSH (Secure Shell) is a cryptographic network protocol that provides encrypted remote access to Linux servers. It authenticates using key pairs or passwords and creates an encrypted tunnel for all data, replacing insecure protocols like Telnet and rsh.

Understanding SSH — Secure Shell Protocol

What Is SSH in Simple Terms

SSH is the secure front door to every Linux server. Before SSH, engineers used Telnet to access remote servers — and every keystroke, every password, every command was transmitted as plain text across the network. Anyone on the same network could read it with a packet sniffer.

SSH encrypts everything. Your password, your commands, the output — all of it is encrypted before it leaves your laptop. An attacker capturing the packets sees random bytes, not your credentials.

At Zerodha, every engineer SSHs into production servers dozens of times a day. Without SSH, that access would either be impossible to do securely or would require physical access to the data centre.

How SSH Works

SSH uses asymmetric cryptography for authentication and symmetric encryption for the session:

◈ DIAGRAM

+---------------------------+          +---------------------------+
| Your Laptop               |          | Production Server         |
|                           |          |                           |
| 1. TCP connect port 22    | -------> | sshd listening on :22     |
|                           |          |                           |
| 2. Key exchange (DH)      | <------> | Agree on session key      |
|    Encrypted tunnel starts|          |                           |
|                           |          |                           |
| 3. Authenticate           | -------> | Check authorized_keys     |
|    (key or password)      |          |                           |
|                           |          |                           |
| 4. Encrypted shell session| <------> | bash running as your user |
+---------------------------+          +---------------------------+

Practical Commands

Bash

## Basic connection
ssh user@10.0.1.50
ssh rahul@mumbai-prod-node-1.razorpay.internal
 
## Connect on non-standard port
ssh -p 2222 rahul@10.0.1.50
 
## Connect with specific key file
ssh -i ~/.ssh/id_ed25519 rahul@10.0.1.50
 
## Verbose output for debugging
ssh -v rahul@10.0.1.50    ## one level
ssh -vvv rahul@10.0.1.50  ## maximum debug
 
## Execute a single command without interactive shell
ssh rahul@10.0.1.50 'df -h'
ssh rahul@10.0.1.50 'systemctl status payment-api'
 
## Copy files securely
scp localfile.txt rahul@10.0.1.50:/tmp/
scp rahul@10.0.1.50:/var/log/app.log ./
 
## Sync directories
rsync -avz ./deploy/ rahul@10.0.1.50:/opt/app/
 
## Local port forward: access remote DB on localhost:5433
ssh -L 5433:localhost:5432 rahul@10.0.1.50
 
## Jump through bastion host
ssh -J bastion@52.66.1.100 rahul@10.0.1.50

Troubleshooting

Symptom	Command	What to Check
Connection refused	`ssh -v user@host`	sshd running? Port open? Firewall?
Permission denied	`ssh -v user@host`	Key in authorized_keys? Key permissions?
Host key changed warning	`ssh-keygen -R hostname`	Remove stale known_hosts entry
Slow connection	`ssh -o ConnectTimeout=5 user@host`	DNS resolution delay

Tip
Add frequently accessed servers to ~/.ssh/config with aliases. Then ssh prod-db connects with the right user, port, and key automatically without typing the full command.

Security
Disable password authentication on all production servers. Set PasswordAuthentication no in /etc/ssh/sshd_config. Key-based authentication is exponentially more secure — a brute-force attack against a key pair is computationally infeasible.

Frequently Asked Questions

What specifically made SSH replace Telnet, given both provide remote shell access?

Telnet transmits everything — including the login password — as plaintext over the network, meaning anyone capturing packets on the path could read credentials and session data directly. SSH encrypts the entire session using asymmetric cryptography for authentication and symmetric encryption for the data stream, closing that hole entirely. SSH also verifies server identity via host keys, protecting against man-in-the-middle attacks that plaintext protocols have no defense against.

Why is password authentication over SSH considered a bad practice for production servers?

Passwords are vulnerable to brute-force and credential-stuffing attacks against any internet-facing SSH port, and unlike a key pair, a password can be guessed with enough attempts. The standard practice is disabling password authentication entirely (`PasswordAuthentication no` in sshd_config) and requiring key-based auth, ideally combined with fail2ban or a security group restricting which source IPs can even reach port 22 in the first place.