Set up SSH keys

An SSH key replaces a password with a cryptographic pair: the private key stays on your machine, the public key on the server. A server breach then does not reveal your login secret. Setup is simple, but the last step, disabling passwords, is the one that locks out the careless.

Generate a key pair

ssh-keygen -t ed25519 -a 100 -C "utilisateur@poste"

ed25519 produces a short, strong key. -a 100 raises the passphrase derivation cost; -C adds a comment to identify the key. Accept the default path ~/.ssh/id_ed25519 or pick an explicit name.

Protect the private key with a passphrase. It never leaves your workstation: do not copy it to the server or commit it to Git. The public key ends in .pub and can be shared.

Install the public key

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@VOTRE_IPV6

The command appends the key to the remote account's ~/.ssh/authorized_keys and creates directories with correct modes. If ssh-copy-id is unavailable, add the line manually:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Check permissions and test

SSH rejects a key when modes are too open. On the server:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

The home directory must not be writable by group or others, ~/.ssh must be 700 and authorized_keys 600. Fix with chmod, never chmod 777. Also confirm that AuthorizedKeysFile points to the real location.

Then keep the SSH session open and start a second window:

ssh -i ~/.ssh/id_ed25519 utilisateur@VOTRE_IPV6

Authentication must use the key. Confirm with ssh -v: the negotiation must mention publickey, not password. If the key fails, do not edit sshd_config: fix permissions or the path first.

Disable passwords

In /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Then:

sudo sshd -t
sudo systemctl reload ssh

sshd -t validates syntax. The reload keeps current sessions alive. Test a new connection immediately; if it fails, the open session lets you roll back by setting PasswordAuthentication yes.

Keep a fallback

• Keep a second key or console access.
• Back up ~/.ssh off the server.
• Use ssh-agent to avoid retyping the passphrase.
• Revoke a key by deleting its line in authorized_keys.

A passphrase-less key on a shared workstation is a risk. A key with a passphrase and a properly configured agent gives the best balance. For highly sensitive access, a FIDO2 hardware key (ed25519-sk) adds a physical check.