Pokud se potřebujete přihlašovat i z počítačů, které nemáte plně pod kontrolou, tak skutečně bezpečné nebude nic. Je potřeba mít na paměti, že SSH (nebo SSL/TLS obecně) řeší zabezpečení komunikace mezi dvěma bezpečnými koncovými body přes potenciálně nebezpečnou síť. Pokud nemůžete důvěřovat těm koncovým bodům, SSH vám nepomůže. Relativně nejmenší riziko bude při použití klíče uloženého v hardwarovém tokenu (openpgp, s novějšími verzemi openssh lze použít i FIDO2 token), protože pak případný útočník bude moci ten tajný klíč zneužít jen po dobu, kdy je token fyzicky připojený. Osobně bych to doporučil jako nejpraktičtější řešení i tomu, kdo se přihlašuje jen ze "svých" počítačů.
'Lepsi' FIDO token vyzaduje nejaku formu potvrdenia napriklad pomocou odtlacku prsta takze to ze je ten kluc niekde strceny nestaci, kazde pouzitie sa musi potvrdit.
Pripadne sa da pouzit One Time Password (OTP) generovany napriklad v mobile. To vyuzivaju niektore komercne riesenie ze zadate HESLO + OTP.
Je mozne zneuzit tu prislusnu session ale v ziadnom pripade nie je mozne ukradnut nejake udaje ktore je mozne pouzit znovu na prihlasenie.
Když útočník ukradne session, může si třeba přidat svůj vlastní klíč. Nebo spustit svůj vlastní server. Zejména pokud se přihlásíte na roota, má útočník dost možností. Ale samozřejmě, útočníkovi to komplikuje situaci – zkopírovat klíč bez hesla z flashky je samozřejmě podstatně jednodušší a nevyžaduje to žádnou zvláštní přípravu.
'Lepsi' FIDO token vyzaduje nejaku formu potvrdenia napriklad pomocou odtlacku prsta takze to ze je ten kluc niekde strceny nestaci, kazde pouzitie sa musi potvrdit.
O tom se dá uvažovat v jednoduchém případě, kdy mi jde opravdu o navázání jednoho (nebo několika málo) SSH spojení. Používat to tomhle režimu pro komplikovanější práci, kde se postupně těch spojení budou navazovat desítky nebo stovky, si moc dobře nedokážu představit.
Já také otvírám spojení extrémní množství, protože mi nikdy moc nepřirostl k srdci multiplexing spojení (vyžaduje abych to první spojení nechal trvale běžet), multiplexing terminálu (nefunguje mi se scrollbackem na mém místním terminálu) ani změna spojení za běhu (typicky přidání port forwardu). Navíc každé scp/rsync a každý git pull/push je další spojení.
> Ale to predsa riesi VPN.
Wat, jak? Částečně řeší port forwarding (ale je to složitější protože se to musí nastavit + se musí řešit otevírání pro správné IP adresy a musím věřit VPN stroji („děravé“ služby typu VNC spouštím normálně tak že poslouchají jenom na localhostu, nebo ještě lépe na unix file socketu)), ty ostatní vůbec.
A ten port forwarding to neřeší úplně, protože se přes VPN nedá dostat na jiné zařízení v té cílové síti - protože nezná routy do VPN. Musel bych mít VPN na router nebo na něm routy nastavovat.
Tak neviem, mozno nepoznate TMUX alebo port forwarding
Nebo to sice znám, ale (1) používám nejen interaktivní session, (2) tmux se pro mne ani zdaleka pohodlím nevyrovná několika samostatným terminálům a (3) uvědomuji si, že když forwardjuji port, abych všechno další protuneloval prvním spojením, může ho stejně dobře použít i kdokoli jiný, kdo je tam se mnou, takže se tím ta nutnost potvrdit každé spojení zvlášť stane bezpředmětnou.
Vedle toho, co píše Michal Kubeček, bych ještě doporučil mít pro každého klienta jiný klíč (tedy jiný doma, jiný v práci a jiný „cestovní“). Pokud byste měl podezření na kompromitaci jednoho klíče, rychle ho všude zakážete a pořád máte přístup pomocí těch ostatních. Takže se budete moci věnovat zjišťování, zda a kam se útočník dostal a ne řešit, abyste se na svá zařízení vůbec dostal sám.
A pro ty notebooky v konferenčních místnostech bych doporučil mít na flashce vlastního klienta s vlastní konfigurací. Někde to nepůjde použít, ale tam, kde ano, zase snížíte riziko, že klient předinstalovaný na daném zařízení je podvržený, starý nebo špatně nakonfigurovaný.