Decrypting SSH traffic

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
In order to set up a honeypot system, it would be quite useful to
decrypt all the SSH traffic to and from the machine. The best way to do
this IMHO would be to deploy a monitoring machine attached to the same
hub (not switch) as the honeypot using a one-way ethernet cable.

One should be able to decrypt SSH sessions from the captured traffic
using the host's private key of the honeypot, because AFAIK that key is
used to encrypt the symmetric random session key (blowfish). Thus far
I've not found any applications that can do this. NetIntercept can
decrypt SSH traffic, but requires patching of the OpenSSH server, which
could be detected by an attacker.

Before I start coding myself, does anyone know if my theory is correct?
And is there really no existing application to do this or did I just not
look hard enough.


Re: Decrypting SSH traffic

Quoted text here. Click to load it

That information is both out of date and incomplete.

It's out of date, because the host's private key was used for
encryption in SSH-1, but everybody should be using SSH-2 now. SSH-2
uses Diffie-Hellman symmetric key exchange, with private data
invented by each end for one-off use; the host's private key is only
used for creating signatures.

It's also incomplete, because even in SSH-1 the host's static
private key was only half the story; there was also a `server key'
changed every hour and only stored inside the server's memory, and
the session key was double-encrypted with both.

Quoted text here. Click to load it

You are definitely going to need _some_ sort of privileged
information out of the innards of the server.

If you don't want to patch the server itself, another option that
spring to mind is to have a secondary program that periodically
attaches to sshd using ptrace(2) and extracts session keys; but of
course an attacker might spot that too.

Or you could run the entire honeypot system inside an emulation
environment so that a layer outside that can do the key extraction
without being directly perceptible to the attacker; but an attacker
might be able to (somehow) deduce the presence of the emulation from
quirks of the emulated system.

A third option involves nobbling the server's random number
generation, so that you can simply _guess_ after each key exchange
what its private Diffie-Hellman integer was. But, again, that still
involves potentially detectable modifications to the server and/or
the kernel on which the server is running.

I can't think of any method of doing what you want which doesn't
leave _some_ means by which a sufficiently paranoid attacker might
able to detect it. The emulation option is probably the best in
theory, since an emulated system can _in principle_ be made
arbitrarily faithful to the real hardware it's emulating, but in
practice it's not clear to me that it would be noticeably better
than any of the other options.
for k in [pow(x,37,0x13AC59F3ECAC3127065A9) for x in [0x195A0BCE1C2F0310B43C,
0x73A0CE584254AB23D5A0, 0x12878657EA814421CC92, 0x7373445BB3DA69996F4A,
0x77A7ED5BC3AA700E80B2, 0xE9C71C94ED87ADCF7367, 0xFE920395F414C1A5DB50]]:

Re: Decrypting SSH traffic

Simon Tatham wrote:
Quoted text here. Click to load it

You're right. Should have figured that out earlier.

Quoted text here. Click to load it

What about physically reading a hardware RNG? Not going to do it, but in
theory it should work, while the attacker is unable to circumvent and/or
notice it.

For practical purposes, patching is probably easier.

Site Timeline