ProxyJump
Skočit na navigaci
Skočit na vyhledávání
Na otevřené porty strojů, nepřístupných z vnější sítě, se lze dostat buď přes VPN[1], nebo skrz SSH proxy – počítač, který má z vnější sítě dostupný SSH port. V rámci laboratorní infrastruktury DCE a DC je pro tento účel vyhrazen disklessový virtuál postel, který má, stejně jako všechny laboratorní disklessové stroje které využívají overlay, specifika, která je nutno vzít na vědomí:
- Jako všechny laboratorní stroje DCE, se na něj uživatel přihlašuje tzv. hlavním heslem ČVUT[2] vůči doméně MS.[3]
- Bezprostředně po restartu či spuštění každého stroje co používá overlay, pokus o připojení přes ssh bude končit neúspěšně s následující chybou připojení:
user@machine:~$ ssh <username>@<remote_diskless> channel 0: open failed: connect failed: Connection refused stdio forwarding failed Connection closed by UNKNOWN port 65535
- Je to tím, že systemd, spouští služby paralelně a síť nahazuje dřív než ostatní služby na který je závislé nahození sshd. Například nslcd musí nejprve získat z MS AD aktuální seznam uživatelů. Disklessový stroj ho při spuštění nemá, nebo (pokud se vyskytuje v rámci některé vrstvy na straně NFS serveru) je expirovaný, takže ho musí získat znovu. Proto vzniká prodleva mezi spuštěním ssh a zobrazením dialogu pro zadání hesla. Ta se může projevit i v situaci, kdy se přihlašujete na disklessový stroj, který je spuštěný delší dobu, aniž by se před vámi na něj někdo přihlašoval.
- K přihlašování lze používat i SSH klíče. Stačí si do souboru
~/.ssh/authorized_keys[4] naimportovat svůj veřejný SSH klíč. Ovšem pamatujte, že pro první přihlášení na čerstvě nabootovaný disklessový stroj SSH klíč použít nelze!
- Z jednoduchého důvodu. K připojení uživatelského adresáře sdíleného přes NFS dojde až po úspěšném ověření. SSH klíč v tuhle chvíli nelze použít, protože váš soubor
~/.ssh/authorized_keysještě není k dispozici.[5] - Poznámka: Původně se po ukončení poslední instance měl uživatelský adresář odpojit, ale to se ukázalo jako kontraproduktivní a zbytečný krok. Nicméně sdílení uživatelského adresáře má i své nevýhody, protože si do něj některé aplikace, jako např. singularity, ukládají seznam spuštěných instancí což pak dělá problém, pokud je stejná aplikace souběžně použita i na jiných strojích.
- Pamatujte, že jde o laboratorní infrastrukturu, kde každé přihlášení zanechává dohledatelnou stopu, protože se po ověření zjišťuje, zda uživatelský adresář existuje nebo ne, což je akce, která se z diagnostických důvodů loguje. Existuje tedy záznam, s časovým razítkem, který umožňuje dohledat kdo, kdy a kam se přihlásil. Takže i když se všechny logy strojů co používají overlay při restartu zahodí, existuje cesta, jak odhalit případné zneužití uživatelského účtu.
Praktické využití SSH proxy k přihlášení na vzdálený stroj remote_machine ve vnitřní síti:
~$ ssh <username>@<remote_machine> -J <username>@<ssh_proxy>
Zjednodušit si to můžete tím, že su do souboru .ssh/config uvedete následující konfigurační nastavení (číslo portu pochopitelně závisí na tom, kde na SSH proxy naslouchá sshd):
Host remoteserver HostName <remote_machine> User <username> IdentityFile ~/.ssh/<your_key> Port 2048
## sample for ProxyJump ProxyJump <username>@<ssh_proxy>
## sample for ProxyCommand ProxyCommand ssh -W %h:%p <ssh_proxy>
A přihlašování pak bude vypadat takto:
~$ ssh remoteserver
Pokud si vystačíte se CLI, nic víc nepotřebujete. Ovšem pokud budete chtít ze stroje remote_machine protunelovat port 1234, musíte si pomoct tím, že si nejdřív uděláte tunel:
~$ ssh -N -L 1234:<remote_machine>:1234 remoteserver
…a pak zavoláte aplikaci, která pře něj půjde, např. xtightvncviewer:
~$ xtightvncviewer localhost:1234
Pokud se ale potřebujete přihlašovat na více strojů, které chcete obsluhovat skriptem, můžete nastavit stejné parametry pro celý subnet, který je v tomto případě pochopitelně pouze ukázkový:
Host 10.0.33.*
ForwardX11 yes
proxyjump <username>@<ssh_proxy>
compression yes
forwardagent yes
user root
A přihlašovat se pak můžete přímo na libovolný stroj příslušného subnetu, např.:
~$ ssh <username>@10.0.33.45
- ↑ Jak se lze připojit přes VPN ze dozvíte prostřednictvím stránky kde je mimo jiné odkaz i na webovou stránku k fakultní VPN FEL (dostupnou po přihlášení), která je doporučená.
- ↑
Ověřování hlavním heslem ČVUT má výhody i nevýhody:
- Za výhodu lze považovat, že tuhle funkcionalitu může využít každý, kdo má v rámci ČVUT zřízen uživatelský účet, bez ohledu na to na jaké fakultě či katedře působí. Ovšem s tímhle heslem se dostanete jen do laboratorní sítě DCE, ale dál už ne.
- Výhodné je také to, že není potřeba žádné jiné heslo. Na druhou stranu, čím více služeb, co vyžadují ověření hlavním heslem, tím vyšší pravděpodobnost, že dojde k jeho kompromitaci. A pokud k tomu dojde, může dojít k preventivnímu zablokování přístupu do všech služeb ČVUT, které s ním pracují.
- Hlavní heslo má nastaven čas expirace, takže pokud si ho uživatel zapomene zavčas změnit nebo skončí jeho vazba na ČVUT, do vnitřní sítě se nedostane, přestože bude mít v rámci svého uživatelského účtu stále platný ssh klíč.
- ↑ Stroje DC se ověřují vůči LDAP serveru, který je součástí disklessové infrastruktury. Přihlašování na tyto stroje tedy není závislé na dostupném připojení k MS AD a funguje i pokud dojde k přerušení konektivity mezi areálem ČVUT na Karlově náměstí a Dejvicemi.
- ↑ Jde o soubor v rámci uživatelského profilu sdíleného přes NFS v rámci celé laboratorní infrastruktury
- ↑ Technicky by to sice bylo možné poměrně jednoduše vyřešit – aplikací overlaye, ale tím by se zbytečně otevřel prostor k možnému zneužití. Vrstvy, ze kterých je sestaven sendvič u strojů disklessové infrastruktury, jsou exportované přes NFSv3 výlučně v režimu Read-Only. Uživatelské adresáře, které se mountují jako Read-Write, jsou sdílené přes NFSv4 ze stroje NetApp. Jedině stroj ghost a přes který se zakládájí dosud neexistující uživatelské profily, k nim má přístup přes NFSv3. Ovšem jeho lokální uživatel 'nfshomecreator', který před pokusem o založení uživatelského adresáře kontroluje jeho existenci, do nexistujícího profilu přístup nemá.