</>KemmerApp

Programming

Disable password authentication for SSH closed

25 September 2026 · 8 min read

Disable password authentication for SSH closed

In today’s interconnected digital landscape, securing remote access to servers is paramount. One of the most critical steps in hardening your server’s security posture is to disable password authentication for SSH. While passwords offer a basic layer of protection, they are inherently vulnerable to brute-force attacks, dictionary attacks, and human error. Transitioning from password-based logins to SSH key pair authentication provides a significantly more robust and secure method for server access, drastically reducing the risk of unauthorized entry.

This comprehensive guide will delve into why this security measure is essential, how SSH key authentication works, and provide step-by-step instructions to implement it effectively. By understanding and applying these principles, you can fortify your server against common cyber threats and ensure a more secure remote administration experience. We’ll explore the technical nuances and best practices to help you make this crucial security upgrade.

Why Disable Password Authentication for SSH?

Disabling password authentication for SSH is a fundamental security best practice that significantly enhances the protection of your servers. Passwords, even strong ones, are susceptible to various forms of attack. A common threat is the brute-force attack, where automated scripts attempt to guess login credentials repeatedly. Statistics show that many compromised servers initially fall victim to weak or guessed passwords, allowing attackers a foothold.

To significantly bolster server security and prevent unauthorized access, you should disable password authentication for SSH and switch to SSH key-based authentication. This method eliminates the primary vulnerability of brute-force attacks targeting passwords, as keys are far more complex and virtually impossible to guess. SSH key pairs consist of a private key, kept secret on your local machine, and a public key, which resides on the server. When you attempt to connect, the server challenges your client, which then proves its identity using the private key, without ever transmitting the key itself.

Beyond brute-force attacks, using SSH keys also mitigates risks associated with phishing, keyloggers, and human error in password management. A compromised password on one service could lead to a breach on another if reused. With SSH keys, each server can have a unique public key, and the private key never leaves your system, creating a far more secure chain of trust. This proactive approach to security hardening is a cornerstone of responsible server administration, especially for publicly accessible systems.

Understanding SSH Key Authentication

SSH key authentication operates on the principles of public-key cryptography, a robust method that relies on a pair of mathematically linked keys: a public key and a private key. When you generate an SSH key pair, the private key remains on your local machine, secured with a strong passphrase. The corresponding public key is then placed on the remote server you wish to access, specifically within the ~/.ssh/authorized_keys file of the user account you intend to log in as.

The authentication process works like this: when you attempt to connect to the server, your SSH client sends a request. The server, possessing your public key, generates a challenge encrypted with that public key. Your client then uses your private key to decrypt this challenge, proving that you possess the correct private key without ever transmitting it across the network. This ‘handshake’ ensures mutual authentication and establishes a secure, encrypted tunnel for communication. This method is vastly superior to traditional password authentication because the private key is never exposed, and its complexity makes it practically impervious to guessing or brute-forcing.

Furthermore, SSH keys can be protected with a passphrase, adding another layer of security. Even if your private key file is stolen, it remains useless without the passphrase. This multi-layered defense makes SSH key-based access the industry standard for secure remote server management. It’s a critical component for ensuring the integrity and confidentiality of your server communications and a key reason why many organizations choose to disable password authentication for SSH entirely.

Step-by-Step Guide to Disabling Password Authentication

Implementing SSH key authentication and disabling password authentication requires careful steps to ensure you don’t lock yourself out of your server. Always ensure you have a working SSH key setup and access before making changes to the SSH daemon configuration.

  1. **Generate SSH Key Pair (if you haven’t already):**On your local machine, open a terminal and run ssh-keygen -t rsa -b 4096. This command generates an RSA key pair with a 4096-bit length, which is highly secure. You’ll be prompted to save the key to a file (default is ~/.ssh/id_rsa) and to enter a passphrase. Always use a strong passphrase for your private key.

  2. **Copy Public Key to Server:**Use ssh-copy-id user@your_server_ip to securely copy your public key (id_rsa.pub) to the server’s ~/.ssh/authorized_keys file. You will need to enter the user’s password for the last time. If ssh-copy-id is not available, you can manually copy it using cat ~/.ssh/id_rsa.pub | ssh user@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys".

  3. **Test SSH Key Authentication:**Before proceeding, open a new terminal window and try to log in using your SSH key: ssh user@your_server_ip. If it prompts you for your key’s passphrase (and not the server password), your key authentication is working. Do NOT close the old terminal window until you confirm successful key login.

  4. **Edit SSH Daemon Configuration:**On the server, use a text editor like Nano or Vim to open the SSH daemon configuration file: sudo nano /etc/ssh/sshd_config. Locate the following lines and modify them:

    • PasswordAuthentication yes to PasswordAuthentication no
    • ChallengeResponseAuthentication yes to ChallengeResponseAuthentication no (This often goes hand-in-hand with password auth).
    • Ensure PubkeyAuthentication yes is uncommented and set to yes.
    • Ensure UsePAM yes is set to yes if you rely on PAM for other authentication methods, otherwise consider setting it to no if you strictly want key-only.

    A helpful resource for OpenSSH configuration can be found on the OpenSSH Official Documentation site.

  5. **Restart SSH Service:**After saving the changes to sshd_config, restart the SSH service to apply them. On most Linux systems, this is done with sudo systemctl restart sshd or sudo service ssh restart. Again, do not close your original working SSH Question & Answer :

    I'm looking for a way to disable SSH clients from accessing the password prompt as noted [here](https://help.ubuntu.com/community/SSH/OpenSSH/Configuring).

    I am unable to disable the password: prompt for root login. I have change the sshd_config file to read:

    ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no

    and have also changed the permissions chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. What am I missing? Does this require I have a passphrase?

    Verbose dump:

    debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/user/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Next authentication method: password

    File /etc/ssh/sshd_config:

    # Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication no # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM no

    In file /etc/ssh/sshd_config

    # Change to no to disable tunnelled clear text passwords #PasswordAuthentication no

    Uncomment the second line, and, if needed, change yes to no.

    Then run

    service ssh restart