GNU/Linux >> Znalost Linux >  >> Linux

Vyžaduje se informace/pomoc při zpětném tunelování Ssh (konvence pojmenování atd.)?

Mám několik malinových pi's se systémem Arch Linux (bez GUI), ke kterým potřebuji přístup. Tyto pí jsou za firewally v každém jedinečném místě. V současné době používám k připojení openvpn, ale náklady na tento systém jsou drahé na licenci. Používám přístupový server od nich.

V důsledku toho se snažím navrhnout a nastavit systém, který mi umožní přihlásit se k mému serveru VPN (vps) a spustit příkaz k vyhledání konkrétního jména (OfficeDevice1991), jako je:customcommandsearch "OfficeDevice1991" a pak vrátí IP adresu stroje nebo něco, co mohu použít k SSH. Také hledám možnost spustit příkaz pro výpis všech aktivních připojených zařízení. Uvádí zpět IP, jméno a možná, jak dlouho je aktivní.

Pro tento cíl samozřejmě musím vytvořit něco, co bude obsahovat název zařízení (v tomto případě OfficeDevice1991) a pak se bude moci připojit k mému veřejnému serveru vps. Z veřejného serveru se mohu přihlásit a prohledat každé zařízení k němu připojené a vrátit informace potřebné pro ssh.

Díval jsem se na reverzní SSH a zatím se mi připojil jeden z mých testovacích pi a je přístupný z mého vps pomocí následujících příkazů:

PI:

ssh -fN -R 12345:localhost:22 -i /publickeyfile [email protected] //Pi's command to connect to vpn

VPS:

ssh -p 12345 [email protected] //command for vpn to connect to pi

Funguje to skvěle, ale při použití této metody, pokud bych ji měl implementovat, bych narazil na několik problémů:

  1. Potřeboval bych nastavit jedinečné nepoužívané porty
  2. Nějaký způsob, jak udržet tyto porty/tunely otevřené
  3. Potřebuji vymyslet systém pro identifikaci každého zařízení. Mohu lokálně přihlásit každý port pod názvem jako textový soubor? Bylo by prospěšné, kdyby to bylo možné zahrnout do nastavení ssh pro každé zařízení, pokud je to možné. Stále bych se potřeboval ujistit, že porty, které používám, nejsou používány žádnými jinými programy nebo zařízeními, které již existují.

Co nechci dělat

  1. Zkontrolujte, jaké porty lze zdarma použít pro jednotlivé RPI

  2. Musíte ručně upravit .ssh/config přidat název reprezentující každý port přiřazený k RPI z části 1 výše.

Píši to pro informaci/pomoc, co dělat pro svůj cíl.

Mohl by mi někdo poskytnout vhodné řešení?

Přijatá odpověď:

Zde je řešení využívající OpenSSH>=6.7 + socat:

  1. OpenSSH>=6.7 může používat předávání soketů domén Unix

    To znamená, že koncovým bodem zpětného tunelu bude naslouchací soket UNIX namísto tradičního naslouchacího soketu TCP. Pak můžete snadněji spravovat flotilu RPI pomocí jednoduchého schématu pojmenování:název soketu bude zvolený (a pevný) název RPI, jako OfficeDevice1991 . Může to být dokonce jedinečná vlastnost z RPI, pokud je to platný název souboru (protože názvy soketů unix dodržují konvence pro názvy souborů). Například jeho název hostitele, MAC adresa jeho ethernetové nebo wifi karty …

    SSH zvládne unixové sockety pro tunely, nikoli pro samotné připojení. Bude potřebovat pomoc ProxyCommand být schopen pracovat jako unix-socket klient. socat zvládne mnoho druhů připojení, včetně unixových soketů.

    AKTUALIZACE:
    Je zde také jeden konkrétní problém, který je třeba vyřešit:soubor soketu unix se při čistém ukončení neodstraní, ani by nebyl smazán tak jako tak, například po havárii. To vyžaduje volbu StreamLocalBindUnlink=yes . Zpočátku jsem nezjistil, že jak název možná napovídá, tato možnost musí být nastavena na uzlu vytvářejícím unixový soket. Nakonec je tedy nastaven na klientovi pomocí místního přesměrování (-L ) nebo jinak na serveru (v sshd_config ) se vzdáleným přesměrováním (-R ). OP to tam našel. Toto řešení využívá vzdálené předávání.

    Konfigurace na VPS:

    mkdir /rpi-access
    

    (jako root) upravte sshd_config soubor (/etc/ssh/sshd_config ). Vyžaduje tuto další možnost:

    StreamLocalBindUnlink yes
    

    V závislosti na výchozích možnostech může také vyžadovat AllowStreamLocalForwarding yes

    UPDATE2:
    Nastaveno také v sshd_config parametry ClientAliveInterval a ClientAliveCountMax , což umožňuje detekovat odpojení v rozumném čase, např.:

    ClientAliveInterval 300
    ClientAliveCountMax 2
    

    Zastaralá připojení ssh by pak měla být na VPS detekována dříve (~10 minut s příkladem) a příslušný proces sshd se poté ukončí.

    Použití na RPI:

    ssh -fN -R /rpi-access/OfficeDevice1991:localhost:22 -i /privatekeyfile [email protected]
    

    V konfiguračním souboru by to bylo podobné tomuto:

    Host ip
    User useraccount
    RemoteForward /rpi-access/OfficeDevice1991:localhost:22
    IdentityFile /privatekeyfile
    

    Opakuji to znovu:StreamLocalBindUnlink yes nastavit na sshd na straně VPS Volba je důležitá:právě vytvořená zásuvka není odstraněna ani při normálním ukončení. Tato možnost zajišťuje, že zásuvka je před použitím odstraněna, pokud existuje, a umožňuje tak její opětovné použití pro další opětovné připojení. To také znamená, že pouhou přítomnost zásuvky nelze považovat za připojenou RPI (ale viz později).

    Nyní to umožňuje dělat na VPS:

    ssh -o 'ProxyCommand=socat UNIX:/rpi-access/%h -' [email protected]
    

    Jako konfigurační soubor, vezmeme-li například v úvahu RPI, mají všechny názvy začínající OfficeDevice :

    Host OfficeDevice*
        User rpiuseraccount
        ProxyCommand socat UNIX:/rpi-access/%h -
    
  2. Chcete-li odkaz zachovat, použijte smyčku

    RPI může spustit smyčku, která znovu připojí ssh k VPS, kdykoli spojení skončí. K tomu nesmí používat režim na pozadí (ne -f ). Měl by být také použit mechanismus udržování života. K dispozici jsou TCPKeepAlive (systémová úroveň) nebo ServerAliveInterval (úroveň aplikace). Myslím, že TCPKeepAlive je užitečný pouze na serveru (strana přijímající připojení), takže raději použijme ServerAliveInterval.

    Jeho hodnota (stejně jako ServerAliveCountMax) by měla být pravděpodobně přizpůsobena v závislosti na různých kritériích:firewall, který po určité době ukončí neaktivní připojení, požadované zpoždění obnovy, negenerování zbytečného provozu, ... zde řekněme 300s.

    OfficeDevice1991 RPI:

    #!/bin/sh
    while : ; do
        ssh  -N -o ConnectTimeout=30 -o ServerAliveInterval=300 -R /rpi-access/OfficeDevice1991:localhost:22 -i /privatekeyfile [email protected]
        sleep 5 # avoid flood/DDoS in case of really unexpected issues
    done
    

    I když vzdálená strana dosud nezjistila předchozí selhání připojení a ještě nějakou dobu staré připojení ssh stále běží, StreamLocalBindUnlink yes stejně násilně obnoví unixový socket na nové připojení.

  3. je již zpracováno 1.

    Neexistuje žádné customcommandsearch potřeboval. Se správným nastavením nastaveným v 1. pouze pomocí ssh OfficeDevice1991 se připojí k OfficeDevice1991.

    V případě potřeby na VPS jako root pouze uživatel, tento příkaz:

    fuser /rpi-access/*
    

    může ukázat, která RPI jsou aktuálně připojena (samozřejmě kromě těch, které nedávno ztratily připojení před detekcí). Nezobrazí zastaralé soubory unixového soketu, protože s nimi není spojen žádný proces.

Související:Jak předat obsah souboru jako parametr příkazového řádku?
Linux
  1. Ssh – Omezení uživatele Ssh/scp/sftp na adresář?

  2. Jak nastavit Reverse SSH Tunnel v Linuxu

  3. Nelze spustit X aplikací přes SSH v Linuxu

  1. SSH s autorizovanými klíči do systému Ubuntu se zašifrovaným homedir?

  2. vncserver -localhost a tunelování ssh

  3. ssh stále přijímá ověřování heslem, přestože je nakonfigurováno pouze pro ověřování pomocí veřejného klíče (což funguje!)

  1. Jak používat tunelování SSH pro přístup k omezeným serverům

  2. SSH pomalé při zahájení relace

  3. SSH připojení přes reverzní (vzdálený) SSH tunel