SSH Credential Reuse — From Low-Priv User to Root

Not every privilege escalation needs a kernel exploit or a misconfigured capability. Sometimes it just needs you to try the password you already have one more time, against a different account.

I ran into this exact pattern twice across separate lab exercises, and both times the fix was identical: whatever credential got me in the front door also opened the root account round the back.

The Setup

Both boxes started the same way — I landed an SSH session as a standard, non-root user after either brute-forcing, guessing, or otherwise obtaining that user’s password during the initial foothold. Nothing unusual about the access itself: a normal shell, no sudo rights, no interesting SUID binaries lying around waiting to be abused.

On the first box, I was logged in as john on a host called funbox8. On the second, the story played out again on a host called sea, this time logged in as nicolas — different hostname, different user, same root cause.

Enumeration — Why Try the Same Password Twice

Password reuse is one of the most consistently underestimated weaknesses in real environments, and lab machines love to model it because it’s so common in the wild. The logic is simple: if an administrator set up a box and reused a password across a personal account and the root account — or if a low-privilege account’s password was originally provisioned from the same source as root’s — then the credential that got you SSH access as a normal user is also worth trying directly against root.

This costs nothing to test and doesn’t require any tooling:

su root

If the account you’re already logged in as shares a password with root, this succeeds immediately — no exploit, no CVE, no chained misconfiguration. Just credential hygiene that wasn’t there.

Exploitation

On the funbox8 box, after landing as john, I simply tried his own SSH password against su root:

john@funbox8:~/.todo$ su root
Password:

It worked on the first try. The same password that authenticated john over SSH was also root’s password on that box.

The second lab followed the identical pattern on a box called sea. After landing as nicolas, a look through a CMS configuration file (database.php, for a SeaCMS install) turned up hardcoded credentials sitting in plain text:

$hidden_creds = [
  'ssh_user' => 'nicolas',
  'ssh_password' => 'ImGonnaBeSuperhero594'
];

The same password nicolas was already using over SSH was sitting right there in the config file — and it worked directly against root too:

nicolas@sea:/tmp$ su root
Password:

Same result as the first box: a single su root call, no exploit required — just a password that had already been used, and reused, more than once. In both cases, the escalation step was a single command; the only real “exploitation” was recognizing that the credential was worth testing again in a different context.

Why This Works

There’s no technical vulnerability being abused here — this is pure credential hygiene failure, and it shows up in a few recognizable shapes:

• Shared provisioning: an admin sets up the box and root using the same password vault entry or the same “default” password pattern, then creates user accounts from the same source without rotating it
• Convenience over security: on personal or lab boxes, it’s common to set one password and reuse it everywhere to avoid juggling credentials
• Copy-paste account creation: a new user is created by cloning an existing account’s configuration, including a shared or templated password

Because SSH authentication and local su/root authentication both ultimately check the same thing — a password against /etc/shadow — any password reuse between an SSH-facing account and root collapses the privilege boundary entirely. There’s no separate “SSH password” and “root password” on the system; there’s just whatever hash sits in /etc/shadow for each user, and if those hashes were generated from the same plaintext, the boundary was never really there.

Root Cause

The underlying issue is password reuse across privilege levels — a low-privilege, remotely-accessible account (SSH) shares a credential with the highest-privilege local account (root). This turns any remote account compromise into an immediate root compromise, removing the entire point of having separate privilege tiers.

Fix: Enforce unique credentials per account and per privilege tier.

# Force root to use a unique, unrelated password
passwd root

# Audit for shared password hashes across all local accounts
sudo awk -F: '{print $2}' /etc/shadow | sort | uniq -d

Pair this with a password manager or centralized secrets store for administrative credentials, and never provision a new user account by copying an existing one’s password.

Key Takeaways

• Always retry a discovered or cracked password against su root (and against other local accounts) before assuming your enumeration is done — password reuse is one of the cheapest wins in any assessment
• Credential reuse doesn’t need a CVE or a misconfigured binary to be exploitable — it just needs someone, somewhere, to have set the same password twice
• SSH access and root access are only as separate as the credentials protecting them; shared passwords erase that boundary instantly
• Any duplicate password hash across /etc/shadow entries is a finding worth flagging on its own, independent of whether it happens to include root

Questions? Hit me up on X.