# SSH Weak Authentication Configuration

- **URL:** https://hackindex.io/services/ssh/vulnerability-discovery/ssh-weak-authentication-configuration
- **Path:** SSH > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/ssh/vulnerability-discovery.md)
- **Published:** 2026-03-16
- **Updated:** 2026-03-16

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.

## Identifying SSH Weak Authentication Config

Connect and observe what the server offers before authentication completes:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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](https://hackindex.io/services/ssh/exploitation/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:

```bash
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:

```bash
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](https://hackindex.io/services/ssh/lateral-movement/ssh-lateral-movement-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:

```bash
ssh -v $USER@$TARGET_IP 2>&1 | grep -i "maxauthtries\|attempts"
```

Or read from the config if you have shell access:

```bash
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.

```bash
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.

Weak authentication indicators to document:

- `PasswordAuthentication yes` on internet-facing services
- `PermitRootLogin yes` allowing direct root access
- No `AllowUsers`/`DenyUsers` restrictions
- Private keys without passphrase protection
- High `MaxAuthTries` with no fail2ban or lockout

## References

- [ssh-auth-methods NSE Script](https://nmap.org/nsedoc/scripts/ssh-auth-methods.html) - Enumerates authentication methods accepted by an SSH server for a given username
- [sshd_config(5): OpenBSD manual page](https://man.openbsd.org/sshd_config.5) - Full reference for all sshd configuration directives including authentication settings