Jak skonfigurować uwierzytelnianie ssh przy użyciu kluczy zamiast nazwy użytkownika / hasła?

Jak skonfigurować ssh do uwierzytelnienia użytkownika za pomocą kluczy zamiast nazwy użytkownika / hasła?

Dla każdego użytkownika: powinni wygenerować (na swoim komputerze lokalnym) parę kluczy za pomocą ssh-keygen -t rsa( rsamożna je zastąpić dsalub rsa1też, choć te opcje nie są zalecane). Następnie muszą umieścić zawartość swojego klucza publicznego ( id_rsa.pub) ~/.ssh/authorized_keysna logowanym serwerze.

Właściwie wolę ssh-copy-id , domyślnie skrypt znajdujący się na * nix (można go również łatwo zainstalować na Mac OS X ), który automatycznie robi to za Ciebie. Ze strony podręcznika:

ssh-copy-id to skrypt, który używa ssh do logowania do zdalnego komputera (prawdopodobnie przy użyciu hasła logowania, więc uwierzytelnianie hasła powinno być włączone, chyba że sprytnie wykorzystałeś wiele tożsamości)

Zmienia również uprawnienia zdalnego domu, ~ / .ssh i ~ / .ssh / uprawnione_klucze do usuwania możliwości zapisu grupowego (co w innym przypadku uniemożliwiłoby zalogowanie się, jeśli zdalny sshd ma ustawione StrictModes w swojej konfiguracji).

Jeśli podano opcję -i, wówczas używany jest plik tożsamości (domyślnie ~ / .ssh / tożsamość.pub), niezależnie od tego, czy w ssh-agent są jakieś klucze.

Hum, nie rozumiem. Po prostu utwórz klucz i zacznij. :) HOWTO Dodatkowo możesz zabronić logowania za pomocą hasła. W np. / Etc / ssh / sshd_config:

PasswordAuthentication no

Jest to dość prosta do zrobienia - jest prosta solucja należy znaleźć tutaj .

Główne punkty to:

• Uruchom ssh-keygenna swoim komputerze. Wygeneruje to klucze publiczne i prywatne.
• Skopiuj i wklej zawartość klucza publicznego (prawdopodobnie w ~/.ssh/id_rsa.pub) ~/.ssh/authorized_keysna zdalnym komputerze.

Ważne jest, aby pamiętać, że zapewni to każdemu, kto ma dostęp do klucza prywatnego na twoim komputerze, ten sam dostęp do zdalnego komputera, więc podczas generowania pary kluczy możesz wybrać hasło tutaj dla dodatkowego bezpieczeństwa.

Użytkownicy systemu Windows mogą skonfigurować kit

• http://www.howtoforge.com/ssh_key_based_logins_putty

Podsumowując to, co powiedzieli inni, konfiguracja kluczy SSH jest łatwa i nieoceniona.

Na komputerze, który będzie SSHing ze trzeba wygenerować parę kluczy:

claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius

Po prostu wciśnij enter tam, gdzie zapisano i wprowadź hasło, gdy zostaniesz o to poproszony - idealnie różni się od zwykłego hasła logowania zarówno na bieżącym hoście, jak i tym, do którego będziesz SSHing.

Następnie należy skopiować wygenerowany klucz po prostu do hosta, który chcesz SSH do . Większość dystrybucji Linuksa ma takie narzędzie ssh-copy-id:

claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Jeśli Twoja dystrybucja tego nie ma, skopiuj klucz do hosta docelowego i dodaj go do (prawdopodobnie istniejącego) .ssh/authorized_keyspliku:

claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub                                    100% 1119     1.1KB/s   00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May  9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys

Wreszcie, aby uzyskać maksymalną korzyść z kluczy SSH, będziesz chciał uruchomić agenta SSH. Jeśli korzystasz ze środowiska graficznego (Gnome, KDE itp.), To samo wylogowanie i ponowne uruchomienie spowoduje uruchomienie agenta SSH. Jeśli nie, można dodać następujące wpisy do pliku rc (muszli .bashrc, .profileitp):

SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
    eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi

Jest to przeznaczone jako lista kontrolna. Jeśli ktoś podąża za nim punkt po punkcie, należy uwzględnić najpopularniejsze hasła do logowania bez hasła. Większość tych punktów wymieniono gdzie indziej; to jest agregacja.

Na każdym komputerze pod kontem musi znajdować się ~/.sshkatalog, chmod 700z którego będą tworzone lub odbierane połączenia.

Klucz (prywatny) musi zostać wygenerowany bez hasła lub można uruchomić agenta, który będzie przechowywać odszyfrowaną wersję klucza zawierającego hasło dla klientów. Uruchom agenta za pomocą ssh-agent $SHELL. Ta $SHELLczęść zajęła mi trochę czasu. Zobacz stronę podręcznika, ponieważ istnieje wiele różnych szczegółów, jeśli chcesz użyć agenta.

Nie zapominaj, że domyślnie słabe klucze (<2048 bit DSA) nie są akceptowane przez ostatnie wersje sshd.

Następujące elementy muszą być wykonane na maszynie po stronie klienta do pochodzić połączenia.

1. Klucz prywatny musi być umieszczony w ~/.ssh/id_rsalub ~/.ssh/id_dsajako właściwe. Możesz użyć innej nazwy, ale musi ona być uwzględniona w opcji -i w komendzie ssh na maszynie inicjującej, aby jawnie wskazać klucz prywatny.

2. Twój klucz prywatny musi być chmod 600.

3. Sprawdź, czy folder domowy to chmod 700.

Teraz za zezwolenie urządzeniu na otrzymanie żądania. Popularnym modelem jest to, że administrator daje ci dostęp do komputera, którego nie jesteś właścicielem (np. Udostępnionego hostingu). Dlatego w ssh chodzi o to, że oferujesz swój klucz publiczny komukolwiek, kto daje ci konto. Dlatego generalnie nie umieszczasz kluczy prywatnych na maszynie odbierającej żądania. Ale jeśli chcesz, aby ta maszyna również wykonywała wychodzące połączenia ssh, musisz traktować ją jak maszynę oryginalną, wykonując powyższe kroki.

1. Twój klucz publiczny musi być umieszczony w pliku o nazwie ~/.ssh/authorized_keyspod kontem, które otrzyma połączenia. Tutaj możesz również umieścić inne klucze, które mogą łączyć się za pośrednictwem tego konta. Szczególnie trudna rzecz, jeśli jesteś w vi i wklejasz klucz do pliku z bufora wklejania w PuTTY, jest następujący: klucz zaczyna się od „ssh-”. Jeśli nie jesteś w trybie wstawiania, pierwsze „s” wprowadzą vi w tryb wstawiania, a reszta klawisza będzie wyglądać dobrze. Ale na początku klucza zabraknie litery „s”. Znalezienie tego zajęło mi kilka dni.
2. Lubię chmod 600 ~/.ssh/authorized_keys. Musi to być co najmniej gw.
3. Teraz musisz dodać odcisk palca hosta do pamięci podręcznej. Przejdź do komputera A i ssh do komputera B ręcznie. Za pierwszym razem otrzymasz zapytanie typu „Czy chcesz dodać ... do pamięci podręcznej kluczy hosta?”. Jeśli próbujesz uzyskać automatyzację (na przykład skrypt) do korzystania z tego logowania, musisz upewnić się, że klient ssh używany przez automatyzację nie otrzyma tego monitu.

Jak powiedzieli inni, twoi użytkownicy powinni tworzyć dla siebie klucze na swoich komputerach klienckich za pomocą ssh-keygen i dodawać swój klucz publiczny do ~ / .ssh / uprawnionych_kluczy na komputerze, na którym chcą się zalogować.

Aby uzyskać bardziej szczegółowe informacje, gorąco polecam SSH, The Secure Shell .

Jest tu dobra rada, więc jej nie powtórzę. Po skonfigurowaniu jednego serwera, aby umożliwić Ci logowanie się przy użyciu kluczy, możesz skonfigurować inne, aby robiły to samo z tym jednym linerem:

remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done

Po prostu przejdź do katalogu domowego, zdefiniuj zmienną zdalną jako jedną lub wiele nazw serwerów i zrób kilka naraz. Hasło, o które prosi, będzie Twoim hasłem ssh do zdalnego serwera. Możesz oczywiście użyć uproszczonej wersji bez pętli for:

tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"

PAMIĘTAJ: Kopiuj tylko klucze publiczne. Nie chcesz, aby twoje prywatne klucze siedziały na jakimś serwerze, na którym każdy z sudo może je skopiować i brutalnie wymusić twoje hasło.