Logowanie za pomocą kluczy Secure Shell

P

rzedstawiony hack jest tłumaczeniem „Quick Logins with ssh Client keys” z książki „Linux Servers Hacks” autorstwa Rob’a Flickenger’a udostępnionym on-line (Hack #66) na stronie http://hacks.oreilly.com. 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:

1
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:

1
2
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ć uprawnienia 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 zarządzasz bezpośrednio)? Jeżeli 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).

0 (0)
Article Rating (No Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
How To: Linux Hard Disk Encryption With LUKS [ cryptsetup Command ]
Viewed 7239 times since Fri, Jul 13, 2018
RHEL: Extending the maximum inode count on a ext2/ext3/ext4 filesystem
Viewed 3071 times since Sun, May 27, 2018
PROCESSOR AND MEMORY INFORMATION
Viewed 5475 times since Sat, Jun 2, 2018
An easier way to manage disk decryption at boot with Red Hat Enterprise Linux 7.5 using NBDE
Viewed 7366 times since Mon, Aug 6, 2018
CONFIGURE FOR ASM Linux
Viewed 5441 times since Sat, Jun 2, 2018
ZFS: Verify/change properties of a zfs filesystem
Viewed 2508 times since Sun, Jun 3, 2018
LOGROTATE – ARCHIWIAZACJA LOGÓW
Viewed 1902 times since Fri, Nov 30, 2018
Extending Linux LVM partitions - scripts
Viewed 6456 times since Sun, May 20, 2018
Jak znaleźć najszybszy publiczny serwer DNS w Polsce?
Viewed 2500 times since Mon, May 21, 2018
RHEL: Allowing users to ’su’ to "root" / Allowing ’root’ to login directly to the system using ’ssh’
Viewed 2749 times since Sat, Jun 2, 2018