Nano ssh-server disconnect the ssh tunnel after 18mn

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hi,
I use the jetson nano as a remote machine installed in a rolling robot. I communicate with the robot via a tunnel ssh over the wifi network. Everything works well. When the robot enters in a no-wifi zone for a short time, it’s also OK : the communication stops during this time and resume correctly. But the robot enters in a no-wifi zone for a time > 18minutes, the the ssh-server closes the ssh tunnel ! I dont understand why because I ve parametrize the sshd_config file to create a permanent ssh tunnel (see below).
For information I use the INTEL Wifi AC8265 board, but except for this issue, this board works very well.
The disconnection problem is easy to replicate on Nano:

  • connect a terminal (like putty) from an HOST to the nano board
  • On nano board, type the command “w” listing the connected and you can see the HOST connected
  • On nano, disconnect the wifi for a while (> 18min) and then reconnect the wifi
  • On nano board, type the command “w” and you can see that the HOST connection has been removes by ssh-server.

Here is the complete sshd_config file:

$OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

This is the sshd server system-wide configuration file. See

sshd_config(5) for more information.

This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

The strategy used for options in the default sshd_config shipped with

OpenSSH is to specify options with their default value where

possible, but leave them commented. Uncommented options override the

default value.

Port 2223
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

Ciphers and keying

#RekeyLimit default none

Logging

#SyslogFacility AUTH
#LogLevel INFO

Authentication:

LoginGraceTime 60m
#PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 20
MaxSessions 30

#PubkeyAuthentication yes

Expect .ssh/authorized_keys2 to be disregarded by default in future.

#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

Change to yes if you don’t trust ~/.ssh/known_hosts for

HostbasedAuthentication

#IgnoreUserKnownHosts no

Don’t read the user’s ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes
#PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Kerberos options

#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
TCPKeepAlive no
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 0
ClientAliveCountMax 0
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 20:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

no default banner path

#Banner none

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

override default of no subsystems

Subsystem sftp /usr/lib/openssh/sftp-server

if somebody can help me to find out where the issue come from …
regards, Bernard

3

Does it worked for any others platform. I don’t think it will recovery to connect if network disconnect a long time.

1 Like
5

what do you mean by “other platforms”?
other jestson platforms ? In this case the answser is Yes: I tried with another nano=> same result…disconnected by ssh-server after 18/19min.
bernard

6

I mean any no Jetson platform like PC or Pi?

7

Hi,

What we want to know is that if you can find a non-jetson platform/PC and set ssh channel opened longer than this.

8

Thanks Wayne,
I dont get any other platform on ubuntu to perform a test.
I just dont understand why the client if kicked out when in theory he should stay connected permanently.
I performed test on several days to find out the issue without succes. I explored the pam, the lowpower mode of wifi board, all forum speaking of ssh-server.

Regards
Bernard

9

@bf1
the solution is to use screen

sudo apt install screen
screen

then after the connection abruption it is possible to resume the screen session that doesn’t abrupt on the conenction termination

screen -ls #shows existing sessions
screen -r  345# resumes session 345
1 Like
10

Hi Andrey,
Do you know if I can use screen without the ubuntu gnome GUI (not used in may app) ?
And also if I can launch a program in a screen remotely with ssh (as I do today) ?

Bernard

11

I use screen a lot via ssh. Screen itself is a text terminal program which has no need for GUI. If you get disconnected (e.g., internet fails), then you can come back later with ssh and continue. To forward a GUI program ssh itself would need to you the “-X” or “-Y” option. If for example you use “ssh -Y someone@somewhere.com”, and then run “xterm”, the terminal should show up locally. If instead you use that same ssh -Y and run screen, followed by xterm, then xterm should still pop up locally. Naturally, if you lose the internet, the forwarded content will fail. However, if you were to detach from screen while screen runs xterm forwarded, then the forwarded xterm should remain up.

Give it a try after “sudo apt-get install screen”.

12

thanks

13

@bf1 yes, it is convenient to run headless background execution with screen from a remote computer,
as it allows to reconnect to the text terminal later after disconnection
it is similar to docker attach command
for GUI execution there are X sessions that do not require the screen
reference: screen(1) - Linux man page