SSH & Key-based Login

SSH (Secure Shell) is how you work on a Linux server that is somewhere else: in a data centre in Mumbai, in the cloud, or in a VM on your own laptop. It gives you a terminal on the remote machine over an encrypted connection, so nobody on the network can read your commands or passwords.

In this lesson you will connect with a password, then set up key-based login, which is both safer and more convenient, and finish with a config file that turns long commands into short names.

Your first connection

The SSH client (ssh) runs on your computer; the SSH server (sshd) runs on the remote machine and listens on port 22. Ubuntu Server installs the server if you tick "Install OpenSSH server"; otherwise add it with sudo apt install openssh-server. Windows 10 and 11, macOS and Linux all include the client.

ssh priya@203.0.113.10

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:Vb3Lq0P1yZ6c8nD4kT2mW9xR7sF5hJ0aG3eU1oI8pXk.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.10' (ED25519) to the list of known hosts.
priya@203.0.113.10's password:
Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.0.0-15-generic x86_64)
priya@shop-server:~$

The form is user@host. On the first connection, SSH shows the server's host key fingerprint, a short summary of the key that proves the server's identity, and asks you to confirm. If possible, compare it with the fingerprint your cloud provider's console shows. After yes, the key is saved in ~/.ssh/known_hosts, and SSH checks it on every later connection. Type exit (or Ctrl+D) to log out.

You can also run a single command remotely and get the result back without opening a shell: ssh priya@203.0.113.10 'df -h /'.

Why keys are better than passwords

Any server on the internet receives thousands of password guesses a day from automated bots. A password can be guessed, reused or stolen. Key-based authentication uses a key pair instead:

• The private key stays on your computer, protected by a passphrase. Never share or upload it.
• The public key is copied to every server you want to log in to. It is safe to share.

When you connect, the server uses your public key to challenge your client, which proves it holds the matching private key without ever sending it. Bots cannot guess a key, which is why the hardening lesson turns password logins off completely.

Creating a key pair

Use the Ed25519 key type: it is modern, fast and short. On your own computer (not the server):

ssh-keygen -t ed25519 -C "priya@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/priya/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/priya/.ssh/id_ed25519
Your public key has been saved in /home/priya/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:cdK0/BBr8s6FnZMAIEsdu2hPvZhtm3IQJHopABC/Fis priya@laptop
The key's randomart image is:
+--[ED25519 256]--+
|*.  o.oo. o      |
|.. ..oo. = +     |
| .o..+. + X      |
|  o+o..o B * o   |
|E +oo o.S o B    |
| o . o.+ + . .   |
|      +.+ o      |
|      ...o       |
|       oo        |
+----[SHA256]-----+

Press Enter to accept the default file name. Do set a passphrase: if your laptop is stolen, the private key is useless without it. -C adds a comment, usually who and where, so you can recognise the key later. The public key is one line of text:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMIRvrWcNRYg/56BkxkJphJ8ovBQUi6nuyhq++EGIJsx priya@laptop

On Windows, the same ssh-keygen command works in PowerShell and saves the keys in C:\Users\Priya\.ssh\.

Installing the public key on the server

The server reads allowed public keys from ~/.ssh/authorized_keys in the user's home folder, one per line. ssh-copy-id adds your key there and sets the right permissions:

ssh-copy-id priya@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/priya/.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
priya@203.0.113.10's password:

Number of key(s) added: 1

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

Now ssh priya@203.0.113.10 asks for your key's passphrase (or nothing, if an agent holds it) instead of the server password. Windows has no ssh-copy-id; paste the public key into the server's ~/.ssh/authorized_keys with nano, or upload it in your cloud provider's control panel when creating the server.

ssh-agent: type the passphrase once

Typing a passphrase for every connection gets tiring. The ssh-agent holds your unlocked key in memory for the session. Ubuntu's desktop starts one automatically; elsewhere start it and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l

Agent pid 4120
Enter passphrase for /home/priya/.ssh/id_ed25519:
Identity added: /home/priya/.ssh/id_ed25519 (priya@laptop)
256 SHA256:cdK0/BBr8s6FnZMAIEsdu2hPvZhtm3IQJHopABC/Fis priya@laptop (ED25519)

Shortcuts with ~/.ssh/config

Instead of remembering users, IP addresses and ports, give each server a short name in ~/.ssh/config on your computer:

Host shop
    HostName 203.0.113.10
    User priya
    IdentityFile ~/.ssh/id_ed25519

Host lab
    HostName 192.168.56.20
    User kabir
    Port 2222

Now ssh shop is enough, and the same names work with scp and rsync in the next lesson, and with VS Code's Remote SSH extension. The file should be readable only by you (chmod 600 ~/.ssh/config).

Advanced: tunnels and the "host key changed" warning

SSH can forward ports. ssh -L 8080:127.0.0.1:80 shop makes http://localhost:8080 on your laptop reach port 80 on the server, through the encrypted connection. This is how you reach admin pages or a database that listens only on the server's loopback, without opening any firewall port.

If a server is rebuilt, its host key changes, and SSH stops with a large "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message. That is SSH protecting you from a possible impostor. If you know the server was reinstalled, remove the old entry with ssh-keygen -R 203.0.113.10 and connect again; if you do not know why it changed, stop and investigate.

Common mistakes

• Copying the private key to the server. Only the .pub file goes on servers; the private key never leaves your machine.
• No passphrase on the key. A stolen laptop then means stolen server access.
• Wrong permissions on ~/.ssh. Key login silently falls back to a password or fails.
• Ignoring a changed host key. Find out why before you remove the old entry.
• Disabling password login before testing the key. Keep one session open and confirm key login works in a second terminal first.

Key points

• ssh user@host opens an encrypted remote shell; host keys are remembered in ~/.ssh/known_hosts.
• ssh-keygen -t ed25519 creates a key pair; protect the private key with a passphrase.
• ssh-copy-id user@host installs your public key in the server's ~/.ssh/authorized_keys.
• ssh-agent and ssh-add remember your unlocked key for a session.
• ~/.ssh/config gives servers short names; ssh -L forwards ports through the connection.

ssh-keygen -t ed25519 -C "meera@laptop"
ssh-copy-id meera@192.168.56.20
ssh meera@192.168.56.20 'echo key login works'
nano ~/.ssh/config
ssh lab 'hostname'

key login works
lab-vm

Host lab
    HostName 192.168.56.20
    User meera