Názory k článku Jak se přihlašovat na SSH bez zadávání hesla
-
Ondřej CaletkaZlatý podporovatelDobrý! O tom jsem vůbec nevěděl.
Já blbec vždycky klíče kopíroval ručně a pak se divil, že to nefunguje, když měl soubor authorized_keys zapisovací práva pro skupinu :)
-
JirkaS (neregistrovaný)
Takový malý dodatek, který se může hodit.
Před mnoha lety jsem to zprovozňoval a prostě to nefungovalo. Bádal jsem nad tím hodně hodně dlouho. Nakonec jsem nějak přišel na to, že důvodem je, že adresář „~/.ssh“ má příliš „volná“ práva.
Pokud si ho vyrobí ‚ssh 'automaticky, tak má 'rwx------‘, já ho tehdy vyrobil ručně, měl ‚rwxr–r–‘, z bezpečnostních důvodů to nefungovalo a přitom se nedalo nikde zjistit, co tomu chybí (resp. přebývá). -
Petr (neregistrovaný)
To nic neni :-) U nas mely home adresare standardny rwxrwxr-x, kazdemu uzivateli se vytvarela specialni skupina a administratori-uzivatelu-ne-stroju se do te skupiny take pridavali, kazdy administrator k tem uzivatelum, za ktere zodpovidal. Tahle prava na $HOME se ssh taky nelibila, password-less nefungoval.
-
l. (neregistrovaný)
NetBSD:
plex# ssh cz
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for ‚/root/.ssh/identity‘ are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /root/.ssh/identity
@@@@@@@@@@@126.10.16.149's password: -
bardolf (neregistrovaný)
Musim autorovi vynadat, ze nevydal tento clanek aslespon o den drive ;-). Pouzivani klicu pro prihlasovani pouzivam leta, vcera sem to chtel nasetupovat na redhatu a bylo to peklo. Defaultne v konf. vyple, ale to je trivka. Nejvetsim problemem bylo prijit na ty permissiony, ktere popisuje JirkaS. Nakonec sem tedy zvitezil, ale precist si prispevek od JirkyS, usetril jsem hodinu zivota.
pro ostatni tedy doporucuji overit nasledujici
chmod 701 ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysPro jakekoliv ladeni doporucuji ssh -vv -i ~/private-openssh-key user@masina.
bardolf
-
Trochu mi v článku chybí diskuse nad tím, o kolik je takový postup bezpečnější (čili jaké útoky znemožňuje) než certifikát bez hesla (uložený také na disku).
Laicky si říkám, že k tomu, aby mi někdo ukradl certifikát bez hesla, potřebuje rootovský přístup k danému stroji nebo mě alespoň potřebuje přesvědčit, abych spustil pod svou identitou nějaký jeho skript.
Pokud se nepletu, obě dvě věci mu stačí i ke kompromitaci certifikátu s heslem:
ad „spustím jeho skript“: může si cokoli nechat podepsat mým agentem (má přístup k danému socketu) – ale jenom dotehdy, než na to přijdu (jak?). Toho může využít např. tak, že se přihlásí na stroje, kam mi certifikát umožňuje přístup a přidá tam do authorized_keys svůj klíč. Dokud si toho nevšimnu (jak?), vesele se přihlašuje všude, kam můžu já.
ad „root“: stejný postup. Pokud je šikovnější, mohl by (jak těžké to je?) získat rozšifrovaný klíč z paměti ssh-agenta.
Přijde mi, že jediný skutečně významný nárůst bezpečnosti oproti certifikátu bez hesla přináší hardwarový token. (skutečně hardwarový, ne jako iKey 1000 :)
Pokud se pletu, uvedení na pravou míru uvítám a předem za něj díky!
-
Mordae (neregistrovaný)
Jeste bych dodal; pokud dostane roota, nebo meho uzivatele pres sit, je to borec a zaslouzi si to, ale muze se stat, ze ten notebook nekdo ukradne a podobne. Hlavne u sluzebniho notebooku bych to asi neriskoval. Sifruji tedy pro jistotu cely disk, ale drive jsem sifroval alespon ty klice.
-
> pokud dostane roota, nebo meho uzivatele pres sit, je to borec a zaslouzi si to
Debata o bezpečnosti nějakého řešení je imho debata o tom, jaké situace umožňují kompromitaci. A faktem je, že když se člověk přihlašuje obyčejným heslem, tak kompromitace jeho účtu nevede ke kompromitaci hesla. V tomhle ohledu je teda řešení s ssh-klientem HORŠÍ než normální heslo.
> ale muze se stat, ze ten notebook nekdo ukradne a podobne. Hlavne u sluzebniho notebooku bych to asi neriskoval. Sifruji tedy pro jistotu cely disk, ale drive jsem sifroval alespon ty klice.
V tom případě by útočníkovi stačilo ukrást notebook v okamžiku, kdy jste aktuálně přihlášen ;) První, co udělá, samozřejmě bude, že vypne screensaver :)
-
hajoucha (neregistrovaný)
> Debata o bezpečnosti nějakého řešení je imho debata o tom, jaké situace umožňují kompromitaci.
dovolím si oponovat: Debata o bezpečnosti je především o hodnotě toho, co chci zabezpečit. A proto také Váš nápad se zabezpečením hesla je poněkud mimo. Jestliže heslo k trezoru zůstane utajeno a trezor bude vykraden, tak to asi nebude považováno za skvělé bezpečnostní řešení.
-
> Debata o bezpečnosti je především o hodnotě toho, co chci zabezpečit.
Ano. Ale je potřeba porovnávat cenu dat na jedné straně a pravděpodobnost situace umožňující kompromitaci na té druhé.
> A proto také Váš nápad se zabezpečením hesla je poněkud mimo.
Jaký můj nápad? Napsal jsem, že za jediný postup, bezpečnější než certifikát bez hesla, považuju certifikát na tokenu.
> Jestliže heslo k trezoru zůstane utajeno a trezor bude vykraden, tak to asi nebude považováno za skvělé bezpečnostní řešení.
Nerozumím.
-
„V tom případě by útočníkovi stačilo ukrást notebook v okamžiku, kdy jste aktuálně přihlášen ;) První, co udělá, samozřejmě bude, že vypne screensaver :) “
Nikdy jsem to neskousel s sifrovanym diskem, ale mam obavy zda by v pripade, ze se potencionalnimu utocnikovy podari ukrast notebook (nebo i jen HDD) nestacilo, ze se z disku muze nabootovat system? Pak by teoreticky pri bootu mohlo stacit zadat jadru jako parametr init=„/bin/bash“, nebo nejaky obdobny postup, kterym nastartuji system a ziskam pristup k datum, alespon pro cteni. Vim z vlastni zkusenosti (uz se mi taky stalo, ze jsem zapomelo heslo superuzivatele :) ), ze na normalnich systemech se podobne da nakrasne obejit autentizacni system…
-
Předpokládám, že pisatel měl namysli šifrování disku, které je k něčemu – tj. s požadavkem vložení hesla při bootu.
Mně šlo ale o něco jiného – pokud ukradnu NB nabootovaný s přihlášeným uživatelem a ten používá řešení popsané v článku, mám automaticky přístup ke všemu, k čemu měl přístup on.
Takže opět jediné bezpečné řešení je zadávat heslo, nebo mít certifikát na tokenu (s předpokladem, že ten mi nikdo neukradne).
-
Sten (neregistrovaný)
Z toho důvodu je u NTB stejný požadavek jako u tokenu: nenechat někde zapnutý :)
Jinak já tohle kromě šifrování disku řeším ještě přes automatické zamknutí NTB + smazání hesel z SSH agenta a po chvíli i hibernace na šifrovaný swap, pokud zadané BT zařízení (konkrétně můj mobil) zmizí z dosahu (samozřejmě lze přerušit zadáním hesla). Taky účinné.
-
semerad zula (neregistrovaný)
Základní rozdíl mezi klíčem/certifikátem s heslem a bez hesla je stejný jako u souboru, který je šifrovaný nebo není. Buď máte klíč na disku v šifrované podobě nebo ne. A zjednodušeně řečeno: klíč/certifikát = soubor obsahující heslo. Soubor s hesly si asi také jen tak neuložíte na disk…
Z toho plyne například to, že v případě, že nešifrujete celý disk, stačí pro získání funkčního certifikátu bez hesla fyzický přístup k PC/serveru (a je jedno, jestli je někdo přihlášený nebo ne, je-li spuštěný nebo ne). Dalších scénářů je mnoho a záleží na celkovém zabezpečení serveru/PC.Certifikát na HW tokenu je další úroveň, kdy se ztrácí nevýhody toho, že klíč leží na disku. V případě, že Vás někdo kompromituje pomocí nějakého scriptu, to stejně nepomůže, protože při použití klíče se stejně nahrává do paměti (v případě, že nepoužijete klíč, který Vám také provádí potřebné výpočetní operace → klíč neopustí token). Proti kompromitaci roota hw klíč pomůže (ne nezbytně). Na druhou stranu asi jednodušeji ztratíte hw token než celý notebook … :-).
-
> Základní rozdíl mezi klíčem/certifikátem s heslem a bez hesla je stejný jako u souboru, který je šifrovaný nebo není.
Bavíme se ale o řešení načrtnutém v článku – a to funguje tak, že na disku je heslo zašifrované, ale v paměti leží nezašifrované. Navíc daný uživatel (čili i ten, kdo se dostane k „přihlášenému počítači“) si může nechat podepsat cokoli.
> Soubor s hesly si asi také jen tak neuložíte na disk…
Rozdíl mezi nezašifrovaným heslem na disku a v paměti není imho nijak velký.
> Z toho plyne například to, že v případě, že nešifrujete celý disk, stačí pro získání funkčního certifikátu bez hesla fyzický přístup k PC/serveru
Zatímco v popsaném řešení při fyzickém přístupu k počítači sice nezískám certifikát jako takový, ale můžu si nechat cokoli podepsat, nebo nahraju trojana, který mi podepsání čehokoli zabezpečí i v budoucnu…
=====
Čili sečteno podtrženo: situace „certifikát s heslem na disku + ssh-agent“ oproti situaci „certifikát bez hesla na disku“ nepřináší imho podstatně vyšší bezpečnost.
-
TH (neregistrovaný)
Jsou ovšem případy, kdy klíče nejdou použít. Například různé appliance. Už jsem viděl takové, které klíče nepodporují. A nebo takové, které při restartu vymažou home.
Pak nezbývá než použít expect a heslo ssh vnutit, třeba takhle (zjednodušeno)
#!/bin/sh expect <<[konec] spawn ssh user@10.0.0.1 expect "password:" send "heslo\r" expect "#" send "nejaky prikaz\r" expect "#" send "exit\r" expect eof [konec]
-
petrpo (neregistrovaný)
Pouzivam pro stejnou vec utilitku keychains od Drobbinse (Gentoo linux founder), ktera ma vylepsovat praci s ssh-agentem. Docela se mi to osvedcilo. Prihlasim se na server, jednou zadam passphrase, ta se ulozi do cache a do doby restartu tam je a pomoci scriptu se lze dostat, kam potrebuji (automaticke zalohovani, sopousteni scriptu na vzdalenych strojich, …)
Kdyz by chtel nekdo dostat server fyzicky do ruky a restartuje jej, tak se cache smaze a musi utocnik zadat passphrase, kterou nema :-)petrpo
-
Nick (neregistrovaný)
klice jsou supr, ale nevyhodou je zaneseni urcite decentralizace rizeni pristupu, ktera v dusledku muze predstavovat vetsi problem nez prihlasovani heslem.
vysvetleno na priklade: sit s vetsim mnozstvim serveru spravovana skupinou administratoru, kazdy z nich ma svuj verejny klic nahrany v /root/.ssh/authorized_keys na kazdem serveru. jeden z adminu opusti firmu. v tomto okamziku dojde typicky ke zmene vsech administratorskych hesel na vsech systemech. v pripade klicu je vsak treba projit na vsech serverech /root/.ssh/authorized_keys a najit klic onoho admina, coz vubec nemusi byt snadne. vubec uz nemluvim o tom, co kdyz si admin vygeneruje vice klicu s identifikatorama, ktere jakoby patrili nekomu jinemu a tudiz se prehlidnou pri odstranovani.
tohle povazuju za zasadni bezpecnostni nevyhodu jinak dobreho konceptu, ktera jej vsak vyrazuje z pouziti v opravdu distribuovanem prostredi.
poradne centralizovane reseni (nejen pro SSH) je Kerberos a GSSAPI. ma vsechny vyhody SSH klicu, k tomu radu dalsich a pritom je centralizovane, tedy odstranenim principalu z kerberos databaze ztraci moznost autentizace kdekoliv by se o to pokousel.
-
bsmejo (neregistrovaný)
Mal som problem vo Fedore13 (v Ubuntu to fungovalo) s ssh-agentom resp. ssh-add, ktory sa mi podarilo vyriesit podla clanku:
http://www.cs.indiana.edu/csg/FAQ/Security/openssh.html
Problem bol, ze som sice v textovom rezime mohol spustit ssh-agent
>ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-wbXnkq1732/agent.1732; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1733; export SSH_AGENT_PID;
echo Agent pid 1733;ale nedalo sa mi spustit: ssh-add
>ssh-add
Could not open a connection to your authentication agent.Vysvetlenie podla toho clanku je:
Session is not running under the ssh-agent. You can get around this by restarting a new shell under the agent by running:
>exec ssh-agent bash
Naozaj to pomohlo, teraz vsetko bezi tak ako som ocakaval.
ČLÁNKY DO MAILU