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.
sshd -dddalong with the client in verbose modessh -vvv. That should have enough info.