0

I installed a remote Raspberry Pi (Debian up-to-date) camera with a mobile modem-router connected to it to upload photos to a cloud.
That has been working very good in the past and at the present.
To manage the frequency of the photo sequence and other stuff I build a tunnel to my Ubuntu (20-04 up-to-date) desktop computer at home.
This is because the mobile modem-router has all incoming ports closed so I cannot access it directly.
This is the command executed to build the tunnel. (Every minute it is checked to see if it is alive)

/usr/bin/screen -dmS ssh-Ubuntu /usr/bin/ssh -o ExitOnForwardFailure=yes -R 2222:localhost:22 me@no-ip-domain -g

So from my desktop ssh -p 2222 pi@localhost should prompt me to enter the password to login the RPi.
Last year it worked okay with no issues but I am having problems now, it works sometimes.
When it doesn't, prompt to enter the password does not appear.
Using a very useful tool called pitunnel I get ssh access. Anyway I prefer my tunnel because it doesn't have some delays between every typing letter.
That way I see that ps aux | grep SCREEN dumps

pi 2759 0.0 0.2 5788 2084 ? Ss 15:04 0:00 /usr/bin/SCREEN -dmS ssh-Ubuntu /usr/bin/ssh -o ExitOnForwardFailure=yes -R 2222:localhost:22 me@no-ip-domain -g

So the tunnel seems to be built. If I kill 2759 and wait until minute time changes so the cron check build the tunnel again. Then again
ps aux | grep SCREEN dumps

pi 11772 0.0 0.2 5788 2164 ? Ss 16:10 0:00 /usr/bin/SCREEN -dmS ssh-Ubuntu /usr/bin/ssh -o ExitOnForwardFailure=yes -R 2222:localhost:22 me@no-ip-domain -g

after that, password prompt is displayed and I can login successfully.
After logout and a couple of hours I enter into a loop: no prompt to enter the password and so on.

I don't realize why sometimes the password prompt don't shows up if the command and the check script worked in the past and the tunnel seems to be built.

The only change apart of software updates was my desktop router.
I used the same configuration as my old one. In this case:
NAT forwarding -> Service Type=SSH; External and Internal port=22; Internal IP=192.168.1.33; Protocol=All;

Update 1:

netstat / ss -nltp from desktop but at this time trying to enter the tunnel I get

ssh: connect to host localhost port 2257: Connection refused

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 ::1:2222                :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -

Update 2:
Yesterday I added 2 lines to /etc/ssh/ssh_config desktop

ServerAliveInterval 15 
ServerAliveCountMax 4

Today I could use the tunnel but trying again after some time ssh -p 2222 pi@localhost got held several minutes and then output

kex_exchange_identification: read: Connection reset by peer

After some minutes ssh -p 2222 pi@localhost

ssh: connect to host localhost port 2222: Connection refused

netstat / ss -nltp does not show

tcp6       0      0 ::1:2222                :::*                    LISTEN

anymore despite from Pi ps aux | grep Ubuntu shows the task is active

pi        7232  0.0  0.2   5788  2036 ?        Ss   09:17   0:00 /usr/bin/SCREEN -dmS ssh-Ubuntu /usr/bin/ssh -o ExitOnForwardFailure=yes -R 2222:localhost:22 me@no-ip -
Daniel Franco
  • 1
  • 1
    Is there a reason that you use screen to run the ssh instance? Does the problem persists if you do not? – Tom Yan Jun 26 '21 at 13:28
  • In my first construction of this system I needed a second login without breaking the tunnel, then I adopted SCREEN. In my recent tests trying to realize what is happening I avoided SCREEN, just run /usr/bin/ssh -o ExitOnForwardFailure=yes -R 2222:localhost:22 me@no-ip-domain -g but the issue is still here – Daniel Franco Jun 26 '21 at 14:57
  • Have you checked whether the public IP of the Pi (or the desktop) changed, before and after the tunnel seemingly "collapsed"? Also see https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/ and https://superuser.com/questions/37738/how-to-reliably-keep-an-ssh-tunnel-open – Tom Yan Jun 26 '21 at 15:36
  • Btw have you also checked (e.g. with loginctl, or just check for the listening port with netstat / ss -nltp) on the desktop to see if the tunnel session of the pi is still there? (particularly, perhaps even after you killed the ssh process on the pi?) – Tom Yan Jun 26 '21 at 15:52
  • @TomYan Public IP changes every 12 hours. So the tunnel breaks and keeps "closed" for a couple of minutes. That's why I check the tunnel is alive every minute. If not then then that command runs to build it again. Doesn't seem the internet connection is the issue because ps aux | grep SCREEN reveals the tunnel is open. I'll try the commands you suggest in the other comment when I cannot use the tunnel for a long time (and append the results to my question). I already added Update 1 for loginctl but having the tunnel usable. – Daniel Franco Jun 26 '21 at 16:27
  • "The only change apart of software updates was my desktop router." – This answer. Your new router may be over-zealous in the context of the answer. – Kamil Maciorowski Jun 26 '21 at 16:56
  • @KamilMaciorowski It seems this could be the reason. I'll check those links you and @ TomYan have suggested. I still cannot upvote your comments. – Daniel Franco Jun 26 '21 at 20:41
  • @TomYan I added Update 2 to my question. After posting it I retried login from desktop and it was successful tcp6 0 0 ::1:2257 :::* LISTEN is listed again... and after 1/2 hour the Update 2 loop goes on – Daniel Franco Jun 27 '21 at 15:50
  • 1
    "Yesterday I added 2 lines to /etc/ssh/ssh_config desktop" – ServerAlive* in the config of your desktop OS will affect the ssh connection that is going to use the tunnel, not the tunnel itself. The tunnel is established by a connection where RPi is the client and the desktop is the SSH server, so you need ServerAlive* in ssh_config of RPi or ClientAlive* in the sshd_config of the desktop computer. – Kamil Maciorowski Jun 27 '21 at 15:55
  • I see. I first had added ClientAlive* in ssh_config of my desktop computer and got an error so I changed it by ServerAlive* but ClientAlive* should be in sshd_config (and restart service) – Daniel Franco Jun 27 '21 at 16:09
  • After some hours of sshd_config adds it seems to be normal again. Thanks. – Daniel Franco Jun 27 '21 at 23:23

0 Answers0