SSH Enumeration and Access on Metasploitable 2

After successfully exploiting the VSFTPD 2.3.4 service and obtaining remote access to the target, I continued enumerating additional services exposed by the system. One of the identified services was Secure Shell (SSH), which was running on TCP port 22.

The objective of this phase was to analyze the SSH service, understand its configuration, establish connectivity from a modern Kali Linux system, and authenticate using valid credentials.

SSH (Secure Shell) is a cryptographic network protocol used to securely access and manage remote systems.

SSH provides:

• Encrypted communication
• Secure remote administration
• Secure file transfers
• Authentication mechanisms
• Port forwarding and tunneling

Because of these capabilities, SSH is one of the most widely deployed remote administration protocols in Linux environments.

Step 1: Service Enumeration

During reconnaissance, the SSH service was identified on TCP port 22.

A version detection scan revealed:

The output can be broken down into several components.

1. Port 22 is the default SSH port
2. Service state is open.
3. Software version "OpenSSH 4.7p1".

The identified version:

OpenSSH 4.7p1

OpenSSH 4.7p1

was released around 2008.

This means the service is extremely old by modern standards.

Security Concerns Associated with Older SSH Versions

Older OpenSSH deployments often suffer from:

1. Weak Cryptographic Algorithms

Support for legacy algorithms such as:

ssh-rsa
ssh-dss

ssh-rsa
ssh-dss

which are no longer recommended.

2. Deprecated Key Exchange Methods

Older systems may support cryptographic methods that are no longer considered secure.

3. Outdated Security Defaults

Modern OpenSSH versions disable numerous legacy algorithms by default.

Older installations typically continue supporting them for compatibility reasons.

Step 2: Initial Connection Attempt

The first connection attempt was performed using:

ssh msfadmin@10.0.2.3

ssh msfadmin@10.0.2.3

The connection failed with:

Unable to negotiate with 10.0.2.3 port 22:
no matching host key type found.

Unable to negotiate with 10.0.2.3 port 22:
no matching host key type found.

Why the Connection Failed

This error did not indicate that SSH was unavailable.

Instead, it revealed a cryptographic compatibility issue. The target server offered only: ssh-rsa ssh-dss host key algorithms.

Modern OpenSSH clients disable many legacy algorithms by default because they are considered weak or obsolete.

As a result, the client refused to negotiate a connection.

Step 3: Establishing Compatibility

To communicate with the legacy SSH server, additional options were supplied:

ssh \
-o HostKeyAlgorithms=+ssh-rsa \
-o PubkeyAcceptedAlgorithms=+ssh-rsa \
username@ip-address

ssh \
-o HostKeyAlgorithms=+ssh-rsa \
-o PubkeyAcceptedAlgorithms=+ssh-rsa \
username@ip-address

Command Breakdown

ssh

Launches the SSH client and initiates a secure remote connection.

-o

Allows custom SSH configuration options to be specified for a single connection.

HostKeyAlgorithms=+ssh-rsa

Temporarily enables the legacy ssh-rsa host key algorithm.

This option was required because the target server was running an older version of OpenSSH that only supported deprecated cryptographic algorithms.

Without this option, the client returned:

Unable to negotiate with 10.0.2.3 port 22:
no matching host key type found

Unable to negotiate with 10.0.2.3 port 22:
no matching host key type found

PubkeyAcceptedAlgorithms=+ssh-rsa

Allows the client to accept older RSA-based authentication methods that are disabled by default in modern OpenSSH releases.

Why These Options Were Necessary

The target was running:

OpenSSH 4.7p1

OpenSSH 4.7p1

which is a legacy SSH implementation released around 2008.

Modern versions of OpenSSH disable several older algorithms, including ssh-rsa and ssh-dss, due to security concerns and the deprecation of SHA-1-based cryptography.

As a result, the SSH client and server were initially unable to agree on a supported cryptographic algorithm, causing the connection to fail.

The additional options temporarily re-enabled compatibility, allowing communication with the legacy SSH service.

Step 4: Authentication

Valid credentials were obtained from the Metasploitable 2 project documentation maintained by Rapid7.

link: https://docs.rapid7.com/metasploit/metasploitable-2-exploitability-guide/

Why SSH Matters During Penetration Testing

SSH is rarely the initial attack vector.

Instead, it often becomes valuable after obtaining credentials through:

• FTP compromise
• Database compromise
• Password cracking
• Credential reuse
• Configuration file disclosure

A penetration tester frequently uses SSH to:

• Maintain access
• Perform enumeration
• Transfer files
• Execute commands
• Conduct privilege escalation

SSH therefore serves as both an administrative tool and a post-exploitation asset.

Key Takeaway

No SSH vulnerability was exploited during this phase.

Authentication was performed using valid credentials obtained from the official Metasploitable 2 documentation.

The purpose of this step was to understand:

• SSH service enumeration
• Legacy OpenSSH behavior
• Cryptographic compatibility issues
• Authenticated remote access

rather than exploiting a vulnerability in the SSH service itself.

Conclusion

Enumeration identified an OpenSSH 4.7p1 service running on TCP port 22. Initial connection attempts failed because the server supported only legacy cryptographic algorithms that modern SSH clients reject by default.

By explicitly enabling compatibility options and authenticating with valid credentials, remote shell access was successfully obtained. This exercise highlights the importance of understanding protocol negotiation, cryptographic compatibility, and credential management when assessing legacy systems.