Skip to content
HackIndex logo

HackIndex

SSH Weak Authentication Configuration

3 min read Mar 16, 2026

Weak SSH authentication configuration does not require exploiting a CVE. It means the server is configured in a way that makes credential attacks easier, allows access vectors that should be disabled, or accepts keys without passphrase protection. These are misconfigurations with direct exploitation paths.

Check Authentication Methods Permitted

Connect and observe what the server offers before authentication completes:

┌──(kali㉿kali)-[~]
└─$ ssh -v $USER@$TARGET_IP 2>&1 | grep -i "authentications that can continue\|server accepts" 
debug1: Authentications that can continue: publickey,password,keyboard-interactive

password in this list means password authentication is enabled. keyboard-interactive is often a wrapper for password auth. publickey alone is the most secure configuration.

Run the dedicated NSE script for a structured view:

┌──(kali㉿kali)-[~]
└─$ nmap -p $PORT --script ssh-auth-methods --script-args="ssh.user=$USER" $TARGET_IP

PermitRootLogin

Direct root login over SSH means any successful credential attack immediately yields full system access. The safest setting is prohibit-password or no. yes or without-password with a weak or exposed key is critical.

Test directly:

┌──(kali㉿kali)-[~]
└─$ ssh -o BatchMode=yes root@$TARGET_IP 2>&1 | grep -i "permission\|publickey\|password"

If the server presents a password prompt for root rather than immediately rejecting the connection, PermitRootLogin yes is likely active. A Permission denied (publickey) response means root login is restricted to key authentication only.

If you have read access to the sshd config after gaining a shell:

┌──(kali㉿kali)-[~]
└─$ grep -i "PermitRootLogin\|PasswordAuthentication\|PubkeyAuthentication\|AuthorizedKeysFile" /etc/ssh/sshd_config

PasswordAuthentication Enabled

Password authentication enabled on an internet-facing SSH service is a brute-force target. Combined with no account lockout policy it allows unlimited attempts.

Confirm it is enabled:

┌──(kali㉿kali)-[~]
└─$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no $USER@$TARGET_IP 2>&1 | head -3

A password prompt confirms password authentication is accepted. A Permission denied (publickey) rejection means password auth is disabled server-side.

When password auth is confirmed, credential attacks are viable. See SSH Password Credential Attacks.

Empty Passphrase Private Keys

Private keys without a passphrase provide no additional protection beyond file access. If a key file is world-readable or accessible to a compromised user, it can be used immediately without any cracking.

Check for key files accessible on the current host and whether they have passphrases:

┌──(kali㉿kali)-[~]
└─$ find /home /root /etc -name "id_rsa" -o -name "id_ed25519" -o -name "id_ecdsa" -o -name "*.pem" 2>/dev/null

Test whether a key has a passphrase:

┌──(kali㉿kali)-[~]
└─$ ssh-keygen -y -f /path/to/key

If the command outputs the public key without prompting for a passphrase, the key has no passphrase protection. A passphrase-protected key prompts before outputting.

Empty passphrase keys that are also listed in an authorized_keys file on another host create a direct lateral movement path. See SSH Lateral Movement with Harvested Keys.

MaxAuthTries and Failed Login Visibility

A MaxAuthTries value of 6 or higher combined with password authentication allows cycling through multiple passwords per connection before being disconnected. The default is 6.

Check from the verbose connection output:

┌──(kali㉿kali)-[~]
└─$ ssh -v $USER@$TARGET_IP 2>&1 | grep -i "maxauthtries\|attempts"

Or read from the config if you have shell access:

┌──(kali㉿kali)-[~]
└─$ grep -i "MaxAuthTries\|MaxSessions\|LoginGraceTime" /etc/ssh/sshd_config

AllowUsers and DenyUsers Absence

Without AllowUsers or DenyUsers restrictions, every system account with a valid shell can attempt SSH login. Service accounts, legacy users, and default accounts all become part of the attack surface.

┌──(kali㉿kali)-[~]
└─$ grep -i "AllowUsers\|DenyUsers\|AllowGroups\|DenyGroups" /etc/ssh/sshd_config

No output means no account restrictions are configured and all valid accounts are loginable over SSH.

References