How to Set Up Passwordless SSH Login

Passwordless SSH login means authenticating with a cryptographic key pair instead of typing a password. You generate a private key (stays on your machine) and a public key (goes on the server). When you connect, SSH proves you hold the private key without ever transmitting it. No password prompt, no credentials sent over the wire.

This is not a convenience shortcut that trades security for speed. Key-based authentication is more secure than passwords in every way that matters. A 256-bit Ed25519 key cannot be brute forced. It cannot be phished. It cannot be guessed. And because you never type or transmit it, it cannot be intercepted by a keylogger or a compromised network.

This guide covers generating a key pair, copying it to a server, testing the connection, the PuTTY workflow for Windows, and the tradeoffs around passphrases.

Why passwordless SSH is more secure than passwords#

This sounds counterintuitive. How can removing a password make things more secure? The answer is that you are not removing authentication – you are replacing a weak authentication method with a stronger one.

Passwords can be guessed. Automated bots scan SSH ports and try common username/password combinations continuously. A weak password falls in minutes. Even a strong password is vulnerable to sustained brute force. See What happens when bots find your WordPress login page – the same credential stuffing attacks hit SSH.

Passwords can be phished. A convincing fake login prompt or social engineering attack can extract a password from a human. A private key file cannot be phished the same way.

Passwords can be intercepted. While SSH encrypts passwords in transit, a keylogger on your local machine captures them before encryption. A private key file sitting on disk is harder to exfiltrate than keystrokes being actively logged.

Passwords are reused. People reuse passwords across services. A breach on one site exposes credentials that attackers try against SSH. Key pairs are unique per purpose.

Keys cannot be brute forced. An Ed25519 key has 256 bits of entropy. There is no computer that can try all possible combinations. A password with 12 characters has roughly 72 bits of entropy at best. The difference is astronomical.

Once key-based authentication is working, you can disable password authentication on the server entirely. This shuts down brute force attacks completely – there is no password endpoint to attack.

Generating a key pair#

On Linux and Mac

Open a terminal and run:

ssh-keygen -t ed25519 -C "your-email@example.com"

You will see:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Press Enter to accept the default location. Then:

Enter passphrase (empty for no passphrase):

Either enter a passphrase or press Enter for no passphrase. More on this tradeoff in the passphrase section below.

This creates two files:

• ~/.ssh/id_ed25519  – your private key. Never share this.
• ~/.ssh/id_ed25519.pub  – your public key. This goes on the server.

On Windows (OpenSSH)

Windows 10 and 11 include OpenSSH. Open PowerShell and run the same command:

ssh-keygen -t ed25519 -C "your-email@example.com"

The keys are saved to C:\Users\YourUsername\.ssh\ . The workflow is identical to Linux and Mac from here.

On Windows (PuTTYgen)

If you use PuTTY instead of OpenSSH, key generation works differently because PuTTY uses its own key format.

1. Open PuTTYgen (installed with PuTTY)
2. Under “Type of key to generate,” select EdDSA (or RSA with 4096 bits if EdDSA is not available in your version)
3. Click Generate
4. Move your mouse randomly over the blank area to generate randomness
5. Once generated, optionally enter a passphrase in the “Key passphrase” field
6. Click Save private key – save as a  .ppk  file somewhere safe
7. The public key is displayed in the text box at the top labeled “Public key for pasting into OpenSSH authorized_keys file.” Copy this entire text.

The .ppk format is PuTTY-specific. If you need an OpenSSH-format private key (for use with the ssh command or other tools), go to Conversions > Export OpenSSH key in PuTTYgen.

Which algorithm to use

Ed25519 is the recommended choice. It is fast, secure, and produces compact keys. Use this unless you have a specific compatibility requirement.

RSA (4096-bit) is the traditional choice. It works everywhere, including very old systems. If you need to connect to a server running an ancient version of OpenSSH that does not support Ed25519, RSA 4096 is the fallback.

ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

ECDSA is also secure and widely supported, but offers no practical advantage over Ed25519 for most users.

Do not use DSA or RSA keys shorter than 2048 bits. Both are considered weak by current standards. OpenSSH has disabled DSA by default since version 7.0.

Copying the public key to the server#

The public key needs to be added to the ~/.ssh/authorized_keys file on the remote server. There are several ways to do this.

Using ssh-copy-id (easiest)

ssh-copy-id user@example.com

This connects to the server using your current authentication method (password), creates the ~/.ssh directory and authorized_keys file if they do not exist, appends your public key, and sets the correct file permissions. It is the simplest method and handles all the details automatically.

If you have multiple keys, specify which one to copy:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@example.com

If the server uses a non-standard SSH port:

ssh-copy-id -p 2222 user@example.com

Manual copy (when ssh-copy-id is not available)

First, display your public key:

cat ~/.ssh/id_ed25519.pub

Output looks like:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere your-email@example.com

Then SSH into the server and add the key:

ssh user@example.com
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere your-email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions matter. SSH refuses to use an authorized_keys file with permissions that are too open. The directory must be 700 (owner only) and the file must be 600 (owner read/write only).

One-liner alternative

cat ~/.ssh/id_ed25519.pub | ssh user@example.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

This pipes your local public key to the remote server and appends it in one step. See How to run commands over SSH for more on this technique.

Through a hosting control panel

On managed hosting platforms, you typically add your public key through the control panel rather than manually editing authorized_keys . On Hostney, SSH key management is in the SSH Keys section of the control panel. Paste your public key there and it is configured automatically for your account. You can also generate a new key pair directly in the control panel.

Testing the connection#

After adding your public key, open a new terminal and connect:

ssh user@example.com

If everything is configured correctly, you log in without a password prompt (or with only a passphrase prompt if you set one on the key).

If it still asks for a password, something is wrong. Check with verbose output:

ssh -vvv user@example.com

Look for lines like:

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519
debug1: Authentication succeeded (publickey).

If you see the key being offered but not accepted, the server does not have your public key or the permissions on authorized_keys are wrong. If you do not see the key being offered at all, SSH is not finding your private key.

Common issues

Wrong permissions on the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~

The home directory itself must not be group-writable or world-writable. SSH’s strict mode checks this.

Wrong key being offered. If you have multiple keys, SSH may try a different one first. Specify the key explicitly:

ssh -i ~/.ssh/id_ed25519 user@example.com

Or configure it in ~/.ssh/config :

Host example.com
    IdentityFile ~/.ssh/id_ed25519
    User john

Server does not allow key authentication. Check /etc/ssh/sshd_config on the server:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

If PubkeyAuthentication is set to no , key-based login is disabled server-side. Change it to yes and restart sshd:

sudo systemctl restart sshd

Configuring PuTTY for key authentication#

Loading your key in PuTTY

1. Open PuTTY
2. In the left panel, navigate to Connection > SSH > Auth > Credentials
3. Under “Private key file for authentication,” click Browse and select your  .ppk  file
4. Go back to Session, enter the hostname and port
5. Optionally save the session so you do not have to configure this every time
6. Click Open

PuTTY uses your private key to authenticate. If the key has a passphrase, PuTTY prompts you for it.

Using Pageant (PuTTY’s SSH agent)

Typing the passphrase every time defeats the convenience of key authentication. Pageant is PuTTY’s SSH agent – it holds your decrypted key in memory so you only enter the passphrase once per session.

1. Open Pageant (it appears in the system tray)
2. Right-click the Pageant icon > Add Key
3. Select your  .ppk  file
4. Enter the passphrase once

Now every PuTTY session automatically uses the key from Pageant without prompting for a passphrase. Pageant runs until you close it or log out of Windows.

Converting between PuTTY and OpenSSH key formats

PuTTY uses .ppk files. OpenSSH uses a different format. If you need to convert:

PuTTY to OpenSSH: Open PuTTYgen, load the .ppk file, go to Conversions > Export OpenSSH key. Save the file (this is your OpenSSH private key).

OpenSSH to PuTTY: Open PuTTYgen, go to Conversions > Import key, select your OpenSSH private key, then click Save private key to create a .ppk file.

Using the SSH agent on Linux and Mac#

The SSH agent works like Pageant – it holds your decrypted keys in memory so you enter the passphrase once instead of every time you connect.

Start the agent and add your key

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The agent runs in the background for the current terminal session. ssh-add prompts for the passphrase once and then the key is available without further prompts.

List loaded keys

ssh-add -l

On Mac

macOS has the SSH agent built into the system. Add your key and store the passphrase in the Keychain:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Then add this to ~/.ssh/config to load keys from Keychain automatically:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

After this, the passphrase is stored in the macOS Keychain and your key is loaded automatically on login. You never type the passphrase again unless you reset the Keychain.

Passphrase vs no passphrase#

When generating a key, ssh-keygen asks for a passphrase. This is an encryption layer on the private key file itself. If someone obtains your private key file, they still need the passphrase to use it.

No passphrase

The private key file is usable as-is. Anyone who gets a copy of the file can authenticate as you. The key is protected only by filesystem permissions and whatever security your machine has.

When this is acceptable:

• Automated scripts and cron jobs that need to connect without human interaction
• Development environments where the key only accesses non-production systems
• Your machine has full-disk encryption and a strong login password

With passphrase

The private key file is encrypted. Even if someone copies the file, they cannot use it without the passphrase. This adds a layer of defense if your machine is compromised, your backup drive is stolen, or you accidentally push the key to a Git repository.

When this is recommended:

• Production server access
• Keys stored on machines shared with others
• Any environment where the consequences of key compromise are significant

The inconvenience of typing a passphrase on every connection is solved by the SSH agent (or Pageant on Windows). Load the key once, and the agent handles authentication for the rest of the session. You get the security of a passphrase with the convenience of passwordless login.

The practical recommendation

Use a passphrase for keys that access production systems or anything you care about. Use the SSH agent so you only type it once per session. For automation-only keys that never have a human in the loop, no passphrase is acceptable as long as the key file itself is properly secured and the key’s access is scoped to what the automation needs.

Disabling password authentication#

Once key authentication is working for all users who need access, you can disable password authentication entirely. This eliminates brute force attacks because there is no password endpoint to attack.

Edit /etc/ssh/sshd_config :

PasswordAuthentication no
ChallengeResponseAuthentication no

Validate the configuration:

sudo sshd -t

Then restart:

sudo systemctl restart sshd

Before doing this, make absolutely sure:

1. Key authentication works for every account that needs SSH access
2. You have console access (KVM, hosting control panel) as a backup in case something goes wrong
3. Root login is either disabled or also has a key configured

If you disable password authentication and your key does not work, you are locked out. Console access through your hosting provider is the only recovery path.

On managed hosting, the provider typically handles this. On Hostney, SSH key authentication is the only supported method – password authentication is not available. This is configured at the infrastructure level, so you do not need to manage sshd_config yourself.

Managing multiple keys#

If you use different keys for different servers (recommended for isolation), configure them in ~/.ssh/config :

Host production
    HostName prod.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod

Host staging
    HostName staging.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging

Host personal
    HostName myserver.example.com
    User john
    IdentityFile ~/.ssh/id_ed25519_personal

Now ssh production , ssh staging , and ssh personal each use the correct key, username, and hostname automatically. This also works with SCP, SFTP, and Git. See What port does SSH use for more on SSH config file options.

SSH key setup on Hostney#

On Hostney, SSH key authentication is required for all SSH, SFTP, and SCP connections. Password authentication is not available.

To set up your key:

1. Generate a key pair on your local machine using the instructions above
2. Open the control panel and go to SSH Keys
3. Paste your public key (the contents of  id_ed25519.pub )
4. Save

Your key is now configured. Connect with:

ssh user@your-server.hostney.com

No password prompt. Your connection details (hostname, port, username) are shown under Terminal Access in the control panel.

SFTP and SCP use the same key automatically:

sftp user@your-server.hostney.com
scp file.txt user@your-server.hostney.com:/var/www/html/

Summary#

Passwordless SSH login replaces password authentication with cryptographic key pairs. Generate a key with ssh-keygen -t ed25519 , copy the public key to the server with ssh-copy-id , and test the connection. Use a passphrase on keys that access production systems and the SSH agent to avoid retyping it. On Windows with PuTTY, generate keys with PuTTYgen and use Pageant as the SSH agent. Once key authentication works, disable password authentication on the server to eliminate brute force attacks entirely.