22

Kiedy loguję się przez ssh za pomocą ssh -v, widzę, że ssh uwierzytelnia się w następujący sposób

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,hostbased

Chciałbym zmienić kolejność ... jakiś pomysł jak?

Moim większym problemem jest to, że użytkownik z zablokowanymi kontami może nadal logować się za pomocą kluczy publicznych. Odkryłem, że mogę dodać użytkownika do grupy „ssh-zablokowane” dodaj odmów tej grupie od sshing, ale wciąż zastanawiam się, czy istnieje sposób, aby powiedzieć ssh'd: Sprawdź hasło przed kluczami ...

ssh password public-key

— Oz123
źródło

1

Myślę, że podchodzisz do tego w niewłaściwy sposób - klucze są (zwykle) bezpieczniejsze niż hasła. Jeśli konto jest zablokowane, musisz powiedzieć demonowi sshd, aby nie pozwalał użytkownikowi zalogować się bez względu na metodę uwierzytelnienia.

— EightBitTony

Tak jak powiedziałem, znalazłem rozwiązanie za pośrednictwem DenyGroups. Proszę o to ze względu na zainteresowanie.

— Oz123

31

Serwer ssh decyduje, które opcje uwierzytelniania zezwala, klienta ssh można skonfigurować tak, aby decydował w jakiej kolejności je wypróbować.

Klient PreferredAuthenticationsssh określa tę opcję w pliku konfiguracyjnym ssh.

Z man ssh_config( zobacz tutaj online ):

PreferredAuthentications
             Specifies the order in which the client should try protocol 2 authentication methods.  This allows a client to prefer
             one method (e.g. keyboard-interactive) over another method (e.g. password).  The default is:

                   gssapi-with-mic,hostbased,publickey,
                   keyboard-interactive,password

Nie sądzę, że bez gry ze źródłem można powiedzieć serwerowi OpenSSH, aby preferował określoną kolejność - jeśli się nad tym zastanowić, to i tak nie ma sensu.

— EightBitTony
źródło

Jeśli używasz Git Bash dla Windows, zapisz konfigurację ssh w~/.ssh/config

— Spencer Williams

Kolejność może mieć sens, jeśli jedna metoda zależy od poprzedniej. Na przykład 2FA w ramach klawiatury interaktywnej może zależeć od tego, czy użytkownik najpierw podał prawidłowe hasło.

— steveayre

Czy możesz opublikować źródło, dla którego skopiowałeś powyższe informacje PreferredAuthentications? Nie widzę tego w man ssh, ani w /etc/ssh/ssh_config, ani w /etc/ssh/sshd_config. Skąd masz te informacje?

— Gabriel Staples,

Znaleziono to! To było w środku man ssh_config. Przesłałem zmianę do sprawdzenia, aby zaktualizować twoją odpowiedź, aby zawierała to źródło. Następnym razem proszę cytować źródła! Wielkie dzięki.

— Gabriel Staples,

18

Dodanie tego:

PreferredAuthentications keyboard-interactive,password,publickey,hostbased,gssapi-with-mic

... mojemu /etc/ssh/ssh_configpomógł mi rozwiązać ten problem i zaoszczędziłem dużo czasu!

Możesz sprawdzić, czy to działa, używając ssh -v user@hostpolecenia do połączenia, gdzie -voznacza „verbose”.

— Pavel Anni
źródło

2

Upewnij się, że dodajesz to do poprawnego pliku, ssh_configa nie sshd_config. To ostatnie spowoduje, że twój ssh zawiedzie!

— Pomarańcze13,

0

Dodając do pozostałych dwóch odpowiedzi, w których już wspomniano tę PreferredAuthenticationsopcję, chciałbym dodać , że nie trzeba edytować żadnego pliku, aby ustawić to ustawienie, jeśli nie chcesz . Zamiast tego możesz po prostu ustawić go w wierszu polecenia dla pojedynczego wywołaniassh , z -oopcją w następujący sposób:

ssh -o PreferredAuthentications=publickey,gssapi-with-mic,hostbased,keyboard-interactive,password user@hostname

Bibliografia:

Aby dowiedzieć się więcej o tej PreferredAuthenticationsopcji, zobacz man ssh_config( zobacz tutaj online ). Przeczytaj także o tej ssh -oopcji na man sshstronach podręcznika ( tutaj online ).

— Gabriel Staples
źródło

Zamówienie uwierzytelnienia w SSH

Bibliografia: