Czy klucz ssh musi mieć nazwę id_rsa?

Kilka razy natknąłem się na ten problem podczas tworzenia serwerów kompilacji z uwierzytelnianiem kluczowym.

Zastanawiałem się, czy ktoś jeszcze tego doświadczył. Mam kilka kluczy dla mojego obecnego użytkownika, które mogą łączyć się z różnymi komputerami. Powiedzmy, że maszyna1 i maszyna2. Wkleiłem mój klucz publiczny do odpowiedniego pliku autoryzowanych_kluczy. Pierwszy nazwałem pierwszym kluczem id_rsa i drugim kluczem giętarki.

Kiedy próbuję połączyć się z giętarką, otrzymuję następujące wyjście z moim pełnym połączeniem ssh

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Oferuje tylko klucz id_rsa, jak widać powyżej. Czy to jest poprawne? Jeśli tak to dlaczego? Jak mogę uzyskać więcej kluczy? Wiem, że to problem, który widzę sporadycznie, ponieważ w domu mam wiele kluczy bez większych problemów.

Byłbym także wdzięczny za przegląd interakcji pubu i kluczy prywatnych z klientem i serwerem. Myślałem, że mam całkiem niezły pomysł, ale najwyraźniej czegoś mi brakuje.

Proszę i dziękuję.

Domyślnie ssh wyszukuje id_dsai id_rsapliki. Klucze nie muszą być tak nazywane, możesz je mykeyrównie dobrze nazwać , a nawet umieścić w innym katalogu. Jeśli jednak zrobisz jedną z nich, musisz jawnie odwołać się do klucza w komendzie ssh w następujący sposób:

ssh user@server -i /path/to/mykey

Jeśli polecenie nie akceptuje -i, np. sshfsSkorzystaj z IdentityFileopcji:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

Jak to działa

Podczas generowania klucza otrzymasz dwa pliki: id_rsa(klucz prywatny) i id_rsa.pub(klucz publiczny). Jak sugerują ich nazwy, klucz prywatny należy zachować w tajemnicy, a klucz publiczny można opublikować publicznie.

Uwierzytelnianie za pomocą klucza publicznego działa z kluczem publicznym i prywatnym. Zarówno klient, jak i serwer mają własne klucze. Podczas instalacji openssh-serverserwera klucze publiczne i prywatne są generowane automatycznie. W przypadku klienta musisz to zrobić samodzielnie.

Kiedy (klient) łączysz się z serwerem, klucze publiczne są wymieniane. Otrzymasz jeden serwer, a serwer twój. Przy pierwszym otrzymaniu klucza publicznego serwera zostaniesz poproszony o jego zaakceptowanie. Jeśli ten klucz publiczny zmienia się z czasem, zostaniesz ostrzeżony, ponieważ trwa możliwy atak MITM (Man in the middle), przechwytujący ruch między klientem a serwerem.

Serwer sprawdza, czy możesz łączyć się (zdefiniowany w /etc/ssh/sshd_config) i czy Twój klucz publiczny jest wymieniony w ~/.ssh/authorized_keyspliku. Możliwe przyczyny odmowy klucza publicznego:

• /etc/ssh/sshd_config:
  • AllowUserslub AllowGroupsjest określony, ale użytkownik serwera nie jest wymieniony na liście grup lub użytkowników (domyślnie nie jest zdefiniowany, nie nakłada żadnych ograniczeń na logowanie się użytkowników lub grup).
  • DenyUserslub DenyGroupsjest określony i znajdujesz się na liście użytkowników lub grup.
  • Próbujesz zalogować się jako root, ale PermitRootLoginjest ustawiony na No(domyślny yes).
  • PubkeyAuthenticationjest ustawiony na No(domyślny yes).
  • AuthorizedKeysFilejest ustawiony w innej lokalizacji, a klucze publiczne nie są dodawane do tego pliku (domyślnie .ssh/authorized_keysw stosunku do katalogu domowego)
• ~/.ssh/authorized_keys: twój klucz publiczny nie został dodany do tego pliku (pamiętaj, że ten plik jest czytany jako użytkownik root)

Używanie wielu kluczy

Często zdarza się, że używasz wielu kluczy. Zamiast biegać ssh user@host -i /path/to/identity_file, można użyć pliku konfiguracyjnego ~/.ssh/config.

Typowe ustawienia to IdentityFile (klucze) i port. Następna konfiguracja sprawdzi „id_dsa” i „bender” tylko podczas łączenia z ssh youruser@yourhost:

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

W przypadku pominięcia Host yourhostustawienia zostaną zastosowane do wszystkich połączeń SSH. Inne opcje mogą być określone dla tego gospodarza meczu, jak User youruser, Port 2222itp Pozwoliłoby to na połączenie z skrót ssh yourhostzamiast ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.

Moja ulubiona metoda umożliwia automatyczne wybranie klucza prywatnego

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSH zastąpi% l nazwą lokalnego komputera,% r zdalną nazwą użytkownika i% h zdalnym hostem, więc jeśli chciałbym połączyć się z mojego komputera o nazwie foo, aby zablokować się jako użytkownik, uruchamiam:

ssh bar

A ssh automatycznie użyje:

~/.ssh/foo_user@bar_id_rsa

Ponieważ lokalny host jest również przechowywany, pozwala to na udostępnianie katalogów domowych przez NFS (inny klucz na maszynę!), A nawet identyfikację, na której maszynie klucz miał być ...

Biorąc pod uwagę komentarz StevenRoose'a, że ​​określenie wielu klawiszy zajmuje więcej czasu, a ja gram z dużą ilością klawiszy, chciałbym zasugerować moje osobiste rozwiązanie.

Tworzę dowiązanie symboliczne do klucza, którego chcę używać w tym czasie, a ponieważ zmienia się to nieczęsto w zależności od projektu, nad którym pracuję, jestem z niego zadowolony.

Tutaj mam link do moich kluczy dla maszyn działających pod wirtualnym pudełkiem:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

Można również dodać naprawdę szybki skrypt, aby przejść do innego zestawu bez konieczności ręcznego wpisywania polecenia ln .

Ponownie, nie jest to rozwiązanie tylko dla dwóch kluczy, ale dla większej liczby może być wykonalne.