SSH via jumpserver voor alles

[aawe mwan]

Mijn oude Synology NAS zit niet rechtstreeks op internet aangesloten, dus als ik er buitenshuis bij wil dan moet dat via mijn jumpserver. Nog maar pas heb ik ontdekt dat je voor SSH verbindingen heel eenvoudig kunt configureren dat ze volautomatisch via een jumpserver lopen.

In bestand /etc/ssh/ssh_config.d/10-🦘.conf heb ik bijvoorbeeld onder andere staan:

code:

Host nas diskstation
  Hostname diskstation
  ProxyJump 🦘
  ForwardX11 no

Sinds ik dit heb, kan ik gewoon ssh diskstation intypen en de computer maakt automatisch eerst via de server met de naam „🦘” een tunnel over internet naar huis en gaat daarover naar de NAS voor de SSH verbinding. Die jumpserver is daarmee ook actief voor onder andere sftp, scp, sshfs en sshuttle.

Dat is veel handiger dan mijn oude oplossingen met scriptjes en local port forwards! Dus die ga ik ombouwen.

Ik twijfel wat de handigste oplossing is voor:

1) Webinterface van de NAS

• Nu loopt dit via een local port forward en kijk ik met de buitenshuis-browser naar https://localhost:5001
• Ik zoek eigenlijk een oplossing die automatisch een tunnel opzet, op het moment dat ik het adres van de NAS oproep in de browser, kan dat?
• Met een sshuttle oplossing (dat is een soort VPN voor een los IPv4-adres) kan ik een verbinding opzetten naar de NAS, maar dat moet dan nog wel handmatig buiten de browser om.
• Zou een SSH SOCKS verbinding handiger zijn en kan ik die in de browser automatisch inschakelen voor alleen de NAS?

2) SMB mounts naar de NAS

• Deze lopen nu ook via een local port forward en omdat het lokale poortnummer kleiner is dan 1024, moet ik het sudo password intypen als ik deze verbinding open.
• De smb shares zijn gedefinieerd in /etc/fstab (en verwijzen daar naar localhost).
  Bestaat er een oplossing dat je een automatische jumphost kunt definieren voor een smb/cifs mount?
• Met sshfs lukt het me om shares te mounten, want dat ondersteunt de NAS ook.

De client waar dit op gebruik draait Ubuntu 21.10, de jumpserver 18.04.

[Thralas]

aawe mwan schreef op zaterdag 11 december 2021 @ 12:45:
• Ik zoek eigenlijk een oplossing die automatisch een tunnel opzet, op het moment dat ik het adres van de NAS oproep in de browser, kan dat?

WireGuard. Dat lost de rest van je problemen ook op.

[daft_dutch]

Thralas schreef op zaterdag 11 december 2021 @ 17:46:
[...]


WireGuard. Dat lost de rest van je problemen ook op.

Op een debian like systeem. Bijvoorbeeld een kleine virtual machine.

code:

curl -L https://install.pivpn.io | bash

En natuurlijk portforward op je gateway.

En dan heb je van uit elke locatie over vpn toegang tot je lokale netwerk.

[_eXistenZ_]

Met OpenVPN op de machine waar je nu een jumhost van gemaakt hebt kun je ook alles bereiken wat je wilt, knal de VPN automatisch aan en je kan bij je NAS alsof je fysiek op hetzelfde netwerk zit

[CAPSLOCK2000]

aawe mwan schreef op zaterdag 11 december 2021 @ 12:45:

• Zou een SSH SOCKS verbinding handiger zijn en kan ik die in de browser automatisch inschakelen voor alleen de NAS?

SSH SOCKS is inderdaad handig om zo'n webinterface te benaderen. Ik gebruik de "foxyproxy" plugin voor Firefox om bepaalde sites via een proxy te laten lopen. Je moet wel zorgen dat de ssh-verbinding al actief is want die kan die plugin niet voor je staat.

[amx]

Het gaat je als ik het goed lees niet zozeer om het ssh verbinden, maar om het combineren van de actie "Openen webinterface NAS" en "verbinding maken met jumphost"


https://www.freedesktop.o...temd-socket-activate.html
http://0pointer.de/blog/p...activated-containers.html

Via systemd kan je een socket maken en hier een actie aan koppelen, bijvoorbeeld een SSH sessie instellen, of (wat ik persoonlijk eerder zou doen) een Wireguard VPN verbinding. SSH is namelijk een TCP verbinding, wat inherent onveiliger is.

[aawe mwan]

@amx Gewoon een VPN openzetten is inderdaad niet de bedoeling. Ik zie dat er een hoek van Unix/Linux is waar ik nog bijna niks van wist, maar waar dit mee zou kunnen. Leuk uitzoekklusje voor de kerstvakantie.

[amx]

https://unix.stackexchang...th-socket-activation-does

Hier staat het beschreven, inclusief een issue met herstarten, omdat openssh niet uitsluitend voor Linux is geschreven.

Ook kan het de moeite waard zijn om een dergelijk proces als container te starten, iets dat systemd ook ondersteunt. Reden is dat de websocket dan met een random userid wordt uitgevoerd en je host machine minder risico loopt.

http://0pointer.de/blog/p...activated-containers.html