[SOLVED] sshd Connection closed by <IP> [preauth]

mfoley · 12-06-2023, 02:31 AM

I'm stumped. I have a Linux host, DC1, which was located remotely. I was able to ssh into it from my home linux computer QUADMON without problem. I then brought this host home and connected it to my LAN with IP 192.168.0.2. But now when I try to connect from QUADMON I get the following in DC1's /var/log/messages:

Code:

sshd Connection closed by 192.168.0.17 port 54786 [preauth]

If I try connecting from another linux computer on my home LAN I get:

Code:

ssh_exchange_identification: read: Connection reset by peer

sshd is listening on 22 on DC1. DC1 has an empty /home/mfoley/.ssh/know_hosts.

I can telnet from QUADMON to port 22 on DC1.

Any idea why I can't ssh from QUADMON to DC1?

lvm_ · 12-06-2023, 03:45 AM

Check server logs, increase log verbosity if necessary (loglevel in /etc/ssh/sshd_config - assuming the ubiquitous openssh). Also addresses here

Quote:

Originally Posted by mfoley

I then brought this host home and connected it to my LAN with IP 192.168.0.2.

and here

Quote:

Originally Posted by mfoley

Code:

sshd Connection closed by 192.168.0.17 port 54786 [preauth]

don't match - are you sure you are connecting to the server you want?

mfoley · 12-06-2023, 08:24 AM

I've upped the sshd_config LogLevel to DEBUG. The computer to which I'm trying to connect is DC1, IP 192.168.0.2. The computer I'm trying to connect to DC1 from is QUADMON 192.168.0.17. I have an ASUS RT-AC66U B1 at 192.168.0.1 for the Internet connection and for the DNS for the LAN.

I can ssh from DC1 to QUADMON, no problem (except that 'last' shows me connecting from 192.168.0.1?!). When I attempt to ssh from QUADMON to 192.168.0.2 I get:

Code:

kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.0.2 port 22

There is nothing in DC1's /var/log/messages or /var/log/syslog when I make this attempt. In DC1's /var/log/debug I get:

Code:

Dec  6 09:12:07 DC1 sshd[10356]: debug1: Forked child 10430.
Dec  6 09:12:07 DC1 sshd[10430]: debug1: Set /proc/self/oom_score_adj to 0
Dec  6 09:12:07 DC1 sshd[10430]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Dec  6 09:12:07 DC1 sshd[10430]: debug1: inetd sockets after dupping: 4, 4
Dec  6 09:12:07 DC1 sshd[10430]: debug1: getpeername failed: Transport endpoint is not connected
Dec  6 09:12:07 DC1 sshd[10430]: debug1: ssh_remote_port failed

Does this tell us anything?

thinknix · 12-06-2023, 08:40 AM

Sounds like a firewall is rejecting the connections somewhere, or hosts.deny if you use it. It could also be a restriction in the server config or authorized_keys. You can get better detail on why an SSH connection is being closed by running the server in debug mode on a different port.

Code:

/usr/sbin/sshd -d -p 2222

sshd won't detach with -d, and your connection details to that port will show on the console.

mfoley · 12-06-2023, 01:04 PM

On the console I get:

Code:

# /usr/sbin/sshd -d -p 2222
debug1: sshd version OpenSSH_9.3, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ssh-rsa SHA256:5JtPT7KzCs4Xw1+9gsFzqH6OuqitFsaOc2selQX15Rk
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:DLXtM4hOfcJ5mNQVNVAYklXO7Ksr5kagPxwXecQclPc
debug1: private host key #2: ssh-ed25519 SHA256:NheZF6kVf+/todLJtelYF1Vvcccuk1Hz2u0Q0dHZwSE
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2222'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.

(waits at this point ...)

debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_9.3, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ssh-rsa SHA256:5JtPT7KzCs4Xw1+9gsFzqH6OuqitFsaOc2selQX15Rk
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:DLXtM4hOfcJ5mNQVNVAYklXO7Ksr5kagPxwXecQclPc
debug1: private host key #2: ssh-ed25519 SHA256:NheZF6kVf+/todLJtelYF1Vvcccuk1Hz2u0Q0dHZwSE
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: ssh_remote_port failed

The server sshd then exits at that point.

On the client side I get:

Code:

$ ssh -p 2222 192.168.0.2
kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.0.2 port 2222

No firewall is running on either end.

scasey · 12-06-2023, 01:28 PM

My guess is that DC1’s sshd is not configured to listen in the new IP address. What does

Code:

netstat -tnlp

On DC1 show?
…or review the sshd config

mfoley · 12-06-2023, 01:45 PM

Quote:

Originally Posted by scasey

My guess is that DC1’s sshd is not configured to listen in the new IP address. What does

Code:

netstat -tnlp

On DC1 show?
…or review the sshd config

(samba removed)

Code:

# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:88              0.0.0.0:*               LISTEN      9978/krb5kdc
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1225/sendmail: acce
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      15303/sshd: /usr/sb
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      1225/sendmail: acce
tcp6       0      0 :::88                   :::*                    LISTEN      9978/krb5kdc
tcp6       0      0 :::22                   :::*                    LISTEN      15303/sshd: /usr/sb

thinknix · 12-06-2023, 02:15 PM

Quote:

Originally Posted by mfoley

The computer to which I'm trying to connect is DC1, IP 192.168.0.2. The computer I'm trying to connect to DC1 from is QUADMON 192.168.0.17. I have an ASUS RT-AC66U B1 at 192.168.0.1 for the Internet connection and for the DNS for the LAN.

I can ssh from DC1 to QUADMON, no problem (except that 'last' shows me connecting from 192.168.0.1?!). When I attempt to ssh from QUADMON to 192.168.0.2 I get:
[code]
kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.0.2 port 22

Just reading the above more closely, when you ssh from .2 to .17, the last log shows .1 as the IP? That would indicate the traffic is being routed through your Asus router and NAT'd on the way. But it shouldn't be NAT'ing LAN-to-LAN connections like that. Try disabling that in your router config and see if the connection in the other direction works.

Also check to be sure you have one device with the .17 IP - maybe that IP is also part of a DHCP range and assigned to another client, for example. You could verify this by looking at the router's ARP database and correlating the entry for the .17 IP with the interface MAC address on .17 itself to make sure they match.

Final suggestion, you can use up to 3 'd' params when running sshd in debug mode, so 'sshd -ddd -p 2222' will give you the most detail.

scasey · 12-06-2023, 04:35 PM

Quote:

Originally Posted by mfoley

(samba removed)

Code:

# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:88              0.0.0.0:*               LISTEN      9978/krb5kdc
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1225/sendmail: acce
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      15303/sshd: /usr/sb
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      1225/sendmail: acce
tcp6       0      0 :::88                   :::*                    LISTEN      9978/krb5kdc
tcp6       0      0 :::22                   :::*                    LISTEN      15303/sshd: /usr/sb

My guess was wrong, then. Sorry.
What are the permies of the ~/.ssh directory for the user on DC1?

michaelk · 12-06-2023, 05:43 PM

If I understand your 1st post you only physically moved the server from a remote location to home. Have you recently updated software on any computers? I might of expected a host key error on QUADMON. Can you ssh to your user on DC1 itself?

What are the distribution / versions of the other computers on your LAN as well as ssh versions? The other computers if not running a newer version of ssh might be using older encryption algorithms which might be causing the ssh_exchange_identification error. It could also be a reverse DNS lookup error.

mfoley · 12-06-2023, 06:34 PM

Quote:

Originally Posted by thinknix

Just reading the above more closely, when you ssh from .2 to .17, the last log shows .1 as the IP? That would indicate the traffic is being routed through your Asus router and NAT'd on the way. But it shouldn't be NAT'ing LAN-to-LAN connections like that. Try disabling that in your router config and see if the connection in the other direction works.

In the router there is a setting for LAN > Switch Control > NAT Acceleration, which was set to "Auto - CTF (Cut Through Forwarding) is enabled". I set that to "disabled". No effect. I don't see any other NAT settings on this router. I don't know what "Nat Acceleration" does, but disabling it made it so I couldn't connect to LAN host by name and messed up the registration setting of my ROKU TV.

Quote:

Also check to be sure you have one device with the .17 IP - maybe that IP is also part of a DHCP range and assigned to another client, for example. You could verify this by looking at the router's ARP database and correlating the entry for the .17 IP with the interface MAC address on .17 itself to make sure they match.

Nmap shows the following:

Code:

Nmap scan report for RT-AC66U_B1-8028 (192.168.0.1)
Nmap scan report for 192.168.0.2
Nmap scan report for watcher (192.168.0.10)
Nmap scan report for HPFBB6AB (192.168.0.11)
Nmap scan report for HPB2A954 (192.168.0.21)
Nmap scan report for android-c720603da1ee1695 (192.168.0.28)
Nmap scan report for 192.168.0.29
Nmap scan report for DGFlaptop (192.168.0.48)
Nmap scan report for doris (192.168.0.51)
Nmap scan report for Lenovo (192.168.0.98)
Nmap scan report for quadmon (192.168.0.17)

The list of connected devices in the router is:

Code:

Internet access state	Device Type	Client Name	Client IP address	IP Method	Clients MAC Address	Interface
Allow Internet access	Loading manufacturer..	58:11:22:C7:38:1C	192.168.0.2	Static IP	58:11:22:C7:38:1C	Wired
Allow Internet access	Hon Hai	Watcher	192.168.0.10	MAC-IP Binding	C0:18:85:8B:ED:31	2.4 GHz
Allow Internet access	Hewlett Packard	HPFBB6AB	192.168.0.11	MAC-IP Binding	98:E7:F4:FB:B6:AC	2.4 GHz
Allow Internet access	Loading manufacturer..	04:7C:16:D0:25:3D	192.168.0.17	MAC-IP Binding	04:7C:16:D0:25:3D	Wired
Allow Internet access	HP Inc.	HPB2A954	192.168.0.21	Automatic IP	38:22:E2:B2:A9:54	5 GHz
Allow Internet access	SAMSUNG	SAMSUNG(android)	192.168.0.28	Automatic IP	EC:1F:72:72:3E:8B	5 GHz
Allow Internet access	Loading manufacturer..	F2:D1:D1:B5:C8:1B	192.168.0.29	Automatic IP	F2:D1:D1:B5:C8:1B	5 GHz
Allow Internet access	AzureWave Technology Inc.	DGFlaptop	192.168.0.48	Automatic IP	74:C6:3B:4D:0F:D6	2.4 GHz
Allow Internet access	ASUS	ASUS	192.168.0.51	Static IP	10:7B:44:7E:41:14	Wired
Allow Internet access	Intel Corporate	Lenovo	192.168.0.98	Automatic IP	B4:69:21:A4:AD:F3	2.4 GHz
Allow Internet access	CHANGHONG (HONGKONG) 50WestinghouseRokuTV	192.168.0.103	Automatic IP	AC:AC:E2:5C:7A:D8	Wired

(Sorry, that's probably not very readable)
IPs 192.168.0.10 (Slackware 14.2 netbook), 192.168.0.11 (HP Printer) and 192.168.17 (Slackware 15.0) are assigned IP addresses by DHCP. The automatic IP assignment pool starts at .20.

Quote:

Final suggestion, you can use up to 3 'd' params when running sshd in debug mode, so 'sshd -ddd -p 2222' will give you the most detail.

Resutls of -ddd. Below is the client side on 192.168.0.17 (QUADMON):

Code:

$ ssh -p 2222 192.168.0.2
The authenticity of host '[192.168.0.2]:2222 ([192.168.0.2]:2222)' can't be established.
ED25519 key fingerprint is SHA256:NheZF6kVf+/todLJtelYF1Vvcccuk1Hz2u0Q0dHZwSE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Warning: Permanently added '[192.168.0.2]:2222' (ED25519) to the list of known hosts.
Connection to 192.168.0.2 port 2222 timed out

and the output of that one connection attempt for sshd on the server side:

Code:

debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 3225
debug2: parse_server_config_depth: config /etc/ssh/sshd_config len 3225
debug3: /etc/ssh/sshd_config:28 setting LogLevel DEBUG
debug3: /etc/ssh/sshd_config:34 setting PermitRootLogin no
debug3: /etc/ssh/sshd_config:35 setting AllowUsers hprsadmin mfoley
debug3: /etc/ssh/sshd_config:44 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:85 setting UsePAM yes
debug3: /etc/ssh/sshd_config:101 setting UseDNS no
debug3: /etc/ssh/sshd_config:112 setting Subsystem sftp /usr/libexec/sftp-server -l INFO -f AUTH
debug1: sshd version OpenSSH_9.3, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ssh-rsa SHA256:5JtPT7KzCs4Xw1+9gsFzqH6OuqitFsaOc2selQX15Rk
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:DLXtM4hOfcJ5mNQVNVAYklXO7Ksr5kagPxwXecQclPc
debug1: private host key #2: ssh-ed25519 SHA256:NheZF6kVf+/todLJtelYF1Vvcccuk1Hz2u0Q0dHZwSE
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2222'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 3225
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug3: recv_rexec_state: entering fd = 5
debug3: ssh_msg_recv entering
debug3: recv_rexec_state: done
debug2: parse_server_config_depth: config rexec len 3225
debug3: rexec:28 setting LogLevel DEBUG
debug3: rexec:34 setting PermitRootLogin no
debug3: rexec:35 setting AllowUsers hprsadmin mfoley
debug3: rexec:44 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: rexec:85 setting UsePAM yes
debug3: rexec:101 setting UseDNS no
debug3: rexec:112 setting Subsystem sftp        /usr/libexec/sftp-server -l INFO -f AUTH
debug1: sshd version OpenSSH_9.3, OpenSSL 1.1.1w  11 Sep 2023
debug1: private host key #0: ssh-rsa SHA256:5JtPT7KzCs4Xw1+9gsFzqH6OuqitFsaOc2selQX15Rk
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:DLXtM4hOfcJ5mNQVNVAYklXO7Ksr5kagPxwXecQclPc
debug1: private host key #2: ssh-ed25519 SHA256:NheZF6kVf+/todLJtelYF1Vvcccuk1Hz2u0Q0dHZwSE
debug1: inetd sockets after dupping: 3, 3
debug3: process_channel_timeouts: setting 0 timeouts
debug3: channel_clear_timeouts: clearing
Connection from 192.168.0.17 port 45356 on 192.168.0.2 port 2222 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_9.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.3
debug1: compat_banner: match: OpenSSH_9.3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 18656
debug3: preauth child monitor started
debug3: privsep user:group 33:33 [preauth]
debug1: permanently_set_uid: 33/33 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug3: append_hostkey_type: ssh-rsa key not permitted by HostkeyAlgorithms [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug3: receive packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: local server KEXINIT proposal [preauth]
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256 [preauth]
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
debug2: compression ctos: none,zlib@openssh.com [preauth]
debug2: compression stoc: none,zlib@openssh.com [preauth]
debug2: languages ctos:  [preauth]
debug2: languages stoc:  [preauth]
debug2: first_kex_follows 0  [preauth]
debug2: reserved 0  [preauth]
debug2: peer client KEXINIT proposal [preauth]
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c [preauth]
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256 [preauth]
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
debug2: compression ctos: none,zlib@openssh.com,zlib [preauth]
debug2: compression stoc: none,zlib@openssh.com,zlib [preauth]
debug2: languages ctos:  [preauth]
debug2: languages stoc:  [preauth]
debug2: first_kex_follows 0  [preauth]
debug2: reserved 0  [preauth]
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug3: receive packet: type 30 [preauth]
debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug3: mm_sshkey_sign: entering [preauth]
debug3: mm_request_send: entering, type 6 [preauth]
debug3: mm_sshkey_sign: waiting for MONITOR_ANS_SIGN [preauth]
debug3: mm_request_receive_expect: entering, type 7 [preauth]
debug3: mm_request_receive: entering [preauth]
debug3: mm_request_receive: entering
debug3: monitor_read: checking request 6
debug3: mm_answer_sign: entering
debug3: mm_answer_sign: ssh-ed25519 KEX signature len=83
debug3: mm_request_send: entering, type 7
debug2: monitor_read: 6 used once, disabling now
debug3: send packet: type 31 [preauth]
debug3: send packet: type 21 [preauth]
debug2: ssh_set_newkeys: mode 1 [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug3: send packet: type 7 [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug3: receive packet: type 21 [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug2: ssh_set_newkeys: mode 0 [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug3: receive packet: type 5 [preauth]
debug3: send packet: type 6 [preauth]
Connection closed by 192.168.0.17 port 45356 [preauth]
debug1: do_cleanup [preauth]
debug3: PAM: sshpam_thread_cleanup entering [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive: entering
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: Killing privsep child 18656

Quote:

Originally Posted by scasey

My guess was wrong, then. Sorry.
What are the permies of the ~/.ssh directory for the user on DC1?

Code:

# ls -ld /home/mfoley/.ssh
drwx------ 2 mfoley users 4096 2023-12-06 08:54 /home/mfoley/.ssh/

# ls -lR /home/mfoley/.ssh
/home/mfoley/.ssh:
total 8
-rw------- 1 mfoley users 913 2023-12-06 09:06 known_hosts
-rw------- 1 mfoley users  89 2023-12-06 08:54 known_hosts.old

Note: after all this I tried setting the DC1 IP to 192.168.0.5 and 'last' still shows connecting as 192.168.0.0. I wonder if this is because DC1 is a Samba domain controller? In smb.conf is "dns forwarder = 192.168.0.1', which I thought was just the DNS it used for name resolution.

I'll try some more experiments turning off Samba, etc.

thinknix · 12-06-2023, 06:58 PM

Client end:

Quote:

Connection to 192.168.0.2 port 2222 timed out

Server end:

Quote:

Connection closed by 192.168.0.17 port 45356 [preauth]

Is that timeout new? And it seems the client is the one closing the connection, not the server. It may be that the reply packets from the server are never making it back to the client, resulting in a timeout and eventual connection close. Does the server have a second network interface?

If you haven't already, you should check basic network connectivity with a ping and traceroute from .17 to .2, and take a look at the routing table on the server.

mfoley · 12-06-2023, 07:18 PM

more info ...

As mentioned, changing the IP on DC1 to 192.168.0.5 did nothing and on QUADMON 'last' still showed connecting as 192.168.0.1.

Next I turned off samba and put 192.168.0.1 (the router) into /etc/resolv.conf. No different.

Lastly, I tried setting DC1 to solicit an IP address from DHCP. That worked. So, the previous setup (which worked remotely) was (Slackware config):

Code:

# Config information for eth0:
IPADDR[0]="192.168.0.2"
NETMASK[0]="255.255.255.248"
IPALIASES[0]=""
USE_DHCP[0]="no"
DHCP_KEEPRESOLV[0]="yes"
DHCP_HOSTNAME[0]=""

GATEWAY="192.168.0.1"

With the above, I could ssh to any host on the LAN, or public, but I could not ssh from a LAN host to DC1.

The DHCP enabled config is:

Code:

IPADDR[0]=""
NETMASK[0]=""
IPALIASES[0]=""
USE_DHCP[0]="yes"
DHCP_KEEPRESOLV[0]="yes"
DHCP_HOSTNAME[0]=""

GATEWAY=""

Now I can ssh from LAN hosts to DC1.

Why?

For the purposes of staging DC1 as a Samba Domain Controller, I'd really like to set a static IP of 192.168.0.2 as that will be its IP in production. What would prevent ssh from connecting to static IP 192.169.0.2 but not to dynamic IP 192.168.0.126?

later ...

I just tried setting the static IP to 192.168.0.126, netmask 255.255.255.0 (see 1st config example), and that also works!

Next, I set the static IP to 192.168.0.2 with netmask 255.255.255.0. And that is now working. Could it have been that netmask 255.255.255.248 was too restrictive (I'm not that knowledgeable about netmasks, the .248 was just copied from the current production Domain Controller).

thinknix · 12-07-2023, 08:11 AM

Quote:

Originally Posted by mfoley

Next, I set the static IP to 192.168.0.2 with netmask 255.255.255.0. And that is now working. Could it have been that netmask 255.255.255.248 was too restrictive (I'm not that knowledgeable about netmasks, the .248 was just copied from the current production Domain Controller).

Yep, that is the issue. 255.255.255.248 is a /29 netmask, which only allows 6 usable hosts in the subnet - in this case 192.168.0.1 to 192.168.0.6. The .17 IP is outside of this subnet, so the server could not route replies to the client. It worked for the opposite direction because the default gateway of .1 is within the /29 subnet, and with SNAT the source IP for the SSH traffic appears as 192.168.0.1 to the server end.

thinknix · 12-07-2023, 08:18 AM

Btw, ipcalc is a handy little utility that is packaged for most distros that does the netmask calculations for you:

Code:

ipcalc 192.168.0.2/255.255.255.248
Address:   192.168.0.2          11000000.10101000.00000000.00000 010
Netmask:   255.255.255.248 = 29 11111111.11111111.11111111.11111 000
Wildcard:  0.0.0.7              00000000.00000000.00000000.00000 111
=>
Network:   192.168.0.0/29       11000000.10101000.00000000.00000 000
HostMin:   192.168.0.1          11000000.10101000.00000000.00000 001
HostMax:   192.168.0.6          11000000.10101000.00000000.00000 110
Broadcast: 192.168.0.7          11000000.10101000.00000000.00000 111
Hosts/Net: 6                     Class C, Private Internet