Linux command: ssh

1. The Basics

The job of ssh is to connect you to another computer over an untrusted network and make that connection safe. You type one line, and a moment later your keyboard is attached to a machine somewhere else.

$ ssh This email address is being protected from spambots. You need JavaScript enabled to view it.

Two programs are involved. On your side, ssh is the client. On the far side, a background service called sshd (the SSH daemon) is the server. The client connects to the server on TCP port 22 by default, and the two agree on how to talk before a single character of your session crosses the wire.

In that opening handshake, ssh does three separate things, and it helps to keep them apart in your head:

• It checks the server. The server proves it owns a private host key, so you know you reached the real machine and not an impostor sitting in between.
• It checks you. You prove who you are with a key or a password, so the server knows which account to open.
• It encrypts everything. From the handshake onward, every keystroke and every byte of output is encrypted and integrity-checked.

What makes ssh special is that it did not stay a login tool. Because it can carry any stream of bytes safely, other programs were built on top of it. scp and sftp copy files through it. rsync uses it as its default transport. git push over an ssh:// URL is an SSH session. Ansible configures whole fleets of servers through it. Learn ssh well and you quietly improve every one of those tools at the same time.

The command that turns a remote machine into a local one. Behind a simple login prompt sit host keys, key pairs, an agent, a config file, and a tunnelling engine that most users never touch.

This article starts with your very first connection and builds up to keys, the config file, port forwarding, jump hosts, connection sharing, and server hardening. By the end you should be able to read an ssh command someone else wrote and know exactly what it does.

The right mental model: ssh is not a "remote terminal program". It is an encrypted tunnel between two machines, and a terminal session is only the most common thing you push through it. Once you see the tunnel, port forwarding and jump hosts stop looking like tricks and start looking obvious.

3. A Short History

Unlike ls or cat, which reach back to the first days of Unix, SSH is a response to a specific problem at a specific moment. In 1995, Tatu Ylönen, a researcher at Helsinki University of Technology in Finland, discovered a password-sniffing attack on his university network. Someone was capturing the plain-text passwords that telnet and rlogin handed over so freely. He wrote SSH as the fix and released it as freeware in July of that year. By the end of 1995 it had roughly 20,000 users in fifty countries.

Success brought a company, and the company brought licences. Later versions of the original SSH became commercial and increasingly restrictive. In 1999 the OpenBSD team took the last freely licensed code, version 1.2.12, cleaned it up, and released OpenSSH. It shipped with OpenBSD 2.6 on 1 December 1999. A separate portable branch was started almost immediately so the same code could run on Linux and other Unix systems, and that is the version nearly everyone runs today.

You can see both facts in the version string on any Linux box:

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.18, OpenSSL 3.0.13 30 Jan 2024

The p1 stands for portable, release 1. Everything after the comma is what your distribution added on top.

Meanwhile the protocol itself was rewritten. The original SSH-1 protocol had design weaknesses, and a redesigned SSH-2 replaced it. The IETF published SSH-2 as a standard in January 2006, spread over RFC 4251 to RFC 4254. SSH-1 is long dead and modern OpenSSH cannot speak it at all.

That last row is worth a second look. The people who capture encrypted traffic today, hoping to decrypt it once quantum computers arrive, are already a real threat model. SSH has quietly moved to key exchange that resists them, and on OpenSSH 9.6 you can watch it happen:

$ ssh -v server.example
...
debug1: kex: algorithm: This email address is being protected from spambots. You need JavaScript enabled to view it.
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: This email address is being protected from spambots. You need JavaScript enabled to view it. MAC: <implicit> compression: none

You did not ask for any of that, and you did not have to. Keeping ssh updated is most of the security work.

5. Moderate Use Cases

5.1 Keys Instead of Passwords

Typing a password on every connection is slow, and worse, a password can be guessed, phished, or brute-forced by the endless robots that scan port 22 all day. Public key authentication solves both problems at once.

You generate a key pair: a private key that never leaves your machine, and a public key that you can hand out freely. The server keeps a copy of the public key. When you connect, the server sends a challenge, your client signs it with the private key, and the server verifies the signature with the public key. Your secret is never transmitted, not even once.

$ ssh-keygen -t ed25519 -C "peter@laptop"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/peter/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/peter/.ssh/id_ed25519
Your public key has been saved in /home/peter/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY peter@laptop
The key's randomart image is:
+--[ED25519 256]--+
|.. .             |
|. o .+.          |
| o ooo+          |
|. o =+ = .       |
|.o +..* S        |
|+E .o...         |
|*+o. o           |
|@@o .            |
|^X+              |
+----[SHA256]-----+

That little picture at the end is the randomart: a visual drawing of the same fingerprint. The idea is that humans spot a changed picture faster than a changed string of base64. Almost nobody uses it, and you can safely ignore it.

Three flags matter here. -t (short for type) picks the algorithm, -C (short for comment) adds a label so you can tell your keys apart later, and -f (short for file) sets the filename if you do not want the default.

On OpenSSH 9.5 and newer you can leave -t out entirely, because Ed25519 is now the default. It is the right choice for almost everyone: modern, fast, and short enough to fit on one line.

Look at what you actually get. The public key is one readable line, and the private key is an encrypted block you never open:

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDA3N37toeUWk+bfwHUdgC64txzH0aqdogl9qkha0mme peter@laptop

$ head -2 ~/.ssh/id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

The public line has three fields: the key type, the key itself in base64, and your comment. Sharing that line is safe. The file without .pub is the one that must never leave your machine, never be pasted into a chat, and never be committed to git.

Always set a passphrase. A private key file with no passphrase is a plain-text credential: anyone who copies that one file owns every server it opens. With a passphrase, the file on disk is encrypted, and a stolen laptop is an inconvenience instead of a breach. Section 5.4 removes the daily cost of typing it.

If you already have a key without one, you do not have to start over. The -p flag (short for passphrase) changes the passphrase on an existing key, leaving the key itself untouched, so nothing on any server needs updating:

$ ssh-keygen -p -f ~/.ssh/id_ed25519
Key has comment 'peter@laptop'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

5.2 Getting Your Key onto the Server

The server keeps your public keys in ~/.ssh/authorized_keys, one per line. You can append the line by hand, but there is a tool that does it correctly, including creating the directory with the right permissions:

$ ssh-copy-id This email address is being protected from spambots. You need JavaScript enabled to view it.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/peter/.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

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh This email address is being protected from spambots. You need JavaScript enabled to view it.'"
and check to make sure that only the key(s) you wanted were added.

It logs in with your password one last time and appends the key. Use -i to pick a specific key and -n for a dry run that shows what it would do:

$ ssh-copy-id -n -i ~/.ssh/id_ed25519.pub This email address is being protected from spambots. You need JavaScript enabled to view it.
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.

Permissions matter more than beginners expect, and ssh deliberately refuses to work when they are wrong. Both sides check:

~/.ssh                 700   (drwx------)
~/.ssh/id_ed25519      600   (-rw-------)   private key
~/.ssh/id_ed25519.pub  644   (-rw-r--r--)   public key
~/.ssh/authorized_keys 600   (-rw-------)   on the server

Get the private key wrong and you get one of the loudest error messages in Unix:

$ ssh -i ~/.ssh/id_ed25519 This email address is being protected from spambots. You need JavaScript enabled to view it.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/peter/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

The fix is one command: chmod 600 ~/.ssh/id_ed25519. This is also the single most common reason a key that "worked yesterday" stops working after files have been copied around with the wrong flags.

5.3 Checking That It Worked

Before you turn passwords off anywhere, confirm from the server's own logs that the key was used. On the server:

$ sudo journalctl -u ssh --since "10 min ago" | tail -3
Accepted publickey for peter from 203.0.113.55 port 50962 ssh2: ED25519 SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY

The word to look for is publickey. If it says password, your key is not being used yet and disabling passwords will lock you out.

The service name differs between distribution families, which catches people who work on both. Debian and Ubuntu call the unit ssh; Red Hat, Fedora, and SUSE call it sshd. If one name returns nothing, try the other:

$ systemctl status ssh      # Debian, Ubuntu
$ systemctl status sshd     # RHEL, Fedora, SUSE

These logs are worth more than a one-off check. They record failed attempts, unknown usernames, and source addresses, so they are the first place to look when you want to know whether anyone else has been trying the door.

5.4 The Agent: Typing Your Passphrase Once

A passphrase on your key is only bearable if you type it once per day rather than once per connection. That is the job of ssh-agent, a small background program that holds your decrypted private keys in memory and signs challenges on request. It never hands the key itself to anything.

$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/peter/.ssh/id_ed25519:
Identity added: /home/peter/.ssh/id_ed25519 (peter@laptop)

$ ssh-add -l
256 SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY peter@laptop (ED25519)

The -l flag (short for list) shows what the agent currently holds. On a desktop Linux system an agent is usually started for you at login, and your desktop keyring may unlock the key automatically. On a server or a bare shell you may need to start one yourself:

$ eval "$(ssh-agent -s)"
Agent pid 74960

Two options make the agent nicer to live with. ssh-add -t (short for time) sets a lifetime, so the key is forgotten again after a while, and AddKeysToAgent yes in your config loads a key into the agent the first time you use it, so you never run ssh-add by hand at all:

$ ssh-add -t 8h ~/.ssh/id_ed25519    # forget it after eight hours

5.5 The Config File That Changes Everything

If you learn only one thing from this article beyond keys, make it ~/.ssh/config. It turns long, forgettable commands into short names, and it is where experienced administrators keep their whole server list.

Host web
    HostName web01.example.com
    User peter
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host *.internal
    User admin
    ServerAliveInterval 60

Host *
    AddKeysToAgent yes
    HashKnownHosts yes

With that in place, this:

$ ssh -p 2222 -i ~/.ssh/id_ed25519 This email address is being protected from spambots. You need JavaScript enabled to view it.

becomes this:

$ ssh web

The alias works everywhere, not just in ssh: scp file web:/tmp/ and rsync -a site/ web:/var/www/ read the same file.

One rule governs the whole file, and it surprises people: the first value found for each setting wins. Later blocks cannot override an earlier one. That is the opposite of most config formats, and it means specific Host blocks belong at the top and the catch-all Host * belongs at the bottom.

When you are not sure what ssh will actually do, ask it. The -G flag prints the fully resolved configuration for a destination without connecting:

$ ssh -G web | grep -E '^(hostname|user|port|identityfile)'
user peter
hostname web01.example.com
port 2222
identityfile ~/.ssh/id_ed25519

This one command answers most "why is it connecting as the wrong user?" questions in seconds.

5.6 Living with known_hosts

Every host you accept lands in ~/.ssh/known_hosts. On Debian and Ubuntu the entries are hashed by default, because /etc/ssh/ssh_config ships with HashKnownHosts yes, so the file looks like this rather than listing your servers in readable text:

$ head -1 ~/.ssh/known_hosts
|1|2UYDkyiaFpx+aPALlarpS9sQdVI=|KpOmbFYFEeDy0di64KcmzAaRymA= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...

That hashing is a deliberate defence: if someone steals your laptop or your backups, they do not also get a tidy list of every server you administer. The trade-off is that you cannot read the file, so you need ssh-keygen to work with it. Use -F (short for find) to look a host up and -R (short for remove) to delete it:

$ ssh-keygen -F server.example      # is this host known?
$ ssh-keygen -R server.example      # forget it

Sooner or later you will meet the alarming version of this. Reinstall a server, or move a domain to a new machine, and the host key changes:

$ ssh This email address is being protected from spambots. You need JavaScript enabled to view it.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:pWQKB1gfFxQ8fTJ9KiwFIFmT4g71fILH0jZEHn3mOII.
Offending ED25519 key in /home/peter/.ssh/known_hosts:2
  remove with:
  ssh-keygen -f '/home/peter/.ssh/known_hosts' -R 'server.example'
Host key verification failed.

ssh even hands you the exact command to make the warning go away, which is precisely why the warning gets ignored. Stop and think first. If you reinstalled that server an hour ago, the change is expected and you can clear the entry. If nothing changed on your side, this is the one warning in all of Linux that genuinely means "someone may be intercepting you", and the correct response is to find out why before you type anything else.

7. Under the Hood: What the Encryption Actually Does

You can use SSH for years without opening this box, and everything above works whether you read this section or not. But a surprising number of confusions disappear once you know what is really happening, so it is worth twenty minutes.

7.1 Three Kinds of Keys, and Why People Mix Them Up

The word key is used for three completely different things in SSH. Almost every muddled conversation about SSH security comes from mixing them up.

The first two are long-lived and you manage them. The third kind is created fresh for every single connection and you never see it. When somebody says "SSH keys", they nearly always mean the second kind, but the warning in section 5.6 is about the first kind, and that is exactly why that warning confuses people.

7.2 The Handshake, Step by Step

Here is the order of events when you type ssh This email address is being protected from spambots. You need JavaScript enabled to view it.:

1. The client resolves the hostname and opens a plain TCP connection to port 22.
2. Both sides announce their version strings and their lists of supported algorithms.
3. They agree on which algorithms to use: one for key exchange, one for the host key, one cipher, one integrity check. The winner is the first entry on the client's preference list that the server also supports, which is why keeping your client up to date improves the connection even to an older server.
4. They run the key exchange, which produces shared session keys without either side ever sending them across the wire.
5. The server signs part of that exchange with its host key, proving its identity. Your client checks the signature against known_hosts.
6. Encryption switches on. Everything from here is protected.
7. Only now do you authenticate, inside the encrypted channel.
8. The session starts and the server launches your shell or your command.

Step 7 is the one worth remembering. Your credentials are sent after encryption is running, which is why even a plain password over SSH is not exposed to the network, and why SSH replaced telnet so completely. It also explains the order of the -v output: key exchange chatter first, authentication attempts second.

You can see the negotiated result on any connection:

$ ssh -v server.example 2>&1 | grep -E 'kex:|Server host key'
debug1: kex: algorithm: This email address is being protected from spambots. You need JavaScript enabled to view it.
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: This email address is being protected from spambots. You need JavaScript enabled to view it. MAC: <implicit> compression: none
debug1: Server host key: ssh-ed25519 SHA256:Cbs69zP2QMpFcfrRMSlg3fsDbEpOD+MH2FANbuWy5J8

And you can ask your client what it is willing to negotiate at all. The -Q flag (short for query) lists the algorithms your build supports:

$ ssh -Q kex        # key exchange methods
$ ssh -Q key        # key and certificate types
$ ssh -Q cipher     # symmetric ciphers

This is how you check a compliance requirement or confirm that an old algorithm really is gone, instead of guessing from a blog post.

7.3 Forward Secrecy: Why a Stolen Host Key Does Not Unlock the Past

Notice that the session keys in step 4 are generated fresh and never stored. That gives SSH a property called forward secrecy, and it is stronger than most people assume.

Suppose an attacker records your encrypted SSH traffic today and keeps it. Years later they break into the server and steal its private host key. They still cannot read the recorded sessions. The host key only signed the handshake, it never encrypted the data, and the keys that did encrypt it were discarded the moment you logged out.

The host key proves who you talked to. It does not protect what you said. That job belongs to session keys that no longer exist, which is why capturing SSH traffic for later decryption is a poor investment.

This is also the reason the post-quantum key exchange from section 3 matters so much. Forward secrecy holds as long as the key exchange itself cannot be broken later, so moving that step to a quantum-resistant algorithm protects conversations you are having today.

7.4 Certificates: Keys That Expire By Themselves

Everything so far copies public keys into authorized_keys, one file per user per server. With five servers that is fine. With two hundred servers and thirty engineers it becomes a filing problem, and the hard part is not adding access but removing it when somebody leaves.

OpenSSH solves this with certificates. You create one certificate authority key, and servers are told to trust it. The CA then signs user keys, and a signed key carries an identity, a list of principals, and an expiry date.

$ ssh-keygen -t ed25519 -f user_ca -C "user CA"          # once, kept very safe

$ ssh-keygen -s user_ca -I "peter@laptop" -n peter -V +1h ~/.ssh/id_ed25519.pub
Signed user key id_ed25519-cert.pub: id "peter@laptop" serial 0 for peter valid from 2026-08-11T14:04:00 to 2026-08-11T15:05:38

The flags read as a sentence: -s (short for sign) picks the CA key, -I (short for identity) labels who this is for the logs, -n lists the usernames the certificate may log in as, and -V (short for validity) sets the lifetime. You can inspect the result at any time:

$ ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub
        Type: This email address is being protected from spambots. You need JavaScript enabled to view it. user certificate
        Signing CA: ED25519 SHA256:f0JisVLECAQaZ8Zvusfs/hcR2RSfhKN3P0sHDRiCmFc
        Key ID: "peter@laptop"
        Valid: from 2026-08-11T14:04:00 to 2026-08-11T15:05:38
        Principals:
                peter
        Extensions:
                permit-pty
                permit-port-forwarding
                ...

On the server, one line in sshd_config replaces the whole filing system:

TrustedUserCAKeys /etc/ssh/user_ca.pub

That is the entire setup. With that in place, a login succeeds even though the user's authorized_keys file is completely empty, and the server log records which certificate was used and which CA vouched for it:

Accepted publickey for peter from 203.0.113.55 port 52318 ssh2: ED25519-CERT SHA256:cSoLJ2nLw74r... ID peter@laptop (serial 0) CA ED25519 SHA256:f0JisVLECAQaZ8Zvusfs/hcR2RSfhKN3P0sHDRiCmFc

And when the hour is up, the key stops working everywhere at once, with no cleanup to forget:

$ ssh This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.: Permission denied (publickey).

# in the server log:
Certificate invalid: expired

The same idea works in the other direction. A host certificate signed by a CA that your clients trust removes the trust-on-first-use question from section 4.2 entirely: new servers are recognised immediately, and no one has to compare fingerprints by hand. The trade-off is real, though. The CA private key becomes the most valuable secret you own, because it can vouch for anyone, so it belongs offline or in hardware rather than on a build server.

9. Best Practices

• Use Ed25519 keys with a passphrase, and an agent. ssh-keygen -t ed25519 once, ssh-add once a day, and you get better security and less typing at the same time.
• Turn off password authentication once keys work. Check the server log for Accepted publickey first, keep a second session open, and only then set PasswordAuthentication no.
• Put everything in ~/.ssh/config. Hosts, users, ports, keys, jump hosts, keepalives. Remember that the first matching value wins, so specific blocks go at the top.
• Never share or copy a private key. One key pair per machine you type on. If a laptop is lost, you remove one public key from authorized_keys instead of rotating everything.
• Read the host key warning before you clear it. Expected after a reinstall, alarming at any other time. This is the one warning that is worth ten minutes of your attention.
• Restrict automated keys. Any key used by a script or a CI system deserves restrict, a forced command=, and a from= address list.
• Prefer ProxyJump over agent forwarding. Same convenience, none of the risk.
• Ask what an account can reach, not just what it can type. SSH access is network access. Set AllowTcpForwarding no for accounts that do not need tunnels.
• Once key files become a filing problem, move to certificates. One trusted CA, short validity periods, and access that expires on its own instead of waiting for someone to remember it.
• Turn on connection sharing. ControlMaster auto with ControlPersist makes every SSH-based tool you own feel faster for the cost of four lines of config.
• Keep OpenSSH updated. Cipher and key-exchange defaults improve with every release, and you inherit those improvements for free.
• Reach for the documentation. The manual pages are excellent and cover far more than any article can.

$ man ssh              # the client
$ man ssh_config       # every client option, including the config file
$ man sshd_config      # every server option
$ man ssh-keygen       # keys, fingerprints, known_hosts, certificates
$ ssh -G server        # what ssh will actually do for this host

11. Summary

The ssh command looks like a way to get a terminal on another machine, and it is. It is also the encrypted tunnel that most of modern server administration runs through.

• ssh means Secure SHell. It replaced telnet, rlogin, and rsh, which sent passwords in plain text, and it uses port 22 because that sat between ftp and telnet.
• Tatu Ylönen wrote it in 1995 after a password-sniffing attack in Finland. The OpenBSD team forked the last free version into OpenSSH in 1999, and the SSH-2 protocol became an IETF standard in 2006.
• Every connection does three things: verifies the server's host key, authenticates you, and encrypts everything. The first-connection question and known_hosts are how the first of those works.
• Public key authentication beats passwords: ssh-keygen -t ed25519, ssh-copy-id, then PasswordAuthentication no on the server. Always set a passphrase and let ssh-agent hold the key.
• ~/.ssh/config turns long commands into short aliases and is read by scp, rsync, and git too. The first matching value wins, so specific hosts go at the top.
• -L brings a remote port to you, -R hands a local port out, and -D turns ssh into a SOCKS proxy for a whole private network.
• -J (ProxyJump) reaches machines behind a bastion, end to end encrypted, and is the safe replacement for agent forwarding.
• ControlMaster with ControlPersist reuses one connection for many sessions and makes every SSH-based tool noticeably faster.
• A tilde at the start of a line talks to your local client, not the server: ~. kills a frozen session, ~? lists the rest, and ~C adds a port forward without reconnecting once you set EnableEscapeCommandline yes.
• In authorized_keys, restrict, command=, and from= reduce a key to exactly one job from exactly one place.
• Three different things are called a key: the server's host key, your user key, and the throwaway session keys that do the actual encrypting. Because the session keys are discarded, a host key stolen later cannot decrypt traffic recorded today.
• SSH certificates replace copying public keys everywhere: one CA signs a key with an identity and an expiry date, servers trust the CA through TrustedUserCAKeys, and access ends by itself.
• Giving somebody SSH access gives them network access to everything the server can reach. AllowTcpForwarding no and permitopen put limits on that.
• On the server, PasswordAuthentication no, PermitRootLogin no, and AllowUsers do most of the work. Test with sshd -t and keep a second session open.
• When in doubt, run ssh -v to see what happens, or ssh -G host to see what would happen.

This is the quick reference worth keeping:

ssh user@host                      log in
ssh -p 2222 user@host              non-standard port
ssh user@host 'uptime'             run one command and exit
ssh -v user@host                   show what is going wrong
ssh -G host                        show the resolved config, do not connect

ssh-keygen -t ed25519 -C "me@laptop"   create a key pair
ssh-copy-id user@host                  install the public key
ssh-add -t 8h ~/.ssh/id_ed25519        load it into the agent for 8 hours
ssh-keygen -lf ~/.ssh/id_ed25519.pub   show a key fingerprint
ssh-keygen -p -f ~/.ssh/id_ed25519     add or change the passphrase
ssh-keygen -R host                     forget a changed host key
ssh-keygen -s ca -I who -n user -V +8h key.pub   sign a short-lived certificate
ssh-keygen -Lf key-cert.pub            inspect a certificate

ssh -f -N -L 3307:127.0.0.1:3306 host  remote database on your local port 3307
ssh -f -N -R 9097:127.0.0.1:3000 host  your local app on the server's port 9097
ssh -f -N -D 9098 host                 SOCKS proxy through the server
ssh -J user@gateway user@internal      reach a host behind a bastion
ssh -O check host                      is a shared master connection running?

~.     disconnect a frozen session      (press Enter first)
~#     list the forwards on this connection
~?     list the escape sequences
~C     add a port forward mid-session   (needs EnableEscapeCommandline yes)

SSH is the one command where a small amount of extra knowledge pays back every single day: fewer passwords, faster deployments, and a server that stops being interesting to the robots scanning it.