SSH (Secure Shell)

By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site

An encrypted way to log in to a remote computer and run commands on it.

You run ssh user@host (port 22 by default) to get an encrypted terminal on a server, and GitHub accepts SSH keys for git push too. Instead of a password you normally use a key pair: the private key stays on your machine and only the public key is copied to the server. Never share or commit the private key: anyone who has it (plus its passphrase, if set) can log in wherever the matching public key is installed.

The intuition

SSH gives you a terminal on another machine over an encrypted channel. Everything you type and everything the server prints travels inside that channel, so a server in a data centre can be administered from a laptop on hotel wifi without exposing a password or a command to the network. The same protocol carries file copies (scp, sftp), Git pushes and tunnels to databases, which is why it sits underneath most day-to-day infrastructure work.

Authentication rests on a key pair. The private key never leaves your machine; the public key is copied to every server you may enter. When you connect, the server issues a challenge only the private key can answer, so nothing reusable crosses the wire. A passphrase on the private key protects it if the laptop is stolen, and an agent keeps the unlocked key in memory so you type the passphrase once per session.

Trust runs in both directions, and the half people forget is the server's identity. On the first connection SSH shows the server's host key fingerprint and asks whether to trust it; the answer is recorded in known_hosts and checked on every later connection. A changed fingerprint means either the server was rebuilt or someone is sitting between you and it. Answering yes without checking throws away the only defence against that second case.

Example

# saves ~/.ssh/id_ed25519 (private) and id_ed25519.pub (public)
ssh-keygen -t ed25519 -C "you@example.com"
# copies that public key to the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com
# log in (port 22 by default)
ssh user@server.example.com

From a fresh laptop to a passwordless login on a research server

Generate a key pair: ssh-keygen -t ed25519 -C "you@example.com". It writes two files, ~/.ssh/id_ed25519 (private, permissions 600) and ~/.ssh/id_ed25519.pub (public, one line beginning ssh-ed25519 AAAA...), and asks for a passphrase. Set one.
Install the public key on the server: ssh-copy-id -i ~/.ssh/id_ed25519.pub analyst@quant.example.com. It logs in once with your password and appends the public line to ~/.ssh/authorized_keys on the server. Nothing from the private file is sent.
First connection: ssh analyst@quant.example.com. SSH prints The authenticity of host 'quant.example.com' can't be established, shows a fingerprint such as SHA256:Xk3... and asks Are you sure you want to continue connecting? Compare the fingerprint with the one your administrator published, type yes, and the host is written to ~/.ssh/known_hosts.
Make it short: add to ~/.ssh/config the block Host quant, HostName quant.example.com, User analyst, IdentityFile ~/.ssh/id_ed25519. Now ssh quant opens the session, and scp results.csv quant:/data/ copies a file using the same settings.
Prove the same key works with GitHub: paste the public line into your GitHub SSH keys page, then run ssh -T git@github.com. The reply is Hi username! You've successfully authenticated, but GitHub does not provide shell access. Remotes of the form git@github.com:org/repo.git now push without a token.
Reach a database behind the server: ssh -L 5433:localhost:5432 quant forwards local port 5433 to PostgreSQL on the server, so psql -h localhost -p 5433 or a pandas read_sql connection string pointing at localhost:5433 talks to the remote database through the encrypted tunnel.

One private key on your machine, its public half on each server, a verified fingerprint in known_hosts, and a config alias so the long form is typed once.

Common pitfalls

Typing yes to an unknown host key without checking the fingerprint. The warning exists to catch a machine impersonating your server; on a first connection compare against the fingerprint the administrator published, and on a changed key stop and ask before deleting the known_hosts line.
Sharing or committing the private key. id_ed25519 belongs on one machine only; a private key in a repository, a shared drive or an email is a leaked credential. Generate a key per device and revoke the public half of a lost one from each server.
Loose file permissions. SSH refuses a private key readable by others, with an unprotected private key file error; fix with chmod 600 ~/.ssh/id_ed25519 and chmod 700 ~/.ssh.
Leaving password authentication enabled on the server. Internet-facing servers are brute-forced within minutes of going online; once keys work, set PasswordAuthentication no in sshd_config.
Running without a passphrase for convenience. A stolen laptop then gives direct access to every server the key is installed on; a passphrase plus ssh-agent costs one prompt per session.

Frequently asked questions

What is SSH used for?

Logging in to a remote machine and running commands as if sitting at it, over an encrypted connection. Around that core it also copies files with scp and sftp, authenticates git push to GitHub and GitLab, forwards ports so a local tool can reach a remote database, and serves as the transport for configuration tools such as Ansible.

What is the difference between SSH and SSL or TLS?

Both encrypt network traffic, but for different jobs. TLS (the successor to SSL) secures application protocols such as HTTPS, where a certificate signed by a certificate authority identifies the server. SSH secures interactive sessions and file transfers, identifies servers by host keys recorded on first use, and authenticates users with key pairs rather than certificates.

How do SSH keys work?

You generate a pair: a private key kept on your machine and a public key placed in authorized_keys on the server. At login the server sends a challenge that can only be answered with the private key, and it verifies the answer with the public one. No password crosses the network, and the public key can be given to anyone without risk.

Why does SSH say the host key has changed?

Because the fingerprint the server presented differs from the one stored in ~/.ssh/known_hosts from an earlier connection. The benign cause is that the server was reinstalled or its keys regenerated. The dangerous cause is a machine intercepting your connection. Confirm with whoever runs the server before removing the old entry and reconnecting.