Czy powstrzymać klienta ssh od oferowania wszystkich dostępnych kluczy publicznych?

32

Jak większość sysadminów, których używam openssh przez cały czas. Mam około tuzina kluczy ssh, lubię mieć inny klucz ssh dla każdego hosta. Powoduje to jednak problem, gdy łączę się z hostem po raz pierwszy, a wszystko, co mam, to hasło. Chcę po prostu połączyć się z hostem za pomocą hasła, w tym przypadku nie ma klucza ssh. Jednak klient ssh zaoferuje wszystkie klucze publiczne w moim ~/.ssh/(wiem o tym patrząc na wynik ssh -v). Ponieważ mam ich tak wiele, rozłączę się z powodu zbyt wielu błędów uwierzytelnienia.

Czy jest jakiś sposób, aby powiedzieć mojemu klientowi ssh, aby nie oferował wszystkich kluczy ssh?

ssh public-key private-key

— Rory
źródło

2

Dlaczego chcesz mieć inny klucz dla każdego hosta? Klucze mogą być również współużytkowane przez hosty w ramach jednej domeny administracyjnej. Oczywiście, używałbyś jednego klucza do maszyn roboczych, a drugiego do maszyn prywatnych, ale jaka jest logika używania oddzielnego klucza dla każdej maszyny w pracy?

— Alex Holst

@AlexHolst Używam wielu kluczy. Mam domyślnie zaszyfrowany (który wymaga ode mnie hasła) dla infrastruktury wewnętrznej. Mam inny, niezaszyfrowany (bez hasła), którego używam do jednej konkretnej usługi, w której nie mogłem używać agenta ani nie chciałem wpisywać hasła co minutę. Mam inne dla połączeń, które nie są częścią naszej wewnętrznej infrastruktury. Jest to dobra praktyka, ponieważ chociaż odzyskanie klucza prywatnego z klucza publicznego powinno być dość trudne, można to zrobić. np. błąd Debiana openssh kilka lat temu ...

— Huygens

@Huygens Chciałbym zobaczyć twój dokument analizy ryzyka, który doprowadził do wniosku, że musisz użyć kilku kluczy SSH, ale posiadanie czystego tekstu jest w porządku. Czy możesz opublikować link?

— Alex Holst,

@AlexHolst nie musisz być tak „bezpośredni”. Przede wszystkim moja odpowiedź dotyczyła powodów posiadania wielu par kluczy. Myślę, że dałem ci kilka. Potem wszyscy mamy do czynienia z dziwactwami, a co nie. Mam system testowy, w którym nie mogę korzystać z aplikacji, która tuneluje dane przez SSH, bez ciągłego monitowania o hasło klucza uniemożliwiające korzystanie z oprogramowania. To wydaje się być błędem z powodu niekompatybilności wersji lub co innego. Otrzymuję powiadomienie e-mail o każdym logowaniu SSH i jestem jedynym logującym się do tego pola. Ryzyko jest więc dopuszczalne.

— Huygens,

31

Jest to oczekiwane zachowanie według strony podręcznika ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Zasadniczo, określenie IdentityFiles tylko dodaje klucze do bieżącej listy, którą agent SSH już przedstawił klientowi.

Spróbuj zastąpić to zachowanie poniższym opisem na dole .ssh/configpliku:

Host *
  IdentitiesOnly yes

Możesz również zastąpić to ustawienie na poziomie hosta, np .:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

— Mathias Bynens
źródło

4

Możesz także użyć ssh -o "IdentitiesOnly true" -v -A user@hosttego, czego używam do zalogowania się na maszynie, która nie ma żadnego z moich kluczy, ale chcę zaoferować przekazywanie agentów dalej. ( -vdo pełnego debugowania).

— eckes

1

@eckes to fajna wskazówka, ale czy nie powinna to być yes(i nie true)?

— aexl

IdentitiesOnlymoże nie zawsze pomóc, może być konieczne wyłączenie hosta; patrz superuser.com/questions/859661/…

— aexl

38

Chociaż inni sugerowali to rozwiązaniami opartymi na konfiguracji, prawdopodobnie warto zauważyć, że można to łatwo zrobić jednorazowo w wierszu poleceń za pomocą:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

— Andrew Ferrier
źródło

3

Idealne .. Rozwiązanie IMHO

— drAlberT

1

Prawidłowo powinna to być zaakceptowana odpowiedź.

— JM Becker,

11

Zgodnie z rozwiązaniem Jamesa Sneeringera, możesz po prostu ustawić ssh_config w następujący sposób:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Jeśli łączysz się z określonym kluczem z wieloma komputerami spoza wspólnej domeny, rozważ nadanie im wszystkich nazw CNAME we własnym DNS. Robię to ze wszystkimi systemami klientów.

— Justin Alan Ryan
źródło

2

Podobnie jak w rozwiązaniu user23413, możesz całkowicie wyłączyć uwierzytelnianie klucza publicznego dla określonego hosta (lub wzorca wieloznacznego):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

— James Sneeringer
źródło

-1

Jeśli wskażesz konkretny plik klucza za pomocą ssh -i / path / to / key, użyje go tylko wtedy, gdy inne są załadowane do agenta i nie zostaniesz poproszony o podanie hasła. Możesz również edytować swoje ~ / .ssh / config i reklamować coś takiego ...

Host foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

możesz także zrobić ...

Host * .example.org
IdentityFile .ssh / id_rsa_example.org

— ryanc
źródło

To tylko dodaje klucz docelowy na końcu listy, co nie rozwiąże problemu. IdentitiesOnlytylko z taką wolą.

— Jo Rhett