Getting kicked out of SSH after 15-20 seconds

[Evan Richardson]

Anyone else having issues with truenas 13 kicking you out of an SSH session after just 15-20 seconds maybe? I can run perhaps 2 commands, before my shell locks up, eventually kicking me out. Even if i run something like "watch zpool iostat -v 1", which runs continuously, i get perhaps 3-4 iterations before it stops responding. The only logs I can seem to find pointing to this is this:

Code:

Jun  7 16:10:53 mediastore.local 1 2022-06-07T16:10:53.698726-07:00 mediastore.local sshd 96207 - - Timeout, client not responding from user root 192.168.4.2 port 54280
Jun  7 16:54:47 mediastore.local 1 2022-06-07T16:54:47.673096-07:00 mediastore.local sshd 82764 - - Accepted password for root from 192.168.4.2 port 34476 ssh2
Jun  7 16:56:14 mediastore.local 1 2022-06-07T16:56:14.523747-07:00 mediastore.local sshd 82764 - - Timeout, client not responding from user root 192.168.4.2 port 34476
Jun  7 17:01:19 mediastore.local 1 2022-06-07T17:01:19.485843-07:00 mediastore.local sshd 27265 - - Accepted password for root from 192.168.4.2 port 47816 ssh2
Jun  7 17:02:38 mediastore.local 1 2022-06-07T17:02:38.603389-07:00 mediastore.local sshd 27265 - - Timeout, client not responding from user root 192.168.4.2 port 47816
Jun  7 21:37:40 mediastore.local 1 2022-06-07T21:37:40.859879-07:00 mediastore.local sshd 84251 - - Accepted password for root from 192.168.4.2 port 39040 ssh2
Jun  7 21:39:04 mediastore.local 1 2022-06-07T21:39:04.884618-07:00 mediastore.local sshd 84251 - - Timeout, client not responding from user root 192.168.4.2 port 39040

also strangely enough, I used to be able to use putty, now putty throws an error:

I looked at the release notes and didnt see any mention of ssh changes, nor can I find anything that stands out in the sshd_config file.

 

[Apollo]

Just wondering if your system isn't rebooting.
I have experienced issues with my backup/test server running TrueNAS 13 and every time I try to connect remotely from my TrueNAS 12 Core server, it is causing TrueNAS 13 server to reboot.

 

[Evan Richardson]

Just wondering if your system isn't rebooting.
I have experienced issues with my backup/test server running TrueNAS 13 and every time I try to connect remotely from my TrueNAS 12 Core server, it is causing TrueNAS 13 server to reboot.

No reboots knock on wood, but having to run any commands via IPMI is a PITA

 

[neofusion]

Are you 100% sure there are no other devices that share the same IP as the client?

 

[Evan Richardson]

Are you 100% sure there are no other devices that share the same IP as the client?

definitely. 192.168.4.2 is my k8s server, the only IP on that subnet (minus an ip of .6 for truenas so it can mount it easier without going across vlans). there are only 2 ips, .2 and .6 (minus .1 for the gateway) This was NOT an issue with truenas 12.x (whatever the latest version was), only started once I upgraded to 13.

 

[Elliot Dierksen]

I agree with @neofusion that this sounds like an IP conflict. Are you on the same IP network as the server? If so, check the arp entry to make sure it isn't changing.

 

[saviodesign]

Personally, I'd suggest starting at the router first to validate and clear up any confusion.

The only time I've experienced this error is when multiple devices have been assigned an identical IP.
This forces the router to hand off a single IP connection and communicate to the first device it sees, and if it sees an IP has been assigned to more than one device, it will stop communication with one and start with the other, then repeat the same process over and over until the conflict has been resolved.

I typically see this mistake when someone has attempted to set up a static connection instead of letting their router's DHCP control things.

If this is your case, to resolve this permanently you'll need a fair understanding of how correctly reserve an IP with a DHCP table:

• Please understand that routers control your network by establishing a network table and providing the first level of security within your home network past the NID (Network Interface Device) aka that grey box outside of your home, or an ONT for those with Fiber connections.
• This also means that you don't need to set a STATIC IP to control which IP lands on a specific device, instead you should leverage an IP Reservations, which functions in a similar fashion by explicitly assigning a specific IP to a device via MAC address.

For a more thorough breakdown of how to perform this task on most home networks, please review this video: DHCP Reservations