View Issue Details

IDProjectCategoryView StatusLast Update
0005143Kali Linux[All Projects] General Bugpublic2018-12-08 16:02
Reporterroger6Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version2018.4 
Target VersionFixed in Version 
Summary0005143: ssh over NAT of VMware will be failed by Connection reset by peer error
DescriptionHello,
I found if I start sshd behind vmware NAT portmapping, it will be occur error after I input account/password during ssh client login
debuglog error line:
Read error from remote host 1.1.1.1 port 8888: Connection reset by peer
You can get more detail information from full sshd debuglog attached

Activities

roger6

2018-12-06 10:17

reporter  

sshderror.txt (4,290 bytes)
root@kali:~# /usr/sbin/sshd -d -D
debug1: sshd version OpenSSH_7.8, OpenSSL 1.0.2o  27 Mar 2018
debug1: private host key #0: ssh-rsa SHA256:YlfUonPt94c9VkKmUNL9LvYSnvqnfijx+LeFr0y3cus
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:sYSLmneJpItfd4nXvMHyKHutVI+3ZiNAO8t3yupWs2g
debug1: private host key #2: ssh-ed25519 SHA256:8wiedgsAfb61GmOIejc4OTBLFgrjo7PQXpxmyy0taYU
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-D'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
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 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 1.1.1.1 port 8888 on 192.168.206.130 port 22
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.70
debug1: no match: PuTTY_Release_0.70
debug1: Local version string SSH-2.0-OpenSSH_7.8p1 Debian-1
debug1: permanently_set_uid: 122/65534 [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: curve25519-sha256@libssh.org [preauth]
debug1: kex: host key algorithm: ssh-rsa [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user roger service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "roger"
debug1: PAM: setting PAM_RHOST to "1.1.1.1"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user roger service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication accepted for roger
debug1: do_pam_account: called
Accepted password for roger from 1.1.1.1 port 8888 ssh2
debug1: monitor_child_preauth: roger has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
User child is on pid 2068
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1000/1000
debug1: rekey after 4294967296 blocks
debug1: rekey after 4294967296 blocks
debug1: ssh_packet_set_postauth: called
debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/1
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on pts/1 for roger from 1.1.1.1 port 8888 id 0
Read error from remote host 1.1.1.1 port 8888: Connection reset by peer
debug1: do_cleanup
debug1: Setting controlling tty using TIOCSCTTY.
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
debug1: session_pty_cleanup: session 0 release /dev/pts/1
debug1: audit_event: unhandled event 12
sshderror.txt (4,290 bytes)

rhertzog

2018-12-06 10:58

administrator   ~0010082

Have a look at ticket 0005095 isn't this the same underlying issue (but on the opposite direction) ?

roger6

2018-12-06 12:13

reporter   ~0010083

I have tried the solution of ticket 0005095 :
1. add OPQoS=throughput to /etc/ssh/ssh_config
2. restart sshd: service ssh stop -> service ssh start
but it's still not work

rhertzog

2018-12-06 20:22

administrator   ~0010087

In your case, you might want to use it in /etc/ssh/sshd_config since you are connecting to the server. But maybe it's needed on both sides. It probably depends on what version of the SSH client you are using to connect to the kali machine.

roger6

2018-12-06 20:33

reporter   ~0010088

I use PuTTY 0.70 to connect my kali machine, default setting I think

SexWarrior

2018-12-07 12:24

reporter   ~0010092

A few things to hopefully help this move along:

I have tried to reproduce this on the same VM as 0005095 - Windows 10 host with VMWare Workstation 15.0.2 build-10952284, running Kali 2018.4 with recent updates (up to date as of today, note that this means I'm running OpenSSH 7.9p1). I was NOT able to reproduce the problem with either Putty 0.70 or with OpenSSH for Windows 7.6p1 (understandably, since 7.6 would predate the issue, but that's what Windows currently ships with).

I then attempted to force my OpenSSH client to use -o IPQoS=AF21 and -o IPQoS=CS1. I was once again NOT able to reproduce the problem, connecting successfully in each instance.

I then tried downloading the latest test release of OpenSSH for Windows (7.7.2.0p1-Beta) - no change.

Finally, I spun up a completely fresh Kali 2018.4 VM with no updates. Once again, both my Windows clients were able to successfully ssh into the VM, even when forced to use the "bad" IPQoS settings.

Connections between the two VMs also work regardless of IPQoS settings, but that's somewhat understandable since it would all stay inside vmnat virtualisation in that scenario.

I suspect we'll need to find out more about the client that's causing the problem before we can reproduce it - I have a hunch it might be the client that's triggering the bug, and not the sshd in Kali. Some questions to perhaps get us started, @roger6:
-What operating system are you using?
-Is the client a virtual machine? If so, what virtualisation software are you using for it?
-What's the exact version of VMWare you're using for the server?
-Try using OpenSSH on the client side, with IPQoS=throuput set (either in /etc/ssh/ssh_config or by adding the -o IPQoS=throughput flag at run time). Does the problem persist?

SexWarrior

2018-12-07 12:30

reporter   ~0010093

Indeed, reading through your sshd log, it would appear that it's the client that broke the connection:

    Read error from remote host 1.1.1.1 port 8888: Connection reset by peer

roger6

2018-12-08 07:21

reporter   ~0010094

Hi,

as SexWarrior mentioned, I should post the associated scenario here:

-What operating system are you using?
Windows 7x64, with patched fully

-Is the client a virtual machine? If so, what virtualisation software are you using for it?
Client is real machine.

-What's the exact version of VMWare you're using for the server?
VMWare version is 14.0.0.build-666.1328

-Try using OpenSSH on the client side, with IPQoS=throuput set (either in /etc/ssh/ssh_config or by adding the -o IPQoS=throughput flag at run time). Does the problem persist?
I tried to do these steps to fix issue:
1. add IPQoS=throughput to /etc/ssh/ssh_config
2. restart sshd: service ssh stop -> service ssh start

But it still doesn't work fine, then I tried to change the way:
1. run sshd by command line:
/usr/sbin/sshd -d -D -o IPQoS=throughput

It worked now, magic!

It perhaps mean current sshd don't reference the setting of /etc/ssh/ssh_config
Is it issue? How can I fix it if it's issue?

SexWarrior

2018-12-08 08:32

reporter   ~0010095

As @rhertzog mentioned, you need to be looking at /etc/ssh/sshd_config and not /etc/ssh/ssh_config.

ssh_config is the client configuration, and sshd_config is for the server, broadly speaking.

roger6

2018-12-08 16:02

reporter   ~0010097

Yes you both are right, I change wrong file, it should be /etc/ssh/sshd_config
Now all works fine now, I'm apologized and many thanks to you both :)

Issue History

Date Modified Username Field Change
2018-12-06 10:17 roger6 New Issue
2018-12-06 10:17 roger6 File Added: sshderror.txt
2018-12-06 10:58 rhertzog Note Added: 0010082
2018-12-06 12:13 roger6 Note Added: 0010083
2018-12-06 20:22 rhertzog Note Added: 0010087
2018-12-06 20:33 roger6 Note Added: 0010088
2018-12-07 12:24 SexWarrior Note Added: 0010092
2018-12-07 12:30 SexWarrior Note Added: 0010093
2018-12-08 07:21 roger6 Note Added: 0010094
2018-12-08 08:32 SexWarrior Note Added: 0010095
2018-12-08 16:02 roger6 Note Added: 0010097