<\/span><\/h3>\n\n\n\nWhen ssh-keygen<\/code> asks for a passphrase, give it one. SSH keys without a passphrase are plaintext credentials: anyone who copies that file owns every server it touches.<\/p>\n\n\n\nThe usual objection is that typing a passphrase on every connection defeats the point. It does not, because ssh-agent<\/code> holds the decrypted key in memory for the session:<\/p>\n\n\n\neval \"$(ssh-agent -s)\"\nssh-add ~\/.ssh\/id_ed25519\n<\/code><\/pre>\n\n\n\nYou type the passphrase once per boot and connect freely after that. On macOS, add --apple-use-keychain<\/code> to store it in the Keychain. On Ubuntu desktop, GNOME Keyring usually unlocks your SSH keys automatically at login.<\/p>\n\n\n\n<\/span>Step 3 \u2014 Copy the public key to your server<\/span><\/h3>\n\n\n\nssh-copy-id<\/code> handles installation correctly \u2014 it creates ~\/.ssh<\/code>, appends to authorized_keys<\/code>, and sets permissions in one shot:<\/p>\n\n\n\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub alex@your-server-ip\n<\/code><\/pre>\n\n\n\nEnter your password one last time. If SSH runs on a non-standard port, add -p 2222<\/code> before the username.<\/p>\n\n\n\nNote the -i<\/code> flag pointing at the .pub<\/code> file. Without it, ssh-copy-id<\/code> will happily push every one of the SSH keys loaded in your agent, which quietly grants more access than you intended.<\/p>\n\n\n\nFrom Windows, or without ssh-copy-id.<\/strong> Windows has no ssh-copy-id<\/code>. This PowerShell one-liner does the same job:<\/p>\n\n\n\ntype $env:USERPROFILE\\.ssh\\id_ed25519.pub | ssh alex@your-server-ip \"mkdir -p ~\/.ssh && chmod 700 ~\/.ssh && cat >> ~\/.ssh\/authorized_keys && chmod 600 ~\/.ssh\/authorized_keys\"\n<\/code><\/pre>\n\n\n\nThe same command works from any Unix shell with cat<\/code> in place of type<\/code>. If you only have console access through your host’s panel, open ~\/.ssh\/authorized_keys<\/code> in an editor and paste the public key as a single unbroken line. A line wrapped in the middle is a dead key \u2014 the most frequent failure when people install SSH keys by hand.<\/p>\n\n\n\nAlready provisioned the server with a key through your provider’s control panel? Then this step is done, and you can jump straight to testing.<\/p>\n\n\n\n
<\/span>Step 4 \u2014 Test before you change anything<\/span><\/h3>\n\n\n\nOpen a second terminal<\/strong> and leave the first one connected:<\/p>\n\n\n\nssh alex@your-server-ip\n<\/code><\/pre>\n\n\n\nYou should land on the server with no password prompt. If something looks wrong, ask SSH to explain itself:<\/p>\n\n\n\n
ssh -v alex@your-server-ip\n<\/code><\/pre>\n\n\n\nThe verbose output names which of your SSH keys it offered and what the server said back. Do not continue to step 5 until this login works cleanly.<\/p>\n\n\n\n
<\/span>Step 5 \u2014 Disable password authentication<\/span><\/h3>\n\n\n\nNow that your SSH keys work, close the password door. Rather than editing the main config file, drop a small override into the include directory \u2014 it survives package upgrades and keeps your changes in one readable place:<\/p>\n\n\n\n
sudo nano \/etc\/ssh\/sshd_config.d\/00-hardening.conf\n<\/code><\/pre>\n\n\n\nAdd:<\/p>\n\n\n\n
PubkeyAuthentication yes\nPasswordAuthentication no\nPermitEmptyPasswords no\nKbdInteractiveAuthentication no\nPermitRootLogin prohibit-password\n<\/code><\/pre>\n\n\n\nCheck the syntax before applying it \u2014 sshd -t<\/code> prints nothing at all if the config is valid:<\/p>\n\n\n\nsudo sshd -t && sudo systemctl restart ssh\n<\/code><\/pre>\n\n\n\nWatch for one trap. Cloud images frequently ship \/etc\/ssh\/sshd_config.d\/50-cloud-init.conf<\/code> containing PasswordAuthentication yes<\/code>. Files load in alphabetical order and the first<\/strong> setting wins in OpenSSH, so a 50-<\/code> file silently overrides a 99-<\/code> one. Naming yours 00-hardening.conf<\/code>, as above, keeps you ahead of it. Confirm what is actually live rather than trusting the file:<\/p>\n\n\n\nsudo sshd -T | grep -iE \"passwordauth|pubkeyauth|permitrootlogin\"\n<\/code><\/pre>\n\n\n\n<\/span>Step 6 \u2014 Verify from a fresh session<\/span><\/h3>\n\n\n\nWith your original terminal still open, start a new connection and deliberately ask for a password:<\/p>\n\n\n\n
ssh -o PreferredAuthentications=password alex@your-server-ip\n<\/code><\/pre>\n\n\n\nA Permission denied (publickey)<\/code> response is the result you want \u2014 it proves passwords are genuinely refused and your SSH keys are the only way in. Then connect normally one more time to confirm key login still works. Only now is it safe to close the original session.<\/p>\n\n\n\nSix steps, and your server no longer has a guessable front door.<\/p>\n\n\n\n<\/span>Setting up SSH keys on Debian, AlmaLinux, Rocky Linux and Fedora<\/span><\/h2>\n\n\n\nKey generation is completely distribution-agnostic. ssh-keygen<\/code>, ssh-agent<\/code>, ssh-copy-id<\/code> and ~\/.ssh\/config<\/code> behave identically everywhere, because they are all OpenSSH, not Ubuntu. What changes is the handful of things around them.<\/p>\n\n\n\n<\/span>Debian: the same steps, two things to check first<\/span><\/h3>\n\n\n\nDebian and Ubuntu share the same packaging, the same ssh<\/code> service name, and the same \/etc\/ssh\/sshd_config.d\/<\/code> include directory. Every command above transfers across with no edits at all.<\/p>\n\n\n\nTwo caveats catch people moving from Ubuntu to Debian. A minimal Debian netinst installation often ships without sudo<\/code><\/strong>, and sometimes without an SSH server at all \u2014 you log in as root and add both yourself:<\/p>\n\n\n\napt update && apt install -y sudo openssh-server\nusermod -aG sudo alex\n<\/code><\/pre>\n\n\n\nSecond, Debian does not use socket activation for SSH, so systemctl restart ssh<\/code> behaves the way you expect and the Port<\/code> directive in sshd_config<\/code> is honoured normally. If you are scripting against both distributions, that is a difference worth knowing.<\/p>\n\n\n\n<\/span>AlmaLinux, Rocky Linux and Fedora: four real differences<\/span><\/h3>\n\n\n\nThe RHEL family needs the same six steps plus four adjustments:<\/p>\n\n\n\n<\/th> Ubuntu \/ Debian<\/th> AlmaLinux \/ Rocky Linux \/ Fedora<\/th><\/tr><\/thead> Service name<\/strong><\/td>ssh<\/code><\/td>sshd<\/code><\/td><\/tr>Restart command<\/strong><\/td>sudo systemctl restart ssh<\/code><\/td>sudo systemctl restart sshd<\/code><\/td><\/tr>SELinux<\/strong><\/td>not enforcing<\/td> enforcing by default<\/strong><\/td><\/tr>Firewall<\/strong><\/td>ufw<\/code><\/td>firewalld<\/code><\/td><\/tr>Crypto policy<\/strong><\/td>n\/a<\/td> update-crypto-policies<\/code> can refuse key types<\/td><\/tr>Socket activation<\/strong><\/td>yes on Ubuntu 26.04<\/td> no \u2014 classic sshd.service<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSELinux is the one that will cost you an afternoon.<\/strong> On AlmaLinux, Rocky Linux and Fedora, SELinux is enforcing out of the box and expects ~\/.ssh<\/code> to carry the ssh_home_t<\/code> context. Create that directory by hand, restore it from a backup, or copy files in from elsewhere, and the context comes out wrong. The login then fails with a plain Permission denied (publickey)<\/code> and absolutely nothing useful in the SSH logs \u2014 the denial happens below SSH, so it never explains itself.<\/p>\n\n\n\nThe fix is one command:<\/p>\n\n\n\n
restorecon -R -v ~\/.ssh\n<\/code><\/pre>\n\n\n\nCheck whether SELinux is the culprit before you go hunting elsewhere:<\/p>\n\n\n\n
ls -Z ~\/.ssh\nsudo ausearch -m AVC -ts recent\n<\/code><\/pre>\n\n\n\nUsing ssh-copy-id<\/code> avoids the problem entirely, because it creates the directory in place with the correct context. It only bites when you build authorized_keys<\/code> manually \u2014 which is exactly what people do from a provider console.<\/p>\n\n\n\nThe crypto-policy difference matters less often but is worth knowing: on the RHEL family, update-crypto-policies --show<\/code> reports the system-wide policy, and a FUTURE<\/code> or FIPS<\/code> setting will reject key types that work fine on Ubuntu. Ed25519 is accepted under the default policy, which is another reason to prefer it.<\/p>\n\n\n\n<\/span>Three problems that catch almost everyone<\/span><\/h2>\n\n\n\nPermissions.<\/strong> OpenSSH refuses keys stored in world-readable locations, and gives a vague error when it does. Fix both ends:<\/p>\n\n\n\nchmod 700 ~\/.ssh && chmod 600 ~\/.ssh\/authorized_keys\nchown -R $USER:$USER ~\/.ssh\n<\/code><\/pre>\n\n\n\nA home directory set to 777<\/code> breaks key authentication too, even when ~\/.ssh<\/code> itself is correct.