Key Points
- SSH without a password uses public-key cryptography so that possession of a private key, not a typed password, proves your identity to a remote server.
- Generating an Ed25519 key pair with ssh-keygen takes under a second and produces keys that match the security of a 3,072-bit RSA key in a fraction of the size.
- Copying your public key to the server with ssh-copy-id appends it to ~/.ssh/authorized_keys: the file OpenSSH checks on every login attempt.
- Disabling PasswordAuthentication in sshd_config locks out password-based logins entirely, blocking brute-force attacks at the protocol level.
- Key pairs work well for individual access; SSH certificate authentication (signed by a certificate authority) is the step up for teams managing access at scale.
Managing dozens of authorized_keys files across a fleet of servers is where SSH key hygiene breaks down. Static public keys never expire, revocation is manual, and auditing who has access to what is a spreadsheet problem. The solution begins with with understanding what SSH without a password actually is, letting users move to more scalable deployments.
This guide walks through the full setup for SSH without a password: generating a key pair, uploading the public key, testing the connection, disabling password logins, and choosing the right key type. At the end, we cover why SSH certificate authentication is the logical next step for enterprise environments.
What Is SSH Without a Password?
SSH without a password, also known as passwordless Secure Shell (SSH) authentication, is a method of authenticating to a remote server using a cryptographic key pair instead of a typed password. The SSH protocol is a network protocol for encrypted remote login and secure data transfer over an untrusted network.
Under the hood, the mechanism is defined in RFC 4252, the SSH Authentication Protocol. The client generates a cryptographic signature using its private key. The server holds a copy of the matching public key and verifies that signature. If the verification passes, the server grants access. No password prompt is needed, and no credentials are sent over the wire.
Two files make this work:
- A private key: Kept only on the client machine
- A public key: Placed in the ~/.ssh/authorized_keys file on every server you want to access
The private key never leaves your machine, and the public key is safe to distribute freely.
How to Set Up SSH Without a Password
To configure SSH without a password, you generate a key pair locally, install the public key on the remote server, and verify key-based authentication before disabling password logins. The following steps outline the complete setup process.
Step 1: Generate an SSH Key Pair
The first step is to generate an SSH key pair. OpenSSH ships ssh-keygen, a key generation tool that supports several algorithms.
For most modern systems, Ed25519 is the recommended algorithm. It provides strong security, smaller key sizes, and faster operations than traditional RSA keys. Ed25519 has been supported in OpenSSH since version 6.5 and is the default choice for most Linux and cloud environments today.
RSA keys are still useful for compatibility with older systems that do not support Ed25519. If you need RSA, use at least 4096 bits.
To generate an Ed25519 key pair, run:
ssh-keygen -t ed25519 -C “your_email@example.com”
The -t flag specifies the key type, while -C adds a comment that helps identify the key later in authorized_keys files and SSH management tools.
When prompted for a file location, press Enter to accept the default path. You should also consider setting a passphrase. A passphrase encrypts the private key on disk, adding another layer of protection if the machine is compromised.
If you do not want to enter the passphrase every time you connect, use ssh-agent. It securely stores the decrypted key in memory for the duration of your session, allowing passwordless SSH access without repeated prompts.
Step 2: Copy Your Public Key to the Server
With a key pair generated, the public key needs to land on the remote server. The standard method is to use ssh-copy-id. It appends your public key to the server’s ~/.ssh/authorized_keys file and sets the correct file permissions.
Run ssh-copy-id followed by your username and the remote hostname or IP address. The command will prompt you for your password one time. After that, it installs the public key, and future logins will use the key instead.
If ssh-copy-id is unavailable (some minimal Linux distributions omit it), you can achieve the same result manually:
- On your local machine, read the contents of your public key file.
- On the remote server, ensure the ~/.ssh directory exists.
- Append the public key to ~/.ssh/authorized_keys.
Either way, verify that the server-side ~/.ssh/ directory has permissions 700 and authorized_keys has permissions 600. Incorrect permissions are the most common reason key-based login silently falls back to password prompts.
Step 3: Test the Connection
Before locking out passwords, confirm the key is working by opening a new SSH connection to the server. If you connect without a password prompt, the key pair is correctly installed. If you are still prompted for a password, check:
- That the public key is in ~/.ssh/authorized_keys on the server
- That file permissions are correct: 700 on .ssh/, 600 on authorized_keys
- That the OpenSSH server is configured to allow public key authentication: PubkeyAuthentication yes in sshd_config
Step 4: Disable Password Authentication in SSH
Once key-based login is confirmed, you can remove the password fallback entirely. This step closes off brute-force and credential-stuffing attacks at the server level.
- Open the SSH daemon configuration file (sshd_config) on the remote server, typically at /etc/ssh/sshd_config.
- Locate the PasswordAuthentication directive and set its value to no.
- If the line does not exist, add it.
- Save the file, then reload the SSH daemon using your system’s service manager (for example, systemctl reload sshd on systemd-based distributions).
Keep your current SSH session open while you test a new connection from a second terminal window. If the new connection succeeds without a password, the configuration is correct. Only close the original session once this is successful. Locking yourself out of a server with no password-reset path is a painful way to learn this lesson.
Ed25519 vs RSA: Choosing the Right Key Type
The two practical SSH key algorithms used for passwordless SSH authentication today are Ed25519 and RSA. Here’s a comparison of the two:
| Dimension | Ed25519 | RSA |
| Algorithm basis | Edwards-curve digital signature algorithm (EdDSA) | Integer factorization |
| Key size for ~128-bit security | 256 bits | 3,072 bits |
| Signature size | 64 bytes | 256+ bytes |
| Generation speed | Near-instant | Slow at 4,096 bits |
| Legacy compatibility | Requires OpenSSH 6.5+ (2014) | Broadly supported |
| NIST guidance | Acceptable | Minimum 2,048-bit modulus required |
For any system running a modern OS released in the last decade, Ed25519 is the better choice. Use RSA 4,096 only when you have documented compatibility requirements that rule out Ed25519.
SSH Without a Password at Scale: Managing Keys Across Fleets
Key-based SSH without a password is a significant improvement over relying on passwords. The operational problems appear at scale. When 50 engineers each have keys on 200 servers, you are tracking 10,000 key relationships. When an engineer leaves, every authorized_keys file they are in needs to be updated by hand, or by a script that itself becomes a single point of failure.
SSH certificate authentication solves this by replacing distributed key management with centralized trust:
- Rather than distributing individual public keys to each server, you configure servers to trust a certificate authority (CA).
- Any user who holds a certificate signed by that CA can authenticate, subject to whatever constraints the certificate carries.
- Centralized access management replaces server-by-server key distribution, so a single CA trust configuration covers all servers.
- Certificate-based revocation can be enforced via a key revocation list (KRL) without editing every authorized_keys file individually.
For a deeper look at how the protocol works, see our guide to SSH certificate authentication.
SSH certificates also carry metadata that static keys lack:
- A principal (the user or host identity)
- A validity period
- Optional usage constraints
A certificate that expires tomorrow cannot be used the day after. No revocation list is required.
This is the same pattern driving enterprise adoption of certificate-based authentication for 802.1X networks, where static pre-shared keys (PSKs) give way to per-device certificates issued by a managed public key infrastructure (PKI).
Extend SSH Passwordless Access With JoinNow Dynamic PKI
For teams operating at scale, passwordless SSH via key pairs is the starting point, but the architecture that makes certificate-based access manageable is a CA with automated issuance and short certificate lifetimes.
JoinNow Dynamic PKI issues SSH user and host certificates signed by a CA you control, with configurable validity windows and native integration with identity providers like Entra ID and Okta. When a user is offboarded, their access is revoked at the identity layer. No hunt-and-delete across authorized_keys files. JoinNow Cloud RADIUS extends the same certificate-based access model to Wi-Fi and VPN, giving your team a single authentication architecture across protocols rather than separate credential stores for each.
If your organization is ready to move beyond key sprawl, Dynamic PKI provides the managed CA infrastructure to do it without standing up on-premises servers.
Schedule a demo to see how certificate-based SSH fits into a broader passwordless access strategy.
Frequently Asked Questions
Is passwordless SSH actually more secure than password authentication?
Yes. Password logins expose a credential that can be guessed, phished, or intercepted. Public-key authentication works by requiring possession of a private key that never leaves the client machine. An attacker who captures the network traffic cannot replay or reuse what they see. A brute-force attack against an Ed25519 key would require breaking 128-bit security, which is computationally infeasible with current and near-future hardware.
What is the best key type for passwordless SSH?
Ed25519 is the current best practice for any system running OpenSSH 6.5 or newer, which covers virtually all Linux distributions and macOS versions released after 2014. It offers stronger security guarantees than RSA at a fraction of the key size and is significantly faster to generate and verify. Use RSA 4,096 bits only when you have legacy infrastructure that cannot be updated to support Ed25519.
Can I set up passwordless SSH for multiple servers?
Yes. Run ssh-copy-id user@server for each target server, or use a configuration management tool such as Ansible to distribute your public key in bulk. For 10 or more servers, consider SSH certificate authentication instead. You configure each server to trust your CA once, and any valid certificate works without server-by-server key distribution.
What happens if I lose my private key?
If the private key is gone, you cannot authenticate using that key pair. Remove the corresponding public key from every server’s authorized_keys file to prevent unauthorized use if the key was stolen rather than simply lost. Then generate a new key pair and redistribute the new public key. This manual cleanup process is one of the core arguments for SSH certificate-based authentication, where invalidating a single CA trust entry achieves the same result immediately.
Is it safe to disable password authentication entirely?
Yes, provided you have tested key-based login and have at least one working key installed before you change the sshd_config setting. Keep a session open while you test a second connection, so you can revert PasswordAuthentication no if something is misconfigured. If you are on a cloud instance, confirm that the provider offers an out-of-band console or recovery mechanism before proceeding.
