Use SSH passwords, keys and forwarding-capable access
Needs: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission
Validate one known identity
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
# Variant — private key
chmod 600 KEY
ssh -v -i KEY -p PORT USER@TARGET
# Variant — discover methods for a known username
nmap -p PORT --script ssh-auth-methods --script-args "ssh.user=USER" TARGET
# Variant — non-interactive key check
ssh -o BatchMode=yes -o ConnectTimeout=5 -i KEY -p PORT USER@TARGET 'id'
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.
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.
This starts an authentication exchange and is logged; Nmap classifies it as intrusive. Use it only when the supported methods change the next decision.
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 deniedproves 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.
Verify → Run hostname and id in the resulting context; retain whether a shell, SFTP or only forwarding was actually granted.
If it fails → Permission denied may be username, key, passphrase, policy or method mismatch. A successful banner exchange proves none of these. More detail ↓
Explanation & examples
Use SSH passwords, keys and forwarding-capable access
- USE WHEN
- An SSH service and a known password, private key or agent context
- STARTING ACCESS
- A confirmed reachable application; anonymous context or one identified credential
- RESULT
- An authenticated shell, subsystem or forwarding capability with verified identity
Recognize the clue
Find SSH in service discovery, then trace a candidate password/key back to its recorded user before a bounded authentication attempt.
ssh -v -p PORT USER@TARGET
ssh -v -i KEY -p PORT USER@TARGET
Authenticated to TARGET using publickey
uid=USER_ID(USER) gid=GROUP_ID(GROUP)Means: Accepted key authentication plus a verified shell identity establishes that specific login, not root or unrestricted forwarding.
Confirm: Check actual account/shell/subsystem and separately inspect forwarding policy if a tunnel is needed.
- After validation
- The intended user can run commands: establish host/privilege/network state.
- Ruled out in this context
- The same valid key is not authorized for this user: rule out that username/key pairing.
- Still inconclusive
- A passphrase prompt or host policy rejection requires key/context diagnosis; it is not evidence that all SSH access is unavailable.
Troubleshooting: Permission denied may be username, key, passphrase, policy or method mismatch. A successful banner exchange proves none of these.
Recognize: SSH commonly uses TCP/22. Prerequisite for access: an accepted authentication method plus a permitted account/session context.
Baseline: validate one known identity
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
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
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
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 deniedproves 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.
Why it works
SSH authentication can succeed while shell access is restricted. Key ownership, passphrase and server authorization matter independently; forwarding is a separately controlled feature.
Worked example · hypothetical
Observation: a disclosed private key names a local user. Test: inspect the key and authenticate to that user. Illustrative output: a shell returns with a non-root UID. Interpretation: establish Linux state and inspect allowed forwarding.
New identity, privilege, host or route? Re-enumerate → All topic tasks →