FTP and SSH Enumeration for Pentesting (Ports 21, 22)
Introduction
Before exploiting a service, you need to know what it is, which version does the target runs, and how it is configured. This is Application enumeration
Application enumeration is the process of identifying and profiling services on open ports. It turns a simple "port 21 is open" into "FTP server X version Y, anonymous login allowed, is running on port 21 of target appliance" which directly shapes your next steps.
During a pentest, that profile creation decides whether you chase anonymous shares, weak auth, known CVEs, or simply document the exposure and move on. Our upcoming three-part network protocol blog series walks through practical port enumeration for common services, starting with FTP and SSH in this one.
What is FTP?
FTP (File Transfer Protocol) is a standard network protocol used to transfer files between a client and a server over a TCP/IP network, such as the internet. Operating at the application layer, FTP enables users and others to upload, download, manage, and edit website files, media assets, and large data backups reliably.
From the official RFC:
The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.
FTP functions using a dual-channel client-server architecture:
FTP Client: A software application (such as FileZilla or WinSCP) installed on your local computer used to navigate directories and trigger uploads or downloads.
FTP Server: A remote computer or hosting server configured to listen for incoming transfer requests and store directory files.
Control Channel (Command Port 21): Transmits administrative instructions, user authentication (USER, PASS), and directory commands.
Data Channel: Dedicated strictly to transferring file payloads and folder directory listings, toggled through either Active Mode or Passive Mode.
Penetration Testing Guide: Enumeration Workflow
Discover open ports (e.g. with Nmap).
Identify the application (banner, response patterns).
Determine version (banners, headers, default pages).
Probe safe, non-destructive checks (anonymous login, supported commands, SSL/TLS).
Document and pivot (credentials, misconfigurations, next targets).
The sections below apply this workflow to each protocol (in this and upcoming blogs).
FTP Enumeration (Port 21)
FTP (File Transfer Protocol) on port 21 is often misconfigured: default credentials, anonymous access, or outdated software. Our Typical FTP enumeration will focus on banner grabbing, supported commands, and anonymous login checks.
FTP Banner Grabbing and Version Detection
Connect and read the banner (first line the server sends):
nc -nv 192.168.1.10 21
Or use Nmap’s FTP scripts (version + default scripts):
nmap -p 21 -sV -sC 192.168.1.10
-sV gets the version; -sC runs safe default scripts (e.g. ftp-anon). Example banner:
220 (vsFTPd 3.0.3)
Note the product and version for CVE lookup later.
FTP Anonymous Login Check
Many penetration testing assessments still find ftp-anon allowed. Check manually:
ftp 192.168.1.10
# At prompt: username = anonymous, password = anonymous or empty
Or with Nmap:
nmap -p 21 --script ftp-anon 192.168.1.10
If anonymous is allowed, list directories and files (e.g. ls -la, dir), recurse into subdirs, and document any sensitive data; no password guessing needed. Note paths and filenames for your report; downloadable files (e.g. configs, backups) are high-value findings.
FTP Supported Commands (HELP and FEAT)
After logging in (anonymous or valid account), run:
HELP
or
FEAT
to see supported commands and extensions. This can reveal extra capabilities (e.g. AUTH TLS, PBSZ, PROT for encrypted transfer, or PASV for passive mode, relevant if the client is behind a firewall). Use this for scripting, fuzzing, or compliance (e.g. "FTP supports TLS").
FTP Enumeration Quick Reference
Goal | Tool / method |
|---|---|
Banner / version | nc -nv <ip> 21 or nmap -p 21 -sV |
Anonymous login | nmap --script ftp-anon or manual FTP |
Commands / FEAT | Interactive HELP / FEAT after login |
FTP Findings: Config Drift Versus Patch Exposure
Not every FTP finding carries the same weight in a pentest report, and mixing the two categories together makes the fix list harder for a client to prioritize.
Version risk is a service that maps cleanly to a public CVE, for example an old vsFTPd or ProFTPD build with a known remote code execution advisory; the fix here is a patch or upgrade, and severity should follow the CVSS score of the underlying advisory rather than your own guess.
Misconfiguration risk is different: anonymous access left enabled, a writable upload directory reachable by anonymous users, or plaintext FTP exposed on an untrusted network are all findings that exist regardless of patch level. A fully patched FTP server with anonymous write access is still a critical finding.
When you write up FTP results, you must separate the two explicitly: "vsFTPd 3.0.3, no known critical CVE at time of test" versus "anonymous login enabled with a writable /incoming directory, allowing an attacker to stage files for further pivoting." Clients will fix these differently, one through patch management and one through configuration change, so conflating them in a single bullet slows remediation.
What to Document for FTP Findings
A useful FTP enumeration entry in your notes, and later your report, needs more than "port 21 open." At minimum, capture the exact banner string (copy it, do not paraphrase), the Nmap command and timestamp used to obtain it, whether anonymous login succeeded and with which credentials, a directory listing if access was granted, and the output of FEAT or HELP if you reached an authenticated or anonymous session.
Redact anything sensitive before a listing goes into the report body, but keep the raw listing in your evidence folder. If you found downloadable files, note the filename, size, and a hash such as sha256sum rather than including the full file content inline; this keeps your report reviewable without turning it into a data dump.
Screenshots or terminal captures should show the command you ran directly above the output, so a reviewer can reproduce the step without guessing which flags were used.
Safe vs Unsafe FTP Probes
Banner grabbing, ftp-anon checks, and HELP/FEAT queries are all read-only and safe to run against a production FTP server without prior arrangement beyond your standard rules of engagement; they do not modify state and rarely trigger more than a log line on the target. Credential brute-forcing against FTP is a different risk class: repeated failed logins can lock accounts, trip fail2ban-style protections, or generate alerts that burn your stealth budget on a red team engagement.
If your scope allows password attacks, throttle them (a handful of attempts per minute, not thousands) and confirm with the client whether account lockout is a concern before you start. Uploading a file to a writable anonymous share to prove impact is usually fine in a pentest, but always use an inert marker file, document the exact path, and remove it before the engagement closes; never write into an application's live upload directory (until explicit permissions to do so) without first confirming what consumes those files downstream.
SSH Enumeration (Port 22)
SSH enumeration on port 22 aims at identifying server software and version, supported auth methods, and (if you have credentials) weak or default keys. Avoid brute-forcing; focus on banners and key auditing.
What is SSH?
To quote the official RFC:
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network.
SSH (Secure Shell) is a cryptographic network protocol used to securely access, manage, and execute commands on remote servers and network devices over an unsecured network. Operating at the application layer over TCP port 22, SSH replaces legacy, insecure protocols like Telnet and rlogin by encrypting all traffic, authentication credentials, and data exchanges.
SSH establishes a secure connection through three key phases:
Transport Layer Handshake: The client contacts the server on port 22. They verify host identity and use a key exchange algorithm (like Diffie-Hellman) to generate shared symmetric session keys for encrypting the session.
User Authentication: Once encrypted, the user authenticates via password or SSH Key Pairs (a public key stored on the server's authorized_keys file and a private key kept strictly on the local machine).
Encrypted Channel Multiplexing: After authentication, the connection opens logical channels to support terminal shell sessions, remote command execution, or tunneled traffic.
SSH Banner Grabbing and Version Detection
Grab the banner with netcat:
nc -nv 192.168.1.10 22
You’ll see something like:
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
Record the vendor and version (e.g. OpenSSH 8.2p1) and check for known vulnerabilities.
Nmap can do the same and run SSH scripts:
nmap -p 22 -sV -sC 192.168.1.10
Scripts may include ssh2-enum-algos (key exchange, ciphers, MACs) and ssh-auth-methods (password, publickey, etc.). Record weak algorithms (e.g. legacy ciphers or MACs) for compliance; auth methods tell you whether to focus on passwords, keys, or both.
SSH Authentication Methods Enumeration
To see which auth methods the server offers (without cracking):
nmap -p 22 --script ssh-auth-methods --script-args ssh-auth-methods.auth=root 192.168.1.10
Or connect with SSH in verbose mode and read the "Authentications that can continue" line:
ssh -v root@192.168.1.10
# (Cancel after the auth method list if you have no credentials)
Document whether password, publickey, or keyboard-interactive is allowed; this shapes credential and key attacks. You can pass different usernames to the Nmap script (for example --script-args ssh-auth-methods.auth=root), but treat the result as the methods the server advertises for that probe, not as proof that the account exists.
Modern OpenSSH returns the same authentication method list for valid and invalid users on purpose, so this script is not a reliable user-existence oracle. Some non-OpenSSH daemons historically differed by username; if you see that behavior, note it as a server-specific finding rather than assuming OpenSSH leaked the account.
SSH Key and Config Auditing (Post-Access)
If you obtain shell access (e.g. via another finding), check:
Authorized keys: Enumerate ~/.ssh/authorized_keys for weak or shared keys.
Server config: Check PermitRootLogin, PasswordAuthentication, AllowUsers in /etc/ssh/sshd_config.
These are configuration-enumeration steps, not remote exploits, but they’re essential for reporting and privilege escalation paths.
SSH Findings: Config Drift Versus Patch Exposure
SSH follows the same split as FTP. Version-based findings come from an OpenSSH build that maps to a specific advisory.
CVE-2024-6387 (regreSSHion) is a signal-handler race in sshd on glibc-based Linux that can lead to unauthenticated remote code execution under the right timing conditions; it is not a one-shot exploit from a banner alone. The modern regression affects portable OpenSSH 8.5p1 through 9.7p1 (fixed in 9.8p1). Versions 4.4p1 through 8.4p1 are not affected by this regression, and very old builds before 4.4p1 may still be exposed to the earlier signal-handler issue unless already patched.
Document the exact banner string, then check the distribution advisory: vendors often backport fixes while the displayed OpenSSH version string stays in the 8.5–9.7 range, so "banner says 9.2p1" is a lead, not a confirmed exploit condition.
Misconfiguration findings are independent of patch level: PermitRootLogin yes, password authentication left enabled where key-only access was expected, weak key-exchange algorithms or MACs still negotiated, or a banner that leaks internal hostnames and environment details.
A fully patched SSH server that still allows root to authenticate directly with a password is a legitimate finding on its own. Keep these two categories separate in your notes so the client's infrastructure team and application team can each act on the part that is theirs to fix.
What to Document for SSH Findings
Record the full banner string (vendor and version), the output of ssh2-enum-algos (key exchange, host key, cipher, and MAC lists), and the result of the auth-methods probe, including which methods the server offered and to which usernames if you tested more than one. If you later gain shell access through another finding, note the contents of sshd_config that matter for security review: PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, AllowUsers or AllowGroups, and MaxAuthTries.
For authorized_keys review, record the key type and comment field (often a username or hostname) rather than the full public key blob; the comment alone is usually enough to flag a shared or default key without bloating the report.
Where you found weak algorithms still enabled, quote the exact algorithm name from the Nmap script output so the client can grep their configuration for it directly.
Safe vs Unsafe SSH Probes
Grabbing the banner, running ssh2-enum-algos, and checking supported authentication methods are safe, low-noise checks that any SSH daemon expects to see routinely from scanners and monitoring tools. They do not attempt authentication and will not (typically) lock an account. Probing auth methods with ssh-auth-methods is still safe because it only asks which methods the server advertises; it never submits a password or key, and (on modern OpenSSH) it does not confirm whether the username exists.
Where SSH probing turns unsafe is credential spraying and key brute-forcing: SSH is a common brute-force target, and many hosts run fail2ban or similar tooling that will ban your source IP after a handful of failures, potentially taking out other testers on the same engagement if you share an attack box.
If password or key guessing is in scope, agree on a rate limit with the client, use a short, curated list rather than a full dictionary, and stop immediately if you see connection resets or throttling that suggests a defensive control has engaged.
SSH Enumeration Quick Reference
Goal | Tool / method |
|---|---|
Banner / version | nc -nv <ip> 22 or nmap -p 22 -sV |
Auth methods | nmap --script ssh-auth-methods or ssh -v |
Algorithms | nmap --script ssh2-enum-algos |
Summary: FTP and SSH Enumeration for Pentesting
FTP and SSH are two of the first services you will see on internal and external penetration tests. For FTP enumeration, always check the banner and anonymous access; for SSH enumeration, always record the version and supported auth and algorithms. Part 2 covers HTTP (80) and HTTPS (443): web server banners, directories, and TLS. Part 3 covers SMTP, POP3, IMAP, and SNMP.
Keep enumeration consistent and documented; the same workflow scales to the rest of the ports in this series.
References
Register for instructor-led online courses today! https://www.darkrelay.com/courses
Check out our self-paced learning paths! https://www.darkrelay.com/learning-paths
Explore our bundled Pricing & Plans for cost-effective options! Buy a course subscription to learn more—hands-on labs and expert-led training included. https://www.darkrelay.com/plans-pricing
Contact us for custom pentesting needs at: info@darkrelay.com or WhatsApp.
Comments