3

I'm using OpenSSH_5.8p1 in my machine,I'm connecting my machine using putty client but its slower so I have ran sshd in debug mode and found following messages can any one explain me in detail about each messages?

debug1: sshd version OpenSSH_5.8p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.

debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 4, 4
Connection from 192.168.0.57 port 33962
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63
debug1: no match: PuTTY_Release_0.63
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

delay of 1.5 second

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received

delay of 1.8 second

debug1: KEX done
Connection closed by 192.168.0.57
Rahul Dhobi
  • 2,037
  • 3
  • 14
  • 11
  • slower than what ? – Kiwy Apr 04 '14 at 09:25
  • @Kiwy:In other system ssh connects fast but in case in my machine using putty it connects slow – Rahul Dhobi Apr 04 '14 at 09:33
  • So connection from other computers to the same server is faster compare to the connection from your computer ? Do you use the same connection ? – Kiwy Apr 04 '14 at 09:37
  • No I'm accessing my pc using putty from other computer using putty that is slower – Rahul Dhobi Apr 04 '14 at 09:42
  • **PLEASE** try to express clearly what is your problem. and **[edit]** your question instead of putting more info in comments. From which machine to which machine is the ssh connection slow. And what comparison are you referring to, to affirm that this connection is slower ? – Kiwy Apr 04 '14 at 09:45
  • I seriously doubt the reason for you slow connection can be found in your `ssh` log. Perhaps is the result of your network configuration either on one of the computers or another network device, eg router. It could even be some hardware incompatibility. Your `ssh` output mostly contains messages showing different authentication steps, nothing that really indicates *why* there is a delay. – Graeme Apr 04 '14 at 10:38
  • Btw, I have written some long answers on this site, but giving a 'detailed explanation` of each of these messages is way too much for me. I'm sure you can find something detailing the `ssh` key exchange process somewhere on the net if you want to understand this. Voting to close as too broad. – Graeme Apr 04 '14 at 10:43
  • [RFC4252 - The Secure Shell (SSH) Authentication Protocol](http://www.rfc-editor.org/rfc/rfc4252.txt). Also this: https://en.wikipedia.org/wiki/Secure_Shell – slm Apr 04 '14 at 12:10
  • 2
    This isn't enough information to determine the cause of each pause. Run sshd with a higher level debug `sshd -ddd` along with the client in verbose mode `ssh -vvv`. That should have enough info. – phemmer Apr 04 '14 at 13:28

1 Answers1

7

This question sounds like a case of the XY problem; you're asking for something that probably doesn't help you with the problem you actually want to solve. Perhaps you should be more careful what you ask for, but for the sake of general knowledge, here goes..


debug1: sshd version OpenSSH_5.8p1

This indicates that the version of OpenSSH is 5.8p1


debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA 
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA

This indicates that OpenSSH found three host keys, which are used to convince the client that the remote is indeed the host the client intended to connect to. The keys are for the RSA, DSA and Elliptic Curve DSA cryptographic algorithms.


debug1: rexec_argv[0]='/sbin/sshd'
debug1: rexec_argv[1]='-d'

These are the arguments the ssh daemon was invoked with.


Set /proc/self/oom_adj from 0 to -17

This indicates that the ssh daemon disables the kernel Out-of-Memory Killer altogether for this process.


debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.

This indicates the server is listening for connections to port 22 from any IPv4 source address.


debug1: Bind to port 22 on ::.
Server listening on :: port 22.

This indicates the server is listening for connections to port 22 from any IPv6 source address.


debug1: Server will not fork when running in debugging mode.

Normally sshd forks a new process for each incoming connection. Since the -d options was specified when sshd was invoked, it runs in debugging mode and does not fork and will only process one connection.


debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 4, 4

This indicates that some communication sockets were duplicated.


Connection from 192.168.0.57 port 33962 
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63
debug1: no match: PuTTY_Release_0.63
debug1: Enabling compatibility mode for protocol 2.0

This indicates an incoming connection was received from a Putty client. The ssh daemon does not recognize the particular version string sent by the client, so it will operate in a mode compatible with the SSH protocol version 2 specification.


debug1: Local version string SSH-2.0-OpenSSH_5.8
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256

This indicates that the ssh daemon identified itself as an SSH 2.0 compatible OpenSSH daemon. The hostkey types indicate the cryptographic algorithms the ssh daemon supports for performing host authentication.


debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

delay of 1.5 second

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received

delay of 1.8 second

debug1: KEX done

These messages indicate that a Diffie-Hellman Group Exchange was performed to exchange key material. After the protocol completes, the client and server have agreed upon a session key used to encrypt further communication using the AES cryptographic algorithm with 256 bit keys in Counter mode and the SHA1 cryptographic hash algorithm for the hash-based message authentication code.


Connection closed by 192.168.0.57

This indicates that the connection was closed by the client.


Thomas Nyman
  • 29,912
  • 10
  • 65
  • 77
  • Nice explanation. Can you say what "PEM" in "PEM private key" means? – Faheem Mitha Apr 04 '14 at 15:14
  • 1
    @FaheemMitha PEM stands for [Privacy Enhanced Mail](http://www.ietf.org/rfc/rfc1421.txt), which was a protocol for encrypted email which never caught on. The [certificate-based key management](http://www.ietf.org/rfc/rfc1422.txt) designed for PEM was compatible with the X.509 PKI widely used today. In this case it refers to the `.pem` container format which can be used to store different types of certificates. – Thomas Nyman Apr 04 '14 at 16:10
  • Thanks, Thomas. You certainly know a lot about this stuff. – Faheem Mitha Apr 04 '14 at 16:20
  • @ThomasNyman: Thanks for good explanation,but I'm more interested in debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes256-ctr hmac-sha1 none debug1: kex: server->client aes256-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent delay of 1.5 second debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received – Rahul Dhobi Apr 05 '14 at 04:30
  • 2
    @user3184706 The client and server perform a [Diffie-Hellman group exchange](https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange) to exchange keys. The protocol is documented in [RFC4419](http://www.ietf.org/rfc/rfc4419.txt). As [Patrick already pointed out](http://unix.stackexchange.com/questions/123091/understand-debug-messages-from-sshd/123113#comment195153_123091) the transcript you provided isn't enough to determine the cause for the delays, partly because debug level 1 is not detailed enough, but most importantly because _you only provide one side of the exchange_. – Thomas Nyman Apr 05 '14 at 11:23