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 -

11
  • 1
    Is there a reason that you use screen to run the ssh instance? Does the problem persists if you do not?
    – Tom Yan
    Commented Jun 26, 2021 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 Commented Jun 26, 2021 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 patrickmn.com/aside/how-to-keep-alive-ssh-sessions and superuser.com/questions/37738/…
    – Tom Yan
    Commented Jun 26, 2021 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
    Commented Jun 26, 2021 at 15:52
  • 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. Commented Jun 27, 2021 at 15:55

0

You must log in to answer this question.

Browse other questions tagged .