Czy mogę użyć uwierzytelniania za pomocą klucza SSH, aby zalogować się do systemu zdalnego z inną nazwą użytkownika?

Załóżmy, że mam zdalny system o nazwie „system zdalny” i konto użytkownika „foouser” w tym systemie.

Wiem, że w moim systemie lokalnym mogę wygenerować parę kluczy SSH jako lokalny użytkownik „foouser”, umieścić klucz publiczny w pliku „/home/foouser/.ssh/authorized_keys” w „systemie zdalnym”. Kiedy SSH jako „foouser” z mojego systemu lokalnego do „zdalnego systemu”, SSH używa pary kluczy do uwierzytelnienia mnie.

Ale co jeśli moja lokalna nazwa użytkownika nie jest taka sama jak nazwa użytkownika w systemie zdalnym? To znaczy, jeśli chcę SSH jako lokalnego użytkownika „baruser” do „systemu zdalnego”? Oczywiście będę musiał wygenerować parę kluczy dla „baruser” i dodać klucz publiczny do „/home/foouser/.ssh/authorized_keys”. Następnie powinienem móc „ssh foouser @ remotesystem”, gdy jestem zalogowany jako „baruser” lokalnie, a SSH użyje pary kluczy do uwierzytelnienia, prawda?

Pytam, ponieważ próbuję uruchomić uwierzytelnianie klucza w tym scenariuszu, ale bez powodzenia. Nie jestem pewien, czy jest to spowodowane niedopasowaniem nazwy użytkownika, czy problemem z konfiguracją serwera SSH w systemie zdalnym.

Tak, możesz to zrobić, tak jak to opisałeś.

baruser @ tutaj ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ here ~ $ ssh foouser @ remotesystem
motd wiadomość itp.
foouser @ remotesystem ~ $

To trochę na bok, ale .....

Jeśli zawsze używasz tej samej nazwy użytkownika dla zdalnego serwera, może być również przydatne dodanie hosta do konfiguracji ssh:

Host remotesystem
    User baruser

W ten sposób nie musisz pamiętać, aby podawać nazwę użytkownika podczas logowania, i wykluczasz to w przypadku problemów z kluczami w przyszłości.

Twoja lokalna nazwa użytkownika tak naprawdę nie ma znaczenia (oprócz klucza prywatnego, który musi znajdować się w katalogu domowym użytkownika lokalnego). Po prostu skopiuj klucz do zdalnej authorized_keyssekcji użytkownika i będzie działać.

W przypadku problemów związanych z ssh, pierwszą rzeczą do zrobienia jest zwiększenie gadatliwości klienta:

ssh użytkownik @ maszyna -vvv

Jeśli to nie da ci wglądu w to, co jest nie tak, musisz zmienić poziom dziennika na serwerze i zrestartować demona.

LogLevel DEBUG3

Powinieneś znaleźć wyjście debugowania w /var/log/auth.log (lub tam, gdzie ssh jest skonfigurowany do logowania). Po znalezieniu problemu pamiętaj, aby przywrócić go do sposobu, w jaki go znalazłeś.

Uprawnienia do katalogów .ssh na obu komputerach są bardzo poprawne. Ogólnie oznacza to 700 w katalogu .ssh i co najwyżej 755 w katalogu domowym. Oprócz 600 na wszystkich plikach w katalogach .ssh.

Jeśli użytkownik w systemie zdalnym jest rootem, upewnij się, że root może ssh. (PermitRootLogin w sshd_config) i ten klucz publiczny (PubkeyAuthentication) oraz, jeśli to konieczne, RSA (RSAAuthentication) są włączone.

Jeśli masz włączoną wersję SE Linux, musisz także wykonać następujące czynności.

Dodaj etykietę SELinux, aby authorized_keyssshd mógł uzyskać do niej dostęp.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

Wygląda na to, że robisz wszystko poprawnie, ale upewnij się, że uprawnienia są poprawne dla uprawnionych kluczy. Powinny być ustawione na 600.