Sniffing SSH Passwords

Is it possible to get someone’s password in plaintext over ssh? Yes! Surely, this makes no sense when the purpose of ssh is to prevent such a thing. Well, I’m speaking of monitoring the session directly from the server the user is connecting to and not across the network.

Although traffic across the network is encrypted, on the server side, sshd will fork off a child process where the password is readable during the decryption. This is a known functionality of sshd and can been viewed by running strace against the process.

First, let us find the exact sshd pid. You may try to get the oldest pid by using “pgrep -o sshd” but I have seen instances of a maintained older sub-process being reported after an sshd restart. So, instead we go with,

# pgrep -l sshd
6235 sshd

On our test server, we will run strace and specify -p with the sshd pid. The -f flag will monitor all child processes and -e will trace needed system calls. Options available are, trace=open,close,read,write. However, we will use just write to cut down on the noise. Lastly, save the output (-o capture) to a file.

# strace -f -p 6235 -e trace=write -o capture

Now, from our client machine, we will ssh into the server and immediately exit.

[ ~]$ ssh -l robert's password: 
Last login: Sat Apr 10 12:46:59 2021 from
[ ~]$ exit

On the server, hit ctrl+c to stop the process and view the captured output.

# strace -f -p 6235 -e trace=write -o capture
strace: Process 6235 attached
strace: Process 30494 attached
strace: Process 30495 attached
strace: Process 30510 attached
^Cstrace: Process 6235 detached

# vi capture

After a quick search for the username, you will locate the plaintext password a few lines below,

Final thoughts

You may note that in order to run strace on sshd, you will already need root access and think, ‘What’s the point?’! Although there are probably many examples of needing to recover a system service password that can’t be changed, I used this to dissuade against integration of Linux systems into Active Directory.

First, in many organizations, there are separate groups for managing Windows and Unix/Linux system and I never wanted a Windows Admin to give themselves access to an AD Linux group and have control of systems that were outside their responsibilities. A separate directory service should be used for Linux systems…

…and more importantly, you would want to prevent lateral movement within your network to your Windows systems if one of the Linux servers was compromised. I demonstrated this by joining a Linux server into AD and then capturing the password credentials of Windows Domain Admin user. Game over.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s