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.