Skip to content
HackIndex.io

SSH Authentication Method Enumeration

4 min read Created Jan 3, 2026 Last updated Jan 4, 2026

Identify which authentication methods the server will accept so you do not waste time on dead paths.

What you are validating

This is not about trying passwords. It is about confirming what the server is willing to do for a user context.

Common pivots:

  • publickey-only means you switch to key hunting and config mistakes

  • keyboard-interactive often means PAM controls, MFA, or policy gates

  • GSSAPI hints at domain integration and different attack angles

  • password enabled means credential attacks are at least technically possible, subject to rules of engagement

Auth methods can vary by user depending on server config. Testing root vs a normal username can produce different results.

If the server returns only publickey, stop credential spray planning immediately. Move to authorized_keys abuse, config misreads, and service account key exposure instead. A server listing gssapi-with-mic alongside publickey strongly suggests Kerberos integration. That opens AD-based attack paths: Kerberoasting, ticket forwarding, and service account targeting.

When password is listed, verify your rules of engagement before spraying. The server accepts the method, but rate limiting, lockout policy, or fail2ban may still be active. Slow and targeted guessing is safer than a full wordlist run.

Probing SSH Supported Auth Methods with Nmap

This gives you a clean list of methods for a specific username. Nmap sends an authentication request for that user and reports back what the server offers. Run it against multiple usernames if you have a list. Root, admin, and common service accounts often have different policies applied. A user that returns only publickey while others return password is worth noting. It may indicate a privileged account with tighter sshd-level controls.

┌──(kali㉿kali)-[~]
└─$ nmap -p $PORT --script ssh-auth-methods --script-args "ssh.user=$USERNAME" $TARGET_IP 
22/tcp open  ssh     syn-ack
22/tcp open  ssh     syn-ack
| ssh-auth-methods:
|   Supported authentication methods:
|     publickey
|     password
|   Banner: This is a private system. Use of this system constitutes
|_consent to monitoring.

Expect this to be logged on the server. It is still enumeration, but it is not silent. On heavily monitored systems, multiple auth probe attempts for a single user may trigger an alert. Stick to one run per user rather than looping.

Confirm server offers via verbose SSH without prompting

This keeps the session non-interactive while still showing the authentications-that-can-continue line in the debug output. BatchMode=yes prevents interactive prompts from halting execution. The StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null flags suppress host key warnings that would otherwise pollute the output. The exit at the end terminates cleanly even if auth somehow succeeds.

The server returns the method list right after your client presents the username. If that line does not appear, the server rejected the connection outright. Another possibility is the username does not exist on the target.

┌──(kali㉿kali)-[~]
└─$ ssh -vvv -p $PORT -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $USERNAME@$TARGET_IP exit 
debug1: Authentications that can continue: publickey,password,keyboard-interactive

If you want the server to advertise methods without your client trying anything meaningful, forcing none as the preferred authentication method is a useful trick. Some servers reject the none method before advertising their full list. Others return the list first and then reject the client. The debug output shows which case applies to your target:

┌──(kali㉿kali)-[~]
└─$ ssh -vvv -p $PORT -o PreferredAuthentications=none -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $USERNAME@$TARGET_IP exit

That usually fails immediately, but it often prints the list you care about in the debug lines. Compare the result against what Nmap reported. Discrepancies suggest per-method filtering between sshd and a PAM module. If the lists differ, PAM may be blocking certain methods for specific users even though sshd advertises them. Record both results separately.

Once you have the confirmed method list, prioritize your next steps accordingly. Password and keyboard-interactive together means credential testing is viable. GSSAPI alone means you pivot to ticket-based approaches. Publickey-only means the credential attack surface is zero. Look for private keys on disk, in memory dumps, or in config backups instead.

References