1

I have encountered a few cases (e.g. OSGi API, port 2222) where SSH connection via PuTTY fails to authenticate at login, while same exact authentication user/password succeeds via mRemoteNG.

PuTTY's failure symptom is by displaying a PuTTY Fatal Error message box with the following message:

"Server unexpectedly closed network connection"

with no corresponding log entry whatsoever in the server's /var/log/secure.

Both succeed through port 22 into same server. Both use SSH 2.0.

Enabling All session output in PuTTY logging, only logs this:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.12.26 13:11:05 =~=~=~=~=~=~=~=~=~=~=~=
login as: root
Further authentication required
SSH server: Password authentication
Using keyboard-interactive authentication.
Password: 

When I enabled SSH packets and raw data, putty.log included much more information. To keep this post brief, I am omitting the raw data:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.12.26 13:15:10 =~=~=~=~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH raw data mode) to file: putty.log
Event Log: Connecting to 192.168.1.2 port 2222
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.69
Incoming raw data at 2017-12-26 13:15:10
  00000000  53 53 48 2d 32 2e 30 2d 53 53 48 44 2d 43 4f 52  SSH-2.0-SSHD-COR
  00000010  45 2d 30 2e 39 2e 30 0d 0a                       E-0.9.0..
Event Log: Server version: SSH-2.0-SSHD-CORE-0.9.0
Event Log: Using SSH protocol version 2
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
...
Outgoing raw data at 2017-12-26 13:15:10
...
Incoming raw data at 2017-12-26 13:15:10
...
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
...
Event Log: Using Diffie-Hellman with standard group "group14"
Event Log: Doing Diffie-Hellman key exchange with hash SHA-1
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEXDH_INIT)
...
Outgoing raw data at 2017-12-26 13:15:10
...
Incoming raw data at 2017-12-26 13:15:10
...
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEXDH_REPLY)
...
Event Log: Host key fingerprint is:
Event Log: ssh-dss 1024 e6:85:76:7f:cb:6e:b6:21:b7:47:d0:86:a6:3f:3c:b6
Outgoing packet #0x2, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Outgoing raw data at 2017-12-26 13:15:10
...
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2017-12-26 13:15:10
Incoming raw data at 2017-12-26 13:15:10
...
Incoming packet #0x2, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x3, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
...
Outgoing raw data at 2017-12-26 13:15:10
...
Incoming raw data at 2017-12-26 13:15:10
...
Incoming packet #0x3, type 6 / 0x06 (SSH2_MSG_SERVICE_ACCEPT)
...
Outgoing packet #0x4, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
...
Outgoing raw data at 2017-12-26 13:15:12
...
Incoming raw data at 2017-12-26 13:15:12
...
Incoming packet #0x4, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...
Event Log: Further authentication required
Outgoing packet #0x5, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
...
Outgoing raw data at 2017-12-26 13:15:12
...
Event Log: Attempting keyboard-interactive authentication
Incoming raw data at 2017-12-26 13:15:13
...
Incoming packet #0x5, type 60 / 0x3c (SSH2_MSG_USERAUTH_INFO_REQUEST)
...
Outgoing packet #0x6, type 61 / 0x3d (SSH2_MSG_USERAUTH_INFO_RESPONSE)
...
Outgoing packet #0x7, type 2 / 0x02 (SSH2_MSG_IGNORE)
...
Outgoing raw data at 2017-12-26 13:15:15
...
Incoming raw data at 2017-12-26 13:15:15
...
Incoming packet #0x6, type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
Event Log: Access granted
Event Log: Opening session as main channel
Outgoing packet #0x8, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
...
Outgoing raw data at 2017-12-26 13:15:15
...
Incoming raw data at 2017-12-26 13:15:15
...
Incoming packet #0x7, type 91 / 0x5b (SSH2_MSG_CHANNEL_OPEN_CONFIRMATION)
...
Event Log: Opened main channel
Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
...
Outgoing raw data at 2017-12-26 13:15:15
...
Outgoing packet #0xa, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
...
Outgoing raw data at 2017-12-26 13:15:15
...
Event Log: Server unexpectedly closed network connection

Any idea what could be the reason for that difference between two seemingly compatible SSH clients?

UPDATE:

After finding out that mRemoteNG uses a modified version of PuTTY called mPuTTYNG (which looks and feels exactly like PuTTY, but unlike PuTTY it succeeds in connecting to the remote host), I enabled log for it too and compared the difference:

Log comparison of PuTTY (left) vs. mPuTTYNG (right)

It appears that the two use a significantly different set of ciphers... Could that be the reason?

OTOH, both use Diffie-Hellman with same exact group and hash:

Event Log: Using Diffie-Hellman with standard group "group14"
Event Log: Doing Diffie-Hellman key exchange with hash SHA-1
  • 4
    your question is: I expect this and that to work but only this works - why doesn't that work? - that is the extent of the information you have provided – Sum1sAdmin Dec 21 '17 at 10:57
  • Maybe this can help? stijn.tintel.eu/blog/2008/07/23/… . Also look at this SO thread: stackoverflow.com/questions/14282364/… – Jay Souper Dec 22 '17 at 5:26
  • 1
    @Sum1sAdmin Thanks to the answer I received below, I have been able to extract initial troubleshooting information and post it here. I am not familiar with the details in the log, so perhaps a seasoned SSH expert can spot what's wrong with this session. – datv Dec 26 '17 at 11:29
5

Any tip on how to troubleshoot this would be much appreciated.

Look in the logs for the applications and on the server would be the first thing I would do. I would then proceed based on what I learned from them.

  • Thanks. I found this tutorial for getting the logs for PuTTY. Will implement and report back. I wish I had enough reputation to vote you up. – datv Dec 26 '17 at 8:36
  • 2
    Check the server logs they will most likely contain relevant information. – Iain Dec 26 '17 at 12:26
  • @user449299 that isn't always true... if it's truly an algorithm mismatch it's likely to not see the attempt in your logs. I've had to resort to packet captures plenty just for that reason. Your answer is great but that is an important caveat. – Tim Brigham Dec 27 '17 at 20:12
  • 1
    You can have fun with that stuff stribika.github.io/2015/01/04/secure-secure-shell.html script kiddes be gone :) – Iain Dec 27 '17 at 21:19
  • @user449299 The link you provide is priceless. Voting you up now (from 4 to 5 :)). – datv Dec 28 '17 at 6:46
1

OK, after enabling logging for the PuTTY that fails on port 2222, then comparing it to the log on the same PuTTY that succeeds on port 22:

enter image description here

I can see that:

mPuTTYNG (and thus mRemoteNG) supports SSH-2.0-SSHD-CORE-0.9.0 which is required by OSGi port 2222. PuTTY only supports SSH-2.0-OpenSSH_5.3.

mRemoteNG uses a modified older version 0.63 of PuTTY. The failing PuTTY is version 0.69.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.