Używać określonego przekazanego klucza od agenta SSH?

Powiedzmy, że mam klucz do Github wraz z innymi kluczami. Dodałem wiele kluczy do mojego agenta ssh ( ssh-add -Lzwraca wiele wierszy) na moim komputerze domowym A. W moim .ssh/configustawiłem, który klucz ma być używany z którym hostem, więc np.

ssh -T -vvv git@github.com 2>&1 | grep Offering

daje

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Zgodnie z oczekiwaniami oferowany jest tylko jeden klucz. Ale potem przesyłam wiadomość do hosta B ForwardAgent yesi powtarzam to samo polecenie

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

co oznacza, że próbuje wszystkich moich kluczy. Jest to problematyczne, ponieważ tylko ograniczona liczba kluczy może zostać wypróbowana przed powrotem serwerów Too many authentication failures. Próbowałem więc edytować .ssh/configna hoście B, aby uwzględnić

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

ale wtedy nie otrzymuję żadnych kluczowych ofert, ale raczej

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

co, jak sądzę, oznacza, że klucz nie został znaleziony (?) A w końcu klucz znajduje się na moim komputerze domowym A, a nie na hoście B, więc pytanie brzmi, jak się do niego odnosić na hoście B? Mam nadzieję, że udało mi się wyjaśnić pytanie.

ssh ssh-agent

— Danmichaelo
źródło

Odpowiedzi:

Masz dobry pomysł. Brakuje tylko tego, że wskazany plik IdentityFilemusi istnieć. Nie musi zawierać klucza prywatnego, wystarczy mieć dostępny tylko klucz publiczny.

Na hoście B możesz wyodrębnić klucz publiczny z agenta, wpisując, ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.puba następnie wskazując ten plik~/.ssh/config

— kasperd
źródło

FYI nazwa klucza publicznego nie ma znaczenia. Wybiera odpowiedni klucz od agenta na podstawie zawartości.

— akostadinov,

@akostadinov Prawda. Jeśli sshwskażesz plik klucza publicznego bez powiązanego pliku klucza prywatnego, powinien on po prostu odczytać klucz publiczny z pliku i pozwolić agentowi na użycie odpowiedniego klucza prywatnego do wygenerowania podpisu.

— kasperd

To skutecznie oszczędza Twój klucz na hoście B! Zobacz odpowiedź poniżej @ mc0e, aby znaleźć rozwiązanie, które nie zapisuje klucza na serwerze.

— Pitt

@Pitt Nie, nie ma. Przechowuje tylko klucz publiczny . I to nie jest problem, ponieważ klucz publiczny nigdy nie był trzymany w tajemnicy. Przekazywanie agenta daje hostowi dostęp do korzystania z klucza, dopóki przekazywanie agenta jest na miejscu, ale agent nigdy nie wyśle nigdzie tajnego klucza.

— kasperd

@kasperd nie potrzebujesz rzeczywistej kopii klucza prywatnego, gdy masz aktywne połączenie z klientem użytkownika za pomocą tego klucza. Jako root możesz uzyskać dostęp do połączeń agentów innych zalogowanych użytkowników.

— mc0e,

Dobra odpowiedź od @Kasperd, ale pamiętaj również, że jeśli komputer B zostanie przejęty lub jeśli nie ufasz wszystkim osobom z uprawnieniami roota, nadal narażasz wszystkie swoje klucze na nadużycia, dopóki jesteś zalogowany na tym hoście.

Lepszym rozwiązaniem może być więc przekazywanie dostępu tylko do potrzebnych kluczy. Może spróbuj, ssh-agent-filterktóry jest w repozytoriach debian / Ubuntu lub z github .

EDYCJA: Postanowiłem ssh-identraczej niż ssh-agent-filterselektywne przekazywanie kluczy, choć nie jest to tak płynne doświadczenie, jak można by oczekiwać.

— Mc0e
źródło

Z komentarza @ kasperd do jego odpowiedzi: „nie. Przechowuje tylko klucz publiczny. I to nie jest problem, ponieważ klucz publiczny nigdy nie był trzymany w tajemnicy. Przekazywanie agentów daje hostowi dostęp do używaj klucza tak długo, jak działa przekazywanie agenta, ale agent nigdy nigdzie nie wyśle tajnego klucza ”

— Bdoserror

@Bdoserror Jako root możesz nadużywać połączenia ssh-agent, gdy powiązany użytkownik jest zalogowany. Po prostu skopiuj SSH_*zmienne środowiskowe i zaloguj się do dowolnego miejsca, w którym chcesz się udać, używając klucza, mimo że nigdy nie masz rzeczywistej kopii.

— mc0e

Aby wyjaśnić: ta odpowiedź jest rzeczywiście nieprawidłowa - podczas gdy scenariusz nadużycia z mc0e jest prawdziwy, nie ma on nic wspólnego z zapisywaniem klucza publicznego - w przypadku naruszenia bezpieczeństwa hosta pośredniego połączenia agenta można użyć do uwierzytelnienia za pomocą klucza prywatnego, niezależnie od tego tego, czy zapisać klucz publiczny na hoście pośrednim, czy nie. Twój klucz prywatny nie zostanie narażony na szwank, a zapisanie klucza publicznego nie ułatwi tego, ponieważ każdy atakujący, który ma połączenie z agentem, może po prostu poprosić go o klucze publiczne.

— Przywróć Monikę

@ marc-lehmann ponownie przeczytał to, co napisałem. Jeśli przekażesz klucze, zostaną one ujawnione, ale możesz ograniczyć liczbę przekazywanych kluczy.

— mc0e

Podążam za tym, co napisałeś - proszę odnieść się do treści naszych komentarzy, a nie do osoby. Problem polega na tym, że twoja odpowiedź jest po prostu błędna, ponieważ zakłada, że podczas pisania klucze „są przekazywane” do zdalnego hosta. Nic takiego się nie dzieje, a same klucze nie są narażone.

— Przywróć Monikę