I am able to recreate the issue. It might be a bug and I would suggest opening a TAC case. Here's the debug info I got trying to establish a connection. BTW I rebuilt the entire config after the upgrade and got the same results.

*Mar 4 21:06:29.515: SSH0: starting SSH control process

*Mar 4 21:06:29.515: SSH0: sent protocol version id SSH-2.0-Cisco-1.25

*Mar 4 21:06:29.519: SSH0: protocol version id is - SSH-2.0-SecureCRT_5.1.3 (build 281) SecureCRT

*Mar 4 21:06:29.519: SSH2 0: send:packet of length 344 (length also includes padlen of 5)

*Mar 4 21:06:29.519: SSH2 0: SSH2_MSG_KEXINIT sent

*Mar 4 21:06:29.519: SSH2 0: ssh_receive: 464 bytes received

*Mar 4 21:06:29.519: SSH2 0: input: total packet length of 464 byte

ssh-test#s

*Mar 4 21:06:29.523: SSH2 0: partial packet length(block size)8 bytes,needed 456 bytes,

maclen 0

*Mar 4 21:06:29.523: SSH2 0: input: padlength 9 bytes

*Mar 4 21:06:29.523: SSH2 0: SSH2_MSG_KEXINIT received

*Mar 4 21:06:29.523: SSH2:kex: client->server enc:aes256-cbc mac:hmac-sha1

*Mar 4 21:06:29.523: SSH2:kex: server->client enc:aes256-cbc mac:hmac-sha1

*Mar 4 21:06:29.523: SSH2 0: ssh_receive: 24 bytes received

*Mar 4 21:06:29.523: SSH2 0: input: total packet length of 2

ssh-test#4 bytes

*Mar 4 21:06:29.523: SSH2 0: partial packet length(block size)8 bytes,needed 16 bytes,

maclen 0

*Mar 4 21:06:29.523: SSH2 0: input: padlength 6 bytes

*Mar 4 21:06:29.527: SSH2 0: SSH2_MSG_KEX_DH_GEX_REQUEST received

*Mar 4 21:06:29.527: SSH2 0: Range sent by client is - 1024 < 2046 < 2046

*Mar 4 21:06:29.527: SSH2 0: Invalid modulus length

*Mar 4 21:06:29.627: SSH0: Session disconnected - error 0x00

Hope that helps.

VanDyke is aware and a recent SecureCRT beta has been released to address the issue:

http://www.vandyke.com/products/beta/securecrt/history.txt

Sure would be nice to disable this new strict checking in IOS, though.

VanDyke software provided a solution:

The new Cisco IOS it seems, requires that the modulus size meet certain criteria that is not specified in the SSH draft.

The following has been known to resolve the issue for other customers encountering this issue:

1. In the 'SSH2' category of the Session Options dialog, select the 'diffie-hellman' key exchange method (without changing any of the checkboxes), and click the up arrow to move this method to the top of the list.

2. Click 'OK' to exit the Session Options dialog and attempt the connection again.

If your version of SecureCRT does not have this option then each of the session ini files will need to be modified. You must move 'diffie-hellman-group1-sha1' to the front of the list on line 'S:"Key Exchange Algorithms"'

Jason