| Service | Port | Notes |
|---|---|---|
| OpenSSH | 22/tcp | Version 4.7p1, outdated build bundled with the base image |
Why It Exists
SSH itself is a secure protocol, but any specific server build can carry its own bugs, weak default configuration, or simply be old enough that it signals a system nobody has maintained in years. OpenSSH 4.7p1 dates to late 2007 — ancient by patch-cycle standards, and left in place deliberately so it stands out clearly during enumeration.
How It's Identified
A version-detection scan reads the SSH banner exchanged during connection setup, which reports the server software and version before any authentication happens:
nmap -sV -p 22 192.168.56.101
Returns "OpenSSH 4.7p1" directly in the scan output, requiring no login attempt at all.
From there, the more realistic path forward on this specific box isn't a protocol-level exploit against SSH itself — it's testing the documented default accounts that also work over SSH, the same way they work at the console.
The Lesson
Exposing version information isn't a vulnerability by itself, but it changes an attacker's cost: an outdated, identifiable version narrows down exactly what to research next. Just as important here is the broader lesson that a hardened protocol doesn't protect weak credentials sitting behind it — SSH being "secure" says nothing about whether the accounts reachable through it are.
How Defenders Mitigate It
Keep SSH server software current, disable password authentication in favor of key-based login, rate-limit or lock out repeated failed logins, and restrict which networks or IP ranges can reach the SSH port at all. None of that matters, though, if default or weak passwords are never rotated — credential hygiene and software patching are separate controls that both have to hold.
Only interact with this service inside your own isolated Metasploitable 2 lab. Testing it against a system you don't own or have written permission to test is illegal in most jurisdictions.
Related: the Telnet page for a contrasting cleartext-protocol lesson, and default credentials for the account list that matters more here than the SSH version itself.
FAQ
Is SSH inherently less safe than other remote-access protocols?
No — it's one of the more secure options available. The issue on Metasploitable 2 is the specific outdated build, not the protocol itself.
Does an old SSH version always mean it's exploitable?
Not necessarily. It's a strong signal to investigate further, not proof of an exploitable flaw on its own.
What OpenSSH version does Metasploitable 2 run?
OpenSSH 4.7p1, running on the Protocol 2 stack. It's old enough to be a clear version-fingerprinting exercise, but the more practical weakness on this specific box is the account credentials, not an unpatched SSH flaw.
Can SSH on Metasploitable 2 be brute-forced?
Yes, because the documented default accounts (such as msfadmin) use weak, published passwords. This is a credential-strength issue, not a flaw in the SSH protocol or server.