ProxyJump
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.
K přihlášení na vzdálený stroj remote_machine
běžící ve vnitřní síti, skrz SSH proxy, lze na příkazové řádce využít parametr -J:
~$ ssh <username>@<remote_machine> -J <username>@<ssh_proxy>
Ovšem s direktivou ProxyJump lze přihlašování zjednodušit, pokud si do souboru .ssh/config
uděláte záznam pro vzdálený stroj remote_machine
(číslo portu pochopitelně závisí na tom, kde na SSH proxy naslouchá sshd):
Host remoteserver HostName <remote_machine> User <username> IdentityFile ~/.ssh/<your_key> ProxyJump <username>@<ssh_proxy> Port 2048
K přihlášení pak bude stačit pouze tohle:
~$ ssh remoteserver
V tomhle případě, se vzdálený stroj zeptá na heslo – pokud si do uživatelského profilu naimportujete svůj SSH klíč – pouze jednou. Viz níže uvedená specifika strojů co používají overlay v sekci Vezměte na vědomí |
Tunelování portů
Pokud si vystačíte se CLI, nic víc, než to co bylo uvedeno výše, 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 4321:<remote_machine>:1234 remoteserver
…a pak zavoláte aplikaci, která jím proleze přes lokální port 4321
na otevřený port 1234
na stroji remote_machine
. Např. xtightvncviewer, pokud je to port, na kterém čeká spuštěný VNC server:
~$ xtightvncviewer localhost:4321
Nastavení pro všechny stroje určitého subnetu
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
Vezměte na vědomí
Že SSH proxy, virtuální stroj postel, má – stejně jako všechny laboratorní disklessové stroje, které využívají overlay – specifika, která je nutno vzít na vědomí:
Tato SSH proxy je součástí laboratorní infrastruktury, kde každé přihlášení zanechává dohledatelnou stopu, protože se vždy po ověření zjišťuje, zda uživatelský adresář existuje nebo ne, což je operace, která se z diagnostických důvodů loguje. O každém přihlášení tedy existuje dohledatelný záznam, s časovým razítkem, který umožňuje zpětně analyzovat kdo, kdy a na kterém stroji pracoval – i přes to, že se všechny změny na strojích co používají overlay při restartu zahodí. |
Poznámky
- ↑ 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á.