Chris,
I think I have the answer to this... I believe I'd classify this as a bug in the SSH server implementation, but probably one that can be worked around.
At the beginning of the SSH2 exchange, the client and server exchange a version string. According to RFC4253, an SSH2 server should send (and expect to receive) a carriage return/linefeed pair to define the end of the string. In SSH1, the version string would just be terminated by a linefeed alone.
If Absolute sends a CR/LF pair to terminate the version string (ssh2 behavior). the connection gets nowhere. If I send a single linefeed instead (ssh1 behavior), the connection works fine. This tells me that the server is relying on SSH1 behavior and breaks when held strictly to SSH2 RFC4253 standards.
With this in mind, I modified the AbsoluteTelnet logic a bit. I first watch for the server version string to arrive. I check to see whether the server uses CR/LF or just LF to terminate the version string. Whatever the server uses for the terminator is what Absolute will use when sending its own version string.
This seems to work well for the Cisco and doesn't break compatibility on any other server I've tested.
Give it a try here:
www.celestialsoftware.net/telnet/AbsoluteTelnet7.54RC13.exe
Let me know how it goes!
Brian