The scenario
You just finished setting up a fresh Fedora Workstation or Server install. You want to connect to it from your laptop without typing a password every time. You also want to lock down the machine so brute-force scripts bounce off the firewall. You found a tutorial that tells you to run ssh-keygen, copy a file, and edit a config. You followed the steps, but the connection still asks for a password. Or worse, you disabled password authentication and now you are locked out of your own machine. This happens when permissions are wrong, the daemon configuration is incomplete, or the key was copied to the wrong location. Fixing it requires understanding how the SSH daemon validates keys and where Fedora stores its configuration.
How SSH key authentication actually works
SSH key authentication replaces a shared secret with a cryptographic handshake. You generate a pair of files on your local machine. One file is private. It stays on your machine and never leaves. The other file is public. You copy it to the remote server. When you connect, the server sends a challenge encrypted with your public key. Your local SSH client uses the private key to solve the challenge and sends the answer back. The server verifies the answer. If it matches, you are in. No password travels across the network.
Think of it like a locked dropbox mounted on a wall. Anyone can slide a letter through the public slot, but only you hold the key to open the box and read the contents. The SSH protocol uses this asymmetry to prove identity without transmitting credentials. Fedora ships with OpenSSH, which enforces strict file permissions to prevent other users on the system from reading your private key or tampering with the authorized keys list. If the permissions are too open, the daemon refuses the key as a security precaution.
Check permissions before you blame the cryptography. OpenSSH rejects keys that are readable by group or other users.
Generate and deploy the key pair
Start by creating a new key pair on the machine you will connect from. Fedora defaults to RSA keys for backward compatibility, but Ed25519 is faster, more secure, and requires less configuration. Run the generation command on your local workstation.
ssh-keygen -t ed25519 -C "your_email@example.com"
# -t ed25519 selects the modern elliptic curve algorithm
# -C adds a comment that helps you identify the key later
# Press Enter to accept the default path ~/.ssh/id_ed25519
# Leave the passphrase empty if you want automatic login, or set one for extra security
The command creates two files in your ~/.ssh directory. The file ending in .pub is safe to share. The file without an extension is your private key. Treat it like a password. Do not commit it to version control. Do not email it to yourself.
Next, place the public key on the remote Fedora system. You can use ssh-copy-id if password authentication is still enabled on the target. This tool handles the directory creation, file appending, and permission fixing automatically.
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@remote-fedora-ip
# -i specifies the public key file to deploy
# ssh-copy-id appends the key to ~/.ssh/authorized_keys on the remote host
# It also sets correct ownership and permissions for the .ssh directory
If ssh-copy-id is unavailable or password login is already disabled, you must copy the key manually. Open the public key file, copy its contents, and paste it into the remote ~/.ssh/authorized_keys file. Ensure the remote directory and file have restrictive permissions.
mkdir -p ~/.ssh
# Create the directory if it does not exist yet
chmod 700 ~/.ssh
# Restrict directory access to the owner only
echo "ssh-ed25519 AAAA... your_email@example.com" >> ~/.ssh/authorized_keys
# Append the public key to the authorized list
chmod 600 ~/.ssh/authorized_keys
# Restrict file access to the owner only
Fedora's OpenSSH daemon checks these permissions every time a connection arrives. A 755 directory or a 644 authorized keys file will cause an immediate silent rejection. The daemon logs the failure, but the client only shows a password prompt.
Run ls -la ~/.ssh on the target. If you see drwxr-xr-x or -rw-r--r--, tighten the permissions before testing the connection.
Configure the SSH daemon
The SSH daemon reads its configuration from /etc/ssh/sshd_config. Fedora ships with a secure default configuration, but some distributions or cloud images disable public key authentication out of the box. You need to verify three directives. Open the configuration file with your preferred editor.
sudo nano /etc/ssh/sshd_config
# Edit the main daemon configuration file
# Use sudo because the file is owned by root
Locate or add the following lines. Remove the leading hash symbol if the line is commented out.
PubkeyAuthentication yes
# Enables public key authentication globally
AuthorizedKeysFile .ssh/authorized_keys
# Tells the daemon where to look for user keys
PasswordAuthentication no
# Disables password login after you verify key access works
Do not disable PasswordAuthentication until you have successfully connected with the key from a separate terminal window. Fedora follows the convention of keeping /etc/ssh/sshd_config as the user-modified configuration. The package maintainer files live in /usr/lib/ssh/sshd_config.d/. If you need to override a setting, place a drop-in file in /etc/ssh/sshd_config.d/ instead of editing the main file. This prevents package updates from overwriting your changes.
sudo systemctl status sshd
# Check the current state and recent log lines before restarting
sudo systemctl reload sshd
# Reload applies configuration changes without dropping active connections
Using reload instead of restart keeps existing sessions alive. This matters when you are configuring a remote server over SSH. A hard restart could terminate your current connection before the new configuration takes effect.
Test the key login in a new terminal before you cut off password access. Future-you will not forgive a premature PasswordAuthentication no.
Verify the connection
Open a fresh terminal on your local machine. Connect to the remote Fedora system using the -i flag to specify the private key, or rely on the default path if you used the standard filename.
ssh -i ~/.ssh/id_ed25519 username@remote-fedora-ip
# -i explicitly points to the private key file
# Omit -i if the key is named id_ed25519 and lives in ~/.ssh
If the configuration is correct, the prompt appears immediately. You will not see a password prompt. If you set a passphrase during key generation, you will be asked for it locally. The SSH agent can cache the passphrase so you only type it once per session.
To confirm the authentication method, run a verbose connection test.
ssh -v username@remote-fedora-ip
# -v enables verbose mode to show the authentication handshake
# Look for "Authentication succeeded" and "Using public key"
# Press Ctrl+C once you see the successful login to avoid entering the remote shell
The verbose output shows exactly which keys the client tried and which ones the server accepted. This output is invaluable when troubleshooting permission mismatches or algorithm restrictions.
Run the verbose test before you lock yourself out. The handshake logs tell you exactly why a key was rejected.
Common pitfalls and error messages
SSH key authentication fails silently in the client most of the time. The client falls back to password authentication, which makes it look like the key was ignored. The real reason is usually in the server logs. Check the journal for OpenSSH messages.
sudo journalctl -xeu sshd
# -x adds explanatory text to log entries
# -e jumps to the end of the journal
# -u filters for the sshd unit specifically
You will often see a line that reads Authentication refused: bad ownership or modes for directory /home/username. This means the home directory or the .ssh directory is group-writable or world-readable. OpenSSH enforces strict permissions to prevent privilege escalation. Fix it by running chmod 700 ~/.ssh and chmod 755 ~ on the remote system.
Another frequent error is Offering public key: ssh-ed25519 ... Server refused our key. This happens when the public key was not appended correctly, or the AuthorizedKeysFile directive points to a different location. Verify the key exists in ~/.ssh/authorized_keys and matches the .pub file exactly. Extra whitespace or line breaks in the file will break parsing.
If you recently upgraded Fedora and the connection fails, check the supported algorithms. Older clients may only support RSA-SHA1, which newer OpenSSH versions disable by default. Add PubkeyAcceptedAlgorithms +ssh-rsa to the client configuration or generate a new Ed25519 key.
Read the server journal before you guess. The daemon logs the exact permission or algorithm mismatch that caused the refusal.
When to use keys versus passwords
Use SSH keys when you need automated scripts, CI/CD pipelines, or routine server management without typing credentials. Use password authentication when you are connecting from an untrusted public terminal and cannot safely store a private key on the machine. Use SSH certificates when you manage dozens of servers and want to avoid copying individual public keys to every host. Use passwordless key login when you trust the local machine completely and want frictionless access. Keep password authentication enabled during the initial setup phase. Disable it only after you verify the key works from multiple locations.
Automate with keys. Lock down with disabled passwords. Verify before you cut the fallback.