SSH Enumeration and Access Validation

← Stage index · Cheatsheet | Strategy map | Study methods: Extract opportunities from services

Recognize: SSH commonly uses TCP/22. Prerequisite for access: an accepted authentication method plus a permitted account/session context.

Baseline: validate one known identity

ssh -v -p PORT USER@TARGET

Decisive output: the debug trace separates connection, host-key negotiation, offered authentication methods and account acceptance. A shell prompt establishes session access as that identity.

Variant — private key

chmod 600 KEY
ssh -v -i KEY -p PORT USER@TARGET

The key must correspond to an authorized public key for that account. Permission denied (publickey) can mean wrong user, wrong key, server policy or account restrictions.

Variant — discover methods for a known username

nmap -p PORT --script ssh-auth-methods --script-args "ssh.user=USER" TARGET

This starts an authentication exchange and is logged; Nmap classifies it as intrusive. Use it only when the supported methods change the next decision.

Variant — non-interactive key check

ssh -o BatchMode=yes -o ConnectTimeout=5 -i KEY -p PORT USER@TARGET 'id'

Batch mode will not prompt for passwords or key passphrases. It is useful only when the key is already usable non-interactively.

Failure cues: timeout suggests route/filtering/service issues; refusal means no accepting listener in that context; host-key failure occurs before user authentication; Permission denied proves that the attempted method/context failed, not that every credential is invalid. A valid account may still have no shell or be restricted by server policy.

Next action: after a shell, verify whoami, groups, hostname and addresses, then re-enumerate locally. Password spraying and key-passphrase cracking belong to the credential-attack block, not this procedure.