Szybkie logowania za pomocą kluczy klienta Secure Shell.odt

Dokument pobrany z serwisu: www.Centrum.Bezpieczenstwa.pl
Autor artykułu: Patryk Krawaczyński (www.nfsec.pl)
Szybkie logowania za pomocą kluczy klienta Secure Shell
Przedstawiony hack jest tłumaczeniem "Quick Logins with ssh Client keys" z ksiąŜki "Linux
Servers Hacks" autorstwa Rob'a Flickenger'a. Do tłumaczenia zostało dodane takŜe parę informacji
od tłumacza.
Kiedy jesteś administratorem więcej niŜ jednej maszyny, szybkie przechodzenie do powłoki
kaŜdego innego serwera moŜe być bardzo przydatne. Konieczność wpisania "ssh
moja.nazwa.serwera.com" (po czym następuje wpisanie hasła) jest nie tylko męcząca i nudna, ale
potrafi przerwać koncentracje. Nagle nasza koncentracja zamiast skupiać się na "gdzie jest
problem?" kierowana jest na "wchodzę tutaj i tutaj", a potem znowu musimy wracać do "o co w
końcu chodziło?". To cyfrowy odpowiednik pytania: "a właściwie po, co tutaj jestem?" (co więcej,
problem robi się gorszy przez program /usr/game/fortune!).
W kaŜdym razie, im więcej wysiłku jest przy logowaniu do innej maszyny tym mniej sił jest na
rozwiązanie problemu. Nowsze wersje programu SSH oferują bezpieczny odpowiednik ciągłego
wpisywania haseł: wymianę kluczy publicznych.
W celu uŜycia publicznych kluczy na serwerze SSH, musisz najpierw wygenerować parę kluczy
publiczny/prywatny:
$ ssh-keygen -t rsa
MoŜesz takŜe uŜyć parametru: -t dsa dla wygenerowania kluczy DSA lub -t rsa1, jeśli nadal
uŜywasz protokołu w wersji pierwszej (a jeśli uŜywasz to wstydź się! I jak najszybciej wykonaj
aktualizację do drugiej wersji!).
Po wklepaniu powyŜszej komendy, powinieneś zobaczyć komunikat podobny do tego:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rob/.ssh/id_rsa):
Po prostu wciśnij klawisz [Enter]. Następnie pojawi się pytanie o długie hasło; naciśnij ponownie
[Enter], tym razem dwa razy (ale przeczytaj uwagi o bezpieczeństwie wyświetlone poniŜej). Wyniki
powinny wyglądać następująco:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rob/.ssh/id_rsa.
Your public key has been saved in /home/rob/.ssh/id_rsa.pub.
The key fingerprint is:
a6:5c:c3:eb:18:94:0b:06:a1:a6:29:58:fa:80:0a:bc rob@localhost
W ten sposób powstaną dwa pliki, ~/.ssh/id_rsa oraz ~/.ssh/id_rsa_pub. W celu uŜycia tej pary
kluczy, wydaj polecenia:
$ ssh -v server "mkdir .ssh; chmod 0700 .ssh"
$ scp .ssh/id_rsa.pub server:.ssh/authorized_keys
Oczywiście zamiast wyraŜenia server podaj nazwę swojego serwera. Dwa razy powinno pojawić
się pytanie o hasło. Teraz, po prostu wystarczy wykonać polecenie: ssh server, a logowanie
odbędzie się automatycznie bez hasła. O tak, w programie scp teŜ zostanie uŜyty nowiutki,
błyszczący klucz publiczny.
Jeśli to nie działa, sprawdź uprawnienia do plików w obu katalogach ~/.ssh/* oraz server:~/.ssh/*.
Klucz prywatny (id_rsa) powinien posiadać uprawnienia 0600 (i znajdować się tylko na komputerze
lokalnym), zaś wszystkie pozostałe pliki powinny mieć oprawnienia 0655. W przypadku OpenSSH
naleŜy takŜe sprawdzić pod jaką nazwą musi być zapisywany publiczny klucz na serwerze (opcja:
AuthorizedKeysFile w /etc/ssh/sshd_config).
Co się tyczy bezpieczeństwa:
Niektórzy uwaŜają, Ŝe klucze publiczne stanowią potencjalne zagroŜenie. W końcu trzeba tylko
ukraść kopię klucza prywatnego, aby uzyskać dostęp do serwerów. To prawda, ale to samo tyczy
się haseł.
Zadaj sobie pytanie, ile razy dziennie wpisujesz hasło, aby uzyskać dostęp do interpretera poleceń
komputera (lub w celu przesłania pliku poleceniem scp)? Jak często uŜywasz tego samego hasła na
wielu (lub wszystkich? nie dobrze!) komputerach? Czy zdarzyło ci się uŜywać hasła w sytuacji
potencjalnego zagroŜenia (w witrynie WWW, na komputerze osobistym z nieaktualnym
oprogramowaniem lub na kliencie SSH na komputerze, którym nie zarzadzasz bezpośrednio)? JeŜli
znasz to wszystko z autopsji, to wiedz, Ŝe w takich samych warunkach klucz SSH praktycznie
uniemoŜliwia atakującemu późniejsze uzyskanie nieautoryzowanego dostępu (o ile, oczywiście,
klucz prywatny jest odpowiednio zabezpieczony).