DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

Set Up SSH Key Login Without Removing Useful Security

#productivity #tutorial #devops #beginners

Typing your server password every time you connect gets old. SSH key authentication replaces that remote account password with proof from a key pair—but it doesn’t mean your connection is unauthenticated, and it doesn’t require leaving your private key unprotected.

The important distinction: your private key stays on your computer; the matching public key goes on the server. You can protect the private key with a passphrase and still avoid entering the server account password on every login.

1. Check for an existing key

Before creating another key, see what’s already in your SSH directory:

ls -la ~/.ssh
Enter fullscreen mode Exit fullscreen mode

A pair such as id_ed25519 and id_ed25519.pub is an existing key. The file ending in .pub is public; the file without that suffix is private. Never copy the private key to the server or share it.

If you don’t have a key, create an Ed25519 key pair:

ssh-keygen -t ed25519 -C "your-email@example.com"
Enter fullscreen mode Exit fullscreen mode

Accept the default location unless you have a reason to use another one. When prompted, set a passphrase to protect the private key if someone gets access to the file. You can use an SSH agent to avoid entering that passphrase every time you connect.

2. Install the public key on the server

On macOS or Linux, ssh-copy-id is the straightforward option:

ssh-copy-id user@server
Enter fullscreen mode Exit fullscreen mode

Replace user and server with the remote account and hostname. The command installs your public key for that account. For additional options and cases such as custom ports, see this guide to using ssh-copy-id.

Windows’ built-in OpenSSH client does not include ssh-copy-id. In PowerShell, you can append the public key to the remote account’s authorized_keys file instead:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Enter fullscreen mode Exit fullscreen mode

This assumes the key is at the default path and that the remote server accepts the initial SSH login. If you use WSL, run the Linux instructions inside WSL.

You can also install the key manually. On the server, create the SSH directory, append the complete one-line contents of your local .pub file to authorized_keys, and set restrictive permissions:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "<paste your public key here>" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode

Run those commands as the account you intend to log in as. authorized_keys is per-user, so installing a key for one account won’t authenticate you as another.

3. Test in a separate connection

Keep your current session open while testing. Open a new terminal window and connect:

ssh user@server
Enter fullscreen mode Exit fullscreen mode

If you reach a shell without entering the remote account password, key authentication is working. If you set a passphrase, SSH may ask you to unlock your local key; that is different from a prompt for the server account password.

If SSH still asks for a password

Check the likely causes in this order:

  1. Wrong account: Confirm you’re connecting as the same user whose authorized_keys contains the public key.
  2. Key not installed: On the server, check that ~/.ssh/authorized_keys contains the public key’s full line.
  3. Permissions too open: The server may reject a key if the home directory or SSH files have unsafe ownership or permissions. ~/.ssh should not be group- or world-writable; chmod 700 ~/.ssh is a safe default. The authorized_keys file should be owner-readable and writable only; use chmod 600 ~/.ssh/authorized_keys. See these details on SSH key permissions.
  4. Wrong key offered: If you have several keys or used a non-default filename, specify the key explicitly: 
   ssh -i ~/.ssh/id_ed25519 user@server
Enter fullscreen mode Exit fullscreen mode

For more detail, ssh -v user@server shows authentication debugging output, including which keys the client offers.

  1. Public-key authentication unavailable: If you administer the server, check whether its SSH server configuration allows public-key authentication. The setting is PubkeyAuthentication yes in sshd_config; providers may apply their own configuration.

Make passphrase-protected keys convenient

An SSH agent can keep an unlocked key available in memory, so you enter its passphrase once per session rather than for every connection. On Linux or macOS, you can start an agent and add the key with:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

You’ll enter the passphrase when adding the key. Subsequent SSH connections in that session can use it automatically.

Disabling password login is a separate decision

You don’t need to turn off password authentication to use SSH keys. If you choose to disable it as a server-hardening step, first confirm key login works from a fresh connection. Keep your existing session open while changing the server configuration, validate it with sudo sshd -t, then reload the SSH service and test another new connection before closing the original session.

That sequence gives you a way back in if the change is misconfigured. Key-based login is the setup; disabling password authentication is optional hardening.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)