nmap -sV -p 22 target
nmap -sV -sC --script=banner -p 22 target
nc -zv target 22
nmap -sV to identify the exact service and versionsearchsploit ssh to find known exploitsSSH (Secure Shell) on port 22 is the encrypted remote-access protocol that has replaced Telnet for almost all modern Unix-like systems. It provides authenticated, encrypted command-line access plus file transfer (SCP/SFTP), tunnelling (port forwarding), and X11 forwarding. SSH is the most common remote-management surface on Linux servers, network devices, and embedded systems — which makes it one of the most-attacked ports on the public internet.
The standard SSH attack pattern is credential brute force: automated bots constantly scan port 22 across the internet, attempting common username/password combinations against any responsive SSH server. A second attack class is SSH key compromise — stealing private keys from compromised laptops or backup systems and using them to access servers that trust the corresponding public key. The third class is SSH protocol vulnerabilities — historically rare but high-impact when they occur (CVE-2024-6387 "regreSSHion" affected most OpenSSH versions in 2024).
For defenders, the SSH hardening checklist is well-established: PermitRootLogin no, PasswordAuthentication no (use key auth only), AllowUsers or AllowGroups to restrict by user, source-IP allowlists via firewall (or behind VPN/jumphost for high-security environments), fail2ban or equivalent to throttle brute-force attempts, and aggressive log monitoring. For high-value targets, also consider 2FA via PAM (TOTP), certificate-based SSH instead of raw keys, and bastion-host access patterns.
When SSH is in pentest scope, the standard sequence: nmap version detection on port 22 to identify the SSH server (nmap -sV -p 22 target), then targeted brute force using hydra or medusa with role-relevant wordlists (admin/admin, root/toor, common service accounts). For sites with weak defaults, this produces shells in minutes; for hardened sites with key-only auth, the brute force returns nothing and you move to other vectors.
After initial compromise on one Linux host, the standard red-team move is checking ~/.ssh/ for private keys, then trying those keys against other internal hosts. SSH keys often grant access to many servers (sysadmin keys especially), making them the highest-leverage credential to steal. Catch this with SSH key rotation policies and monitoring for unusual SSH connections from compromised hosts.
Many organisations run SSH on non-standard ports (2222, 22222, 50022) thinking it provides security through obscurity. It does not — masscan or a full nmap port range scan finds them in minutes. Scope-permitting, finding unexpected SSH on internet-facing IPs is sometimes a valid finding, especially when paired with weak credentials or known SSH server vulnerabilities.
During incident response, SSH logs (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL) are the first place to check for unauthorised access. Look for: successful logins from unusual IPs, unusual usernames, brute-force attempts that suddenly stopped (suggesting the attacker found valid credentials), and connections from IPs in known threat-intel feeds.
CTF challenges frequently feature SSH services as initial access vectors. Common patterns: weak credentials in challenge VMs (root/root, ctf/ctf), SSH server vulnerabilities (vulnerable older OpenSSH versions), or pivoting through SSH after gaining initial low-privilege shell elsewhere. The encyclopedia's standard scan commands are usually the right starting point for these challenges.
Default OpenSSH configuration plus internet exposure plus password authentication plus no rate limiting equals constant brute-force probing. Most automated bots will eventually find a weak password. Switching to key-only auth makes this attack class extinct on your server.
Moving SSH from 22 to 22222 reduces opportunistic scanner noise but does not stop targeted attacks. Modern scanners (masscan, RustScan) check all 65535 ports in seconds. Port change is operational hygiene (cleaner logs, less brute-force noise); it is not security.
Each team member should have their own SSH key pair. Shared private keys mean you cannot revoke access for one person without invalidating everyone. They also leave no audit trail for who actually connected. The pattern is: each person generates their own key, you add their public key to authorized_keys, and you remove just their public key when they leave.
A passphrase-less private key is plaintext access to your servers if the key file is stolen. Always generate keys with passphrases (ssh-keygen -t ed25519 prompts for one), and use ssh-agent to avoid typing the passphrase repeatedly. The convenience trade-off is small; the security improvement is significant if your laptop is ever compromised.
Successful brute-force is preceded by thousands of failed attempts. Monitoring auth logs and alerting on unusual failure patterns (sudden spike, unusual source IPs, valid usernames being targeted) catches attacks-in-progress before they succeed. fail2ban handles automated blocking; your SIEM should handle correlation and alerting for sophisticated patterns.
Most production environments only need SSH access from specific source IPs (admin VPN, jumphost, office network, on-call team). Restricting SSH to those source IPs at the firewall level eliminates almost all attack surface. If your access pattern is "from anywhere on the internet", consider whether VPN access would actually serve you better than open SSH.
ssh-keygen -t ed25519 -C "your-email@example.com" on your local machine. This creates a key pair: a private key (default ~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub). Set a passphrase when prompted. Copy the public key to the server's ~/.ssh/authorized_keys file (or use ssh-copy-id user@server which automates this).-L) makes a remote service accessible on your local machine. Remote forwarding (-R) makes a local service accessible on the remote machine. Dynamic forwarding (-D) creates a SOCKS proxy. Useful for accessing internal services from outside the network without setting up VPN, but easy to misuse — administrators sometimes disable forwarding (AllowTcpForwarding no) to prevent abuse.ListenAddress :: in sshd_config (or specific IPv6 addresses) to listen on IPv6. Connect with ssh user@[ipv6-address]. IPv6 addresses are larger and harder to scan exhaustively than IPv4, but this is not security — targeted attackers find services through DNS, leaks, and other discovery methods.Banner /path/to/file in sshd_config. Some organisations include legal "authorised users only" warnings in the banner for compliance/legal purposes, though their actual deterrent value is debatable.nc target 22 or ssh -V target — the SSH server announces its version in the banner exchange. nmap -sV -p 22 target does this automatically. Knowing the version matters because specific versions have specific known CVEs — particularly important for high-impact issues like CVE-2024-6387 (regreSSHion) which affected most OpenSSH versions for years.