TCP/IP 5.6ECO3 SSH Server Key Regeneration Problems

[Saul Cisneros]

The issue I've been investigating concerns key regeneration. After upgrading to TCP/IP 5.6ECO3, proper SSH key regeneration is broken. One HP rep confirmed he has seen this with other systems. Setting the Putty option, "Handles SSH-2 key re-exchange badly" to "On" corrects the issue. However, I was wondering if anyone else had come across this or found a more proper fix.

[Richard W Hunt]

I don't use PuTTY at my site but I've seen the Key Regen issue. There is a published bug in both Solaris and UNIX SSH, and of course the TCPIP stack's implementation of SSH is just a port of a UNIX version. If for some reason a server has had more than one server key AND the client-side has copies of both the old and new keys AND the old (obsolete) key is first in the list, you get problem with the key regen process.

My solution was to get into the hostkeys subfolder in my client-side machine and purge old keys. Or all keys for that machine. Then, of course, at next connection attempt, you have to accept the server key again. But this time it is going to be first in the list and the ReKey feature will work better. At least, it did for me.

[Hoff]

Proper fix? That's going to be the subject to some local discussion and decisions. One option would be to replace the ssh server here with an ssh server that (better) supports key renegotiation.

PuTTY is working around this, using the specified knob.

Per the PuTTY documentation:

--

4.24.8 â Handles SSH-2 key re-exchange badlyâ

Some SSH servers cannot cope with repeat key exchange at all, and will ignore attempts by the client to start one. Since PuTTY pauses the session while performing a repeat key exchange, the effect of this would be to cause the session to hang after an hour (unless you have your rekey timeout set differently; see section 4.19.2 for more about rekeys). Other, very old, SSH servers handle repeat key exchange even more badly, and disconnect upon receiving a repeat key exchange request.

If this bug is detected, PuTTY will never initiate a repeat key exchange. If this bug is enabled when talking to a correct server, the session should still function, but may be less secure than you would expect.

This is an SSH-2-specific bug.
--

For details of the rekey process, see:

http://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter4.html#config-ssh-kex-rekey