Reverse SSH tunnel valt uit?

[Opifex]

Dag allen,

Allereerst, vergeef me als dit topic meer in NOS thuis hoort dan in Netwerken, maar op dit moment is het me nog onduidelijk of mijn probleem een netwerkprobleem is, of eerder iets Linux-gerelateerd.

Ik heb thuis een HA server draaien op een Raspberry Pi 4. Om aan deze server te kunnen van buitenaf, zonder poorten open te zetten in de firewall, en zonder een VPN te moeten gebruiken, heb ik via een goedkope VPS een reverse SSH tunnel geopend zodat ik deze kan bereiken.
(Hierna kan ik dan een local SSH forwarding doen om op die manier ook aan de app of browser te geraken, maar dat terzijde)

Deze oplossing werkt prima. Zowel de reverse tunnel als de forwarding in de andere richting kan ik opzetten en gebruiken. (Voor een leek als ik verbaast het me zelfs dat het zo eenvoudig was...)

Echter, er is één probleem: het lijkt alsof de SSH tunnel na enige tijd verbroken wordt. Ik kan dan nog wel rechtstreeks in de server vanop het lokale netwerk: ik zie via

code:

ps -ef | grep ssh

dat er nog steeds een process draait voor de tunnel, en ook systemd geeft aan dat alles nog "running" is, maar toch... werkt het niet. Als ik dan via systemd een restart command geef werkt alles weer prima.
Er loopt dus duidelijk iets mis met de tunnel. Maar wat...?
Journalctl geeft ook niets van relevante informatie weer.

De tunnel wordt als volgt opgezet:

code:

ssh -N -R <externe_poort>:localhost:22 <vps_user>@<vps_ip> -p <ssh_port_vps>

Via de tunnel met de server verbinden gaat dan als volgt:

code:

ssh <server_user>@<vps_ip> -p <externe_poort>

In de systemd service staat het volgende:

code:

[Unit]
Description=Reverse SSH connection

[Service]
Type=ExecStart

ExecStart=<path_to_>/create_ssh_tunnels.sh
Restart=always
RestartSec=10s
User=<server_user>
SyslogIdentifier=ssh-tunnels


[Install]
WantedBy=multi-user.target

Iemand enig idee wat hier zou kunnen mislopen, of waar ik best zou kunnen zoeken?

Alvast bedankt!

[Noob_Saibot]

Je huidige service heeft Type=simple nodig (niet ExecStart), en mogelijk een KillMode om zombies te voorkomen:

code:

[Unit]
Description=Reverse SSH connection

[Service]
Type=simple
ExecStart=<path_to>/create_ssh_tunnels.sh
Restart=always
RestartSec=10s
User=<server_user>
SyslogIdentifier=ssh-tunnels
# Voeg toe om zombies te voorkomen:
KillMode=process

[Install]
WantedBy=multi-user.target

[Opifex]

Thanks @Noob_Saibot ! Ik heb het aangepast. Nu afwachten of het gewerkt heeft...

Ik probeerde uit te vissen wat nu juist het verschil is tussen `Type=simple` en `Type=ExecStart`. Tot mijn verbazing stond ExecStart nergens tussen de opties in de documentatie? Wil dat zeggen dat ExecStart als optie niet bestaat, en dit in den beginne al fout is?

[Noob_Saibot]

ExecStart specificeert het hoofdprogramma of script dat door de service wordt uitgevoerd.
In jou geval (als voorbeeld):

code:

[Service] ExecStart=/home/pi/create_ssh_tunnels.sh

Gebruik absolute paden en zorg voor uitvoerrechten, kies de juiste Type= (meestal simple voor scripts).

[Opifex]

Noob_Saibot schreef op maandag 9 juni 2025 @ 14:04:
ExecStart specificeert het hoofdprogramma of script dat door de service wordt uitgevoerd.

Dit had ik door. Want dat gebruikte ik ook in het bovenstaande script
Maar het is me niet duidelijk of dat als "Type" ook bestaat, of nu net niet?

In jou geval (als voorbeeld):

code:

[Service] ExecStart=/home/pi/create_ssh_tunnels.sh

Gebruik absolute paden en zorg voor uitvoerrechten

Geen zorgen! Dat is het geval In bovenstaande heb ik het pad vervangen met een placeholder. Het is in dit geval namelijk niet '/home/pi'

[ Voor 4% gewijzigd door Opifex op 09-06-2025 14:21 ]

[Kabouterplop01]

Ik denk dat je ook een keepalive moet instellen ergens.
de standaard timeout van een tcp sessie waar niets overheen gaat is een uur.
dus je moet zorgen dat de pi om de zoveel tijd even een pakketje verstuurt.

[Opifex]

Helaas, de verbinding werd nog steeds verbroken.

Kabouter Plop's suggestie klinkt wel veelbelovend.

Kabouterplop01 schreef op maandag 9 juni 2025 @ 17:04:
Ik denk dat je ook een keepalive moet instellen ergens.
de standaard timeout van een tcp sessie waar niets overheen gaat is een uur.
dus je moet zorgen dat de pi om de zoveel tijd even een pakketje verstuurt.

Waar of hoe zou je voorstellen dit te doen? In systemd? Op het internet vind ik namelijk duizend en één manieren die voorgesteld worden.

Ik heb nu deze opties proberen toe te voegen aan het commando van de tunnel:

code:

-o ConnectTimeout=0 -o ServerAliveInterval=60 -o TCPKeepAlive=yes

Zou dit kunnen werken?

[Kabouterplop01]

Goede vraag, als het een beschreven optie is uit de manual dan vooral proberen.
Ik weet het niet.
In Putty kun je dat met de -k flag doen in de commandline -k 60 geeft dan elke 60s een pakketje.
Ik zou elke minuut een pakketje sturen ofzoiets.

[ Voor 11% gewijzigd door Kabouterplop01 op 11-06-2025 18:44 ]

[synoniem]

Je kan de poor man's vpn sshuttle proberen.

[Opifex]

@synoniem Bedankt voor de suggestie! Ik ga deze zeker in het achterhoofd houden voor de toekomst, maar in dit geval was het net de bedoeling om géén volledige VPN te maken. Ik wil slechts één server toegankelijk maken vanop afstand. En dan alleen voor apparaten met een geauthorizeerde SSH key.

@Kabouterplop01 Met bovenstaande opties heeft het toch alleszins al enkele dagen draaiende gebleven. Ik denk dat het dat'm dus was.
Ondanks dat de reacties van @Noob_Saibot zeer nuttig waren denk ik dat jouw reactie dan toch moet gemarkeerd worden als "Beste antwoord", omdat jij het ontbrekende puzzelstuk had


Intussen heb ik de verbinding wel alsnog uitgeschakeld. Toen ik m'n vriendin haar telefoon ook aan het prepareren was realiseerde ik me dat iedereen dan via een root account zou passeren... dat lijkt me niet de bedoeling. Als één toestel dan gecompromitteerd raakt, is heel je beveiliging zo lek als een zeef.
Ik ben nu aan het kijken om de tunnel te laten opstarten door een dummy-user zonder sudo en shell access. Volgens wat ik lees moet dat lukken met Systemd door het `User` argument in te vullen. Voorlopig nog geen succes. Maar dat is een verhaal apart

Bedankt voor het meedenken allemaal!

[synoniem]

Opifex schreef op zaterdag 14 juni 2025 @ 21:33:
@synoniem Bedankt voor de suggestie! Ik ga deze zeker in het achterhoofd houden voor de toekomst, maar in dit geval was het net de bedoeling om géén volledige VPN te maken. Ik wil slechts één server toegankelijk maken vanop afstand. En dan alleen voor apparaten met een geauthorizeerde SSH key.

@Kabouterplop01 Met bovenstaande opties heeft het toch alleszins al enkele dagen draaiende gebleven. Ik denk dat het dat'm dus was.
Ondanks dat de reacties van @Noob_Saibot zeer nuttig waren denk ik dat jouw reactie dan toch moet gemarkeerd worden als "Beste antwoord", omdat jij het ontbrekende puzzelstuk had


Intussen heb ik de verbinding wel alsnog uitgeschakeld. Toen ik m'n vriendin haar telefoon ook aan het prepareren was realiseerde ik me dat iedereen dan via een root account zou passeren... dat lijkt me niet de bedoeling. Als één toestel dan gecompromitteerd raakt, is heel je beveiliging zo lek als een zeef.
Ik ben nu aan het kijken om de tunnel te laten opstarten door een dummy-user zonder sudo en shell access. Volgens wat ik lees moet dat lukken met Systemd door het `User` argument in te vullen. Voorlopig nog geen succes. Maar dat is een verhaal apart

Bedankt voor het meedenken allemaal!

Voor de duidelijkheid sshuttle werkt op basis van ssh en heeft geen root rechten nodig.

[Opifex]

Gezien de naam is het me geen verrassing dat het op basis van ssh werkt
Het niet hebben van root rechten is fijn, maar je zet dan nog steeds je hele netwerk open. Dat is niet helemaal mijn bedoeling. Ik wil slechts één server verbinden.

Intussen is het gelukt overigens. De service heb ik niet draaiende gekregen als een andere user (het is me een raadsel waarom, want volgens mij moet dat gewoon werken...), maar ik realiseerde me plots dat het in feite niet uit maakt wie de tunnel openzet. Als je in het bezit bent van een geauthorizeerde key, kan je nog steeds op elk account inloggen.
De oplossing zit'm er dus niet in om de tunnel aan te laten maken door een andere user, maar wel door de keys van de apparaten die zullen verbinden niet toe te voegen aan de authorized_hosts van de root, maar wel van de unprivileged user. Ze kunnen dan nog steeds de server bereiken, maar ze kunnen dan niet meer in het root account.