ProxyJump: Porovnání verzí
(založena nová stránka s textem „Na otevřené porty strojů, nepřístupných z vnější sítě, se lze dostat buď přes VPN<ref> Jak se lze připojit přes VPN ze dozvíte prostřednictvím [https://ist.cvut.cz/nase-sluzby/pripojeni-z-domova-vpn/ 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á. </ref>, nebo skrz SSH proxy. V rámci laboratorní infrastruktury je pro tento účel vyhrazen disklessov…“) |
mBez shrnutí editace |
||
(Nejsou zobrazeny 2 mezilehlé verze od stejného uživatele.) | |||
Řádek 1: | Řádek 1: | ||
__TOC__ | |||
Na otevřené porty strojů, nepřístupných z vnější sítě, se lze dostat buď přes VPN<ref> | Na otevřené porty strojů, nepřístupných z vnější sítě, se lze dostat buď přes VPN<ref> | ||
Jak se lze připojit přes VPN ze dozvíte prostřednictvím [https://ist.cvut.cz/nase-sluzby/pripojeni-z-domova-vpn/ 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á. | Jak se lze připojit přes VPN ze dozvíte prostřednictvím [https://ist.cvut.cz/nase-sluzby/pripojeni-z-domova-vpn/ 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á. | ||
</ref>, nebo skrz SSH proxy. V rámci laboratorní infrastruktury je pro tento účel vyhrazen disklessový virtuál [[postel]] | </ref>, 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]]. | ||
Technicky by sice bylo možné | K přihlášení na vzdálený stroj <code>remote_machine</code> 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 <code>.ssh/config</code> uděláte záznam pro vzdálený stroj <code>remote_machine</code> (čí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 | |||
{{Poznámka|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í|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 <code>remote_machine</code> protunelovat port <code>1234</code>, 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 <code>4321</code> na otevřený port <code>1234</code> na stroji <code>remote_machine</code>. 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í == | |||
{{Pozor|Ž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í''': | |||
* Jako všechny laboratorní stroje DCE, se na něj uživatel přihlašuje tzv. hlavním heslem ČVUT<ref> | |||
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íč. | |||
</ref> vůči doméně MS.<ref> | |||
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. | |||
</ref> | |||
* 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í: | |||
: <syntaxhighlight lang="bash"> | |||
user@machine:~$ ssh <username>@<remote_diskless> | |||
channel 0: open failed: connect failed: Connection refused | |||
stdio forwarding failed | |||
Connection closed by UNKNOWN port 65535 | |||
</syntaxhighlight> | |||
: 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 <code>~/.ssh/authorized_keys</code><ref>Jde o soubor v rámci uživatelského profilu sdíleného přes NFS v rámci celé laboratorní infrastruktury | |||
</ref> 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 <code>~/.ssh/authorized_keys</code> ještě není k dispozici.<ref> | |||
Technicky by to sice bylo možné poměrně jednoduše vyřešit – aplikací [[overlay]]e, 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á. | |||
</ref> | </ref> | ||
: <small>'''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.</small> | |||
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 == | |||
<references /> |
Aktuální verze z 11. 4. 2024, 13:03
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á.