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.
[firstname.lastname@example.org ~]$ ssh -l robert s1.networklogician.com email@example.com's password: Last login: Sat Apr 10 12:46:59 2021 from c1.networklogician.com [firstname.lastname@example.org ~]$ exit logout
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,
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.