LiveChat 
Support 
SSH Keyless Login: Set Up Passwordless, Key-Based SSH (Step by Step)
If you manage a Linux server, you have probably typed an SSH password more times than you can count. SSH keyless login replaces that password with an SSH key pair, so `ssh user@host` logs you straight in. The word “keyless” here is a little misleading: you are not removing keys, you are removing the *password*. You authenticate with cryptographic keys instead of typing a secret every time.
This guide walks through exactly how to set up passwordless, key-based SSH, why it is both more convenient *and* more secure, and how to finish the job by disabling password authentication entirely. Every step includes the real commands.
Key Takeaways
• “Keyless” SSH means passwordless, key-based login — you log in with an SSH key pair instead of typing a password.
• The setup is three steps: generate a key pair, copy the public key to the server, then connect. No password prompt.
• Your private key never leaves your machine. The server verifies you with a cryptographic challenge, not a shared secret.
• Permissions matter: `~/.ssh` must be `700`, `authorized_keys` and your private key must be `600`, or SSH silently refuses the key.
• Finish by disabling password authentication (`PasswordAuthentication no`) so brute-force bots have nothing to attack.
What is keyless (passwordless) SSH login?
Keyless SSH login uses public-key cryptography instead of a password. You generate a key pair: a private key that stays on your computer and a public key that you place on the server. When you connect, the server issues a cryptographic challenge that only your private key can answer. If it checks out, you are in — no password typed, nothing prompted.
A password is a *shared secret*. Both you and the server know it, and it travels across the connection on every login. A key pair is different: the private half never leaves your machine. The server only ever holds your public key, which is useless to an attacker on its own. (If you have never created one, see for the full walkthrough, and for the concept.)
Here is the entire process at a glance:
| Step | What it does | Command |
|---|---|---|
| 1. Generate a key pair | Create your private + public keys | `ssh-keygen -t ed25519 -C “[email protected]”` |
| 2. Copy the public key | Install your public key on the server | `ssh-copy-id user@host` |
| 3. Connect | Log in with no password prompt | `ssh user@host` |
| 4. Load passphrase once | Cache your key passphrase for the session | `ssh-add ~/.ssh/id_ed25519` |
| 5. Harden | Turn off password login entirely | `PasswordAuthentication no` in `sshd_config` |
The rest of this guide expands each step with real commands.
How do you generate an SSH key pair?
If you do not already have a key, generate one. The modern, recommended algorithm is Ed25519 — it is fast, compact, and strong:
“`bash ssh-keygen -t ed25519 -C “[email protected]” “`
You will be prompted for a file location (press Enter to accept the default `~/.ssh/id_ed25519`) and a passphrase. Use a passphrase — it encrypts the private key on disk, so a stolen laptop does not equal a compromised server.
“` Generating public/private ed25519 key pair. Enter file in which to save the key (/home/you/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/you/.ssh/id_ed25519 Your public key has been saved in /home/you/.ssh/id_ed25519.pub “`
That creates two files:
“`bash ls -l ~/.ssh/
“`
If your system is older and lacks Ed25519 support, use a 4096-bit RSA key instead:
“`bash ssh-keygen -t rsa -b 4096 -C “[email protected]” “`
How do you copy your public key to the server?
The easiest way is `ssh-copy-id`. It appends your public key to the server’s `~/.ssh/authorized_keys` and sets the right permissions automatically. You will be asked for your password this one last time:
“`bash ssh-copy-id user@host “`
Output looks like this:
“` Number of key(s) added: 1
Now try logging into the machine, with: “ssh ‘user@host'” and check to make sure that only the key(s) you wanted were added. “`
No `ssh-copy-id` available? (It is missing on some systems, including default Windows.) Do it manually. Print your *public* key, then append it to the server’s `authorized_keys`:
“`bash
cat ~/.ssh/id_ed25519.pub “`
“`bash
mkdir -p ~/.ssh chmod 700 ~/.ssh echo “ssh-ed25519 AAAA…your-public-key… [email protected]” >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys “`
Or do it in one piped command from your machine:
“`bash cat ~/.ssh/id_ed25519.pub | ssh user@host \ “mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys” “`
Only ever copy the `.pub` file. The private key (`id_ed25519`, no extension) must never leave your machine.
How do you log in without a password?
Now just connect:
“`bash ssh user@host “`
If your key has a passphrase, you will be asked for the passphrase the first time — but notice the difference: that passphrase unlocks the key locally and never touches the network. To avoid typing it every session, use `ssh-agent`. The agent holds your decrypted key in memory and answers challenges for you:
“`bash
eval “$(ssh-agent -s)”
ssh-add ~/.ssh/id_ed25519 “`
After that, every `ssh user@host` for the rest of your session is instant and silent. You can confirm what the agent is holding:
“`bash ssh-add -l “`
To make connecting even cleaner, add a host entry to `~/.ssh/config`:
“` Host myserver HostName host.example.com User user IdentityFile ~/.ssh/id_ed25519 “`
Now `ssh myserver` is all you need.
Why is passwordless SSH actually more secure, not less?
This is the part that trips people up. “Passwordless” *sounds* less secure — surely removing the password weakens things? In fact it is the single biggest security upgrade you can make to SSH, and understanding why corrects a genuinely dangerous intuition.
A password is a shared secret that travels to the server on every login. That makes it attackable in every classic way: it can be guessed, brute-forced by the bots that hammer every internet-facing SSH port around the clock, phished out of you, shoulder-surfed, or leaked because someone reused a weak one across ten sites. The password is, by far, the most attackable thing about SSH.
Key-based login replaces that shared secret with public-key cryptography. Your private key never leaves your machine. The server verifies you by issuing a cryptographic challenge that is mathematically infeasible to fake without the private key — and nothing secret is ever transmitted to intercept. So “passwordless” does not mean “no authentication.” It means authentication that cannot be brute-forced. There is no secret on the wire to capture and no secret on the server to guess.
The proof comes in the final step. Once key login works, you disable password authentication entirely — and the relentless automated password-guessing attacks that every public SSH server endures suddenly have nothing to attack. They cannot brute-force a key. Passwordless SSH is not a convenience that sacrifices security; it is a security upgrade that *happens* to also be more convenient, because the most attackable thing about SSH is simply removed.
Why do file permissions matter so much?
SSH is deliberately paranoid about permissions. If your key files or `.ssh` directory are readable by other users, SSH assumes the key may be compromised and silently refuses to use it — sending you back to a password prompt (or “Permission denied”) with no obvious explanation. Get these right:
| Path | Required permission | Command |
|---|---|---|
| `~/.ssh` directory | `700` (drwx——) | `chmod 700 ~/.ssh` |
| `~/.ssh/authorized_keys` (server) | `600` (-rw——-) | `chmod 600 ~/.ssh/authorized_keys` |
| Private key (your machine) | `600` (-rw——-) | `chmod 600 ~/.ssh/id_ed25519` |
| Public key | `644` (-rw-r–r–) | `chmod 644 ~/.ssh/id_ed25519.pub` |
Run these on the server (for `authorized_keys`) and on your machine (for the private key):
“`bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_ed25519 “`
Also make sure your home directory is not group- or world-writable, which trips up SSH the same way:
“`bash chmod go-w ~ “`
Set up passwordless SSH on a server built for it. DarazHost VPS and dedicated servers fully support key-based, passwordless SSH out of the box. Generate a key, copy it to your server, log in without a password, then disable password authentication to shut out brute-force bots entirely — secure-by-design server access with 24/7 support to help you set it up without accidentally locking yourself out. It is the difference between a server that quietly fends off thousands of automated login attempts and one that is still rolling the dice on a password.
How do you disable password authentication for real hardening?
Once you have confirmed key login works — open a second terminal and connect successfully before you change anything — turn off password authentication so brute-force attacks become pointless. Edit the SSH daemon config:
“`bash sudo nano /etc/ssh/sshd_config “`
Set (or uncomment and change) these lines:
“` PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no PubkeyAuthentication yes “`
Then validate the config and reload the service:
“`bash
sudo sshd -t
sudo systemctl reload ssh # or: sudo systemctl reload sshd “`
Do not close your working session until you have tested a fresh login in a new window. If something is wrong, you still have an open connection to fix it. This is the one step where locking yourself out is a real risk.
This is the moment the security win becomes concrete: every password-guessing bot on the internet now gets refused instantly, because there is no password to guess. For the full walkthrough, see . For background on the protocol itself, see .
How do you fix common keyless SSH problems?
Most failures come down to three causes. Add the `-v` flag to see exactly what SSH is doing:
“`bash ssh -v user@host “`
“Permission denied (publickey)” — wrong permissions. This is the number-one culprit. Re-check the permissions table above on *both* machines:
“`bash ls -ld ~/.ssh # should be drwx—— (700) ls -l ~/.ssh/authorized_keys # should be -rw——- (600) “`
Still prompted for a password — key not loaded or wrong key. Confirm the agent has your key, and tell SSH explicitly which key to use:
“`bash ssh-add -l # list keys in the agent ssh -i ~/.ssh/id_ed25519 user@host “`
“Could not open a connection to your authentication agent” — agent not running. Start it and re-add your key:
“`bash eval “$(ssh-agent -s)” ssh-add ~/.ssh/id_ed25519 “`
Public key not actually on the server. Verify it landed in `authorized_keys`:
“`bash ssh user@host ‘cat ~/.ssh/authorized_keys’ “`
If your key fingerprint is not in there, repeat the copy step. When in doubt, the verbose output from `ssh -v` will name the exact key it tried and why the server rejected it.
Frequently asked questions
Does “keyless SSH” mean there is no key? No — it is the opposite. “Keyless” is shorthand for *passwordless*: you log in with an SSH key pair instead of typing a password. There is very much a key; you just stop typing a secret.
Is passwordless SSH safe if my laptop is stolen? This is exactly why you set a passphrase on the private key. The passphrase encrypts the key on disk, so a thief cannot use it. For high-value access, store keys on a hardware token (like a YubiKey) so the private key never sits on the disk at all.
Can I use the same key pair for multiple servers? Yes. Copy the same public key to every server’s `authorized_keys`. The matching private key authenticates to all of them. Many admins prefer separate keys per role or environment for tighter control, but one key for many servers is perfectly valid.
What happens if I lose my private key? You lose access via that key — there is no recovery, by design. Remove the corresponding public key line from each server’s `authorized_keys` and add a new one. This is why having a second key or a backup access method matters before you disable password login.
Should I really disable password authentication entirely? Once key login is confirmed working, yes. It is the step that delivers the full security benefit: brute-force bots have nothing to guess. Just verify a fresh key-based login in a new terminal *before* you reload the SSH service.
For the bigger picture on securing and operating Linux servers, see our pillar guide: Linux Server Administration: The Complete Guide to Managing Linux Servers.
