There's VERBOSE, DEBUG, DEBUG{1,2,3}
Feb 17 12:15:44 znuny sshd[47414]: debug1: Forked child 47425. Feb 17 12:15:44 znuny sshd[47425]: debug1: Set /proc/self/oom_score_adj to 0 Feb 17 12:15:44 znuny sshd[47425]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Feb 17 12:15:44 znuny sshd[47425]: debug1: inetd sockets after dupping: 4, 4 Feb 17 12:15:44 znuny sshd[47425]: Connection from x.x.x.x port NNNNN on y.y.y.y port 22 rdomain "" Feb 17 12:15:44 znuny sshd[47425]: debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5 Feb 17 12:15:45 znuny sshd[47425]: debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8 Feb 17 12:15:45 znuny sshd[47425]: debug1: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000 Feb 17 12:15:45 znuny sshd[47425]: debug1: permanently_set_uid: 105/65534 [preauth] Feb 17 12:15:45 znuny sshd[47425]: debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 17 12:15:45 znuny sshd[47425]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Confusing af. Because there's nothing useful for some reason. What about DEBUG3?
https://pastebin.com/Cszsar6u
If you search for SSH2_MSG_KEXINIT, you'll find lots of people having a similar issue.
What bothers me in your case is that child sshd process exits right after sending key exchange request to your client. In issues of other people, some at least had their client respond to this.
Обсуждают сегодня