SSH, keys and connecting to a server

A server sits in a data centre somewhere; you are at your laptop. SSH (Secure Shell) is how you get a shell on that remote machine — securely, over the network — and it is how essentially all remote server work is done. It is also your first real encounter with public-key cryptography, used in the practical, everyday way you will meet it again in TLS, Git and deployments. This lesson is SSH: connecting, keys, and the habits that keep it secure. It closes the Linux module.

What SSH does

SSH opens an encrypted connection to a remote machine and gives you a shell there — so you type commands on your laptop and they run on the server, with everything in between scrambled so nobody on the network can read it. The basic command:

ssh asha@203.0.113.10        # connect as user 'asha' to the server at that IP
ssh asha@server.example.com  # or by hostname
ssh -p 2222 asha@host        # a non-default port with -p

You land in a shell on the server, exactly like the local one, except now you are operating the remote machine. exit (or Ctrl-D) disconnects. Everything you learned this module — files, permissions, processes, services — you now do over SSH on a real server.

Passwords are the weak way; keys are the right way

You can log in with a password, but on real servers you use SSH keys, which are both more secure and more convenient. A key is a pair of files created together:

A private key — stays on your laptop, secret, never shared. This is you.
A public key — you copy it to the server. It is safe to share.

The maths (the same public-key idea as TLS, in the networking module) means the server can verify that whoever is connecting holds the matching private key, without the private key ever leaving your laptop. So there is no password to guess, phish or reuse. Generate a pair:

ssh-keygen -t ed25519 -C "asha@laptop"   # creates ~/.ssh/id_ed25519 (private) and id_ed25519.pub (public)

ed25519 is a modern, strong key type — prefer it. When asked for a passphrase, set one: it encrypts the private key on disk, so a stolen laptop does not hand over your key. Now put the public key on the server:

ssh-copy-id asha@server        # copies your public key into the server's authorized list

After that, ssh asha@server logs you in using the key — no password. Behind the scenes, the server stored your public key in ~/.ssh/authorized_keys; anyone whose public key is in that file can log in as that user, which is exactly why the private key must stay secret.

Permissions matter here (and SSH enforces them)

Remember the permissions lesson: SSH is strict about who can read your key files, and will refuse to work if they are too open. Your private key must be readable only by you:

chmod 700 ~/.ssh              # the directory: only you
chmod 600 ~/.ssh/id_ed25519  # the private key: only you can read/write
chmod 644 ~/.ssh/id_ed25519.pub

If SSH says "permissions are too open" and refuses your key, this is why — a private key others can read is insecure, so SSH will not use it. This is the permissions lesson made real: the mode of a file is not bureaucracy, it is a security control the tools actively enforce.

Copying files, and the config file

SSH brings companions you will use constantly:

scp copies files over SSH: scp report.txt asha@server:/home/asha/ (to the server) or scp asha@server:/var/log/app.log . (from it). rsync is a smarter alternative for larger or repeated copies.
The ~/.ssh/config file saves you repeating hosts, users, ports and keys. Instead of a long command, define a shortcut:
```
Host prod
  HostName 203.0.113.10
  User asha
  Port 22
  IdentityFile ~/.ssh/id_ed25519
```
Now ssh prod connects with all those settings. On a real team you accumulate a config of named servers, and connecting becomes ssh prod or ssh staging. It is a small quality-of-life win that adds up.

Securing the server side

As you move toward running servers, know the habits that keep SSH access safe — you will apply these when you set up a real server:

Disable password login entirely (keys only), so there is nothing to brute-force.
Do not allow root to log in over SSH — log in as a normal user and use sudo (the permissions lesson).
Keep private keys secret and passphrase-protected; never commit a private key to Git or paste it anywhere.
Use a firewall to limit who can even reach the SSH port.

These are standard server-hardening steps, and they all follow from one idea you now understand: access to a server is guarded by who holds the right private key, so the whole game is keeping private keys private and removing everything guessable (passwords, root login). SSH is your door into every server you will ever operate — treat its keys with care.

Check your work

SSH gives you an encrypted remote shell: ssh user@host (-p for a non-default port); you operate the server as if local, exit to leave. All the module's skills now apply over SSH on real servers.

Keys over passwords: a key pair — private key (stays on your laptop, secret, is you) and public key (copied to the server, safe to share). ssh-keygen -t ed25519 (set a passphrase — encrypts the key on disk); ssh-copy-id puts the public key in the server's ~/.ssh/authorized_keys. No password to guess/phish.

Permissions are enforced: chmod 700 ~/.ssh, 600 the private key — SSH refuses a key others can read ("permissions too open"). The permissions lesson made real: file mode is an enforced security control.

Companions: scp/rsync copy files over SSH; ~/.ssh/config saves named hosts (ssh prod).

Harden the server: disable password login (keys only), disallow root over SSH (use a normal user + sudo), keep private keys secret and passphrase-protected (never commit one), firewall the SSH port. It all follows from "keep private keys private, remove the guessable".

Practice

Generate an ed25519 key pair with ssh-keygen, setting a passphrase; find the two files in ~/.ssh.
Explain which of the two keys goes on the server and which never leaves your laptop, and why.
Set chmod 600 on a private key and explain what SSH does if it is more open than that.
Use scp to copy a file to and from a server (or describe the exact commands you would use).
Write a ~/.ssh/config entry for a server so you can connect with a short ssh <name>.
List four ways to harden SSH on a server and explain how each removes something guessable or over-exposed.

Official documentation

OpenSSH manual (ssh) — The SSH client and its options.
Ubuntu — OpenSSH server & keys — Setting up and securing SSH on a server.
ssh-keygen manual — Generating and managing keys.

Next: the Networking Essentials module — how traffic finds a server.