Co dokładnie wysyła ssh podczas negocjacji klucza?

Gdy jawnie określasz plik tożsamości dla ssh:

ssh -i ./id_rsa ...

Mam te wiersze w śladzie debugowania ssh:

debug1: Offering public key: ./id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Czy to znaczy, że generowany przez ssh id_rsazawiera również publiczny wykładnik RSA? id_rsaformat wydaje się raczej wyraźny, że zawiera klucz prywatny z blokiem „BEGIN PRIVATE KEY”, więc „oferowanie klucza publicznego” musi oznaczać coś innego niż „wysłanie klucza publicznego na serwer”.

EDYTOWAĆ:

Aby to wyjaśnić, chcę wiedzieć, co dokładnie dzieje się za linią „oferowanie klucza publicznego”. Jeśli klient ma wiele kluczy, wszystkie zostaną zaoferowane serwerowi jeden po drugim.

ssh

— Alex B.
źródło

Aby dodać do tego problemu, istnieje metoda sprawdzania przez serwer, czy otrzymaliśmy dobry klucz przed wyzwaniem. Ponieważ już miałem serwer odrzucił nasz klucz, zanim go nawet odszyfrowałem. Błąd tam, gdzie jest z powodu nieokreślonej nazwy.

— Gopoi

Odpowiedzi:

Aby połączyć się z serwerem SSH i uwierzytelnić za pomocą klucza publicznego / prywatnego, musisz najpierw udostępnić swój klucz publiczny serwerowi.

odbywa się to przez skopiowanie klucza publicznego dla swojego klucza prywatnego do serwera i dodanie go ~/ssh/authorized_keyspoprzez kopiuj / wklej, kopiowanie id_rsa.pub, aby ~/.ssh/authorized_keysna serwerze lub cat id_rsa.pub >> ~/.ssh/authorized_keys, dołączając go do listy.

po nawiązaniu połączenia serwer używa klucza publicznego do podpisania wyzwania, a klient używa klucza prywatnego id_rsado odszyfrowania wyzwania, ponownego zaszyfrowania go przy użyciu publicznego serwera host keyi odesłania go z powrotem.

host sprawdza, czy poprawnie odszyfrowałeś wyzwanie, odszyfrowując odpowiedź za pomocą klucza prywatnego, a klient / host nawiązuje szyfrowane połączenie na podstawie udostępnionych danych, a nie na kluczach publicznych / prywatnych.

pod ŻADNYM PUNKTEM w wymianie nie jest twój klucz prywatny lub klucz prywatny hosta wymieniony lub ujawniony sobie nawzajem. twój klucz publiczny jest przechowywany na serwerze, ale dlatego jest to klucz PUBLICZNY.

— cpbills
źródło

Tak, to wszystko dobrze i dobrze, ale wszystko to dzieje się, zanim serwer zidentyfikuje klucz publiczny do szyfrowania wyzwania. Mam kilka kluczy i wszystkie są „oferowane” serwerowi jeden po drugim. Co to dokładnie oznacza? I tak, zdaję sobie sprawę, że klucz prywatny nie jest tak naprawdę wysłany, prawdopodobnie powinienem całkowicie usunąć tę linię z pytania. : P

— Alex B,

kiedy określisz ssh -i keyname, mówisz klientowi ssh dokładnie, jakiego klucza chcesz użyć do połączenia z serwerem. jeśli masz kilkanaście kluczy w ~/.ssh/swoim kliencie, NIE będzie iterować po każdym z nich. będzie szukał ~/.ssh/id_rsa, ~/.ssh/id_dsapotencjalnie kilku innych nazw plików, które są zakodowane w kliencie, lub jaki klucz jest określony dla tego hosta w ~/.ssh/config... długiej historii; twój klient nie oferuje / oferuje / żadnych kluczy do serwera.

— cpbills

po nawiązaniu połączenia Twój / klient / odszyfrowuje wyzwanie z serwera, a następnie przechodzi do listy standardowych lokalnych kluczy prywatnych w celu zaszyfrowania wyzwania i wysłania odpowiedzi. JEŻELI wyzwanie nie powiedzie się, / może / może przejść do następnego zakodowanego klucza, ponownie zaszyfruj za pomocą / that / private key i spróbuj ponownie. ponownie, twoje klucze, publiczny i prywatny, nie są / współdzielone / z serwerem podczas uwierzytelniania przy logowaniu.

— cpbills

och, ponownie przeczytam twój komentarz; host: szyfruje wyzwanie za pomocą klucza hosta, klient: odszyfrowuje wyzwanie za pomocą klucza pubu hosta, klient: szyfruje wyzwanie za pomocą klucza prywatnego, host: próbuje odszyfrować wyzwanie za pomocą wszystkich wymienionych kluczy publicznych ~/.ssh/authorized_keysna hoście wie, jakie jest wyzwanie i jak wygląda ponieważ, kiedy klucz publiczny odblokuje go, będzie wiedział, jak go użyć.

— cpbills

@ rachunki, przepraszam, zapomniałem wspomnieć, że mam kilka kluczy od przekazanego agenta, dlatego oferowanych jest wiele kluczy (dziennik -vvv pokazuje wszystkie z nich, mimo że podam plik tożsamości).

— Alex B,

Kryptografia klucza publicznego / prywatnego oparta jest na bardzo prostym systemie:

Masz klucz publiczny, który jest zdolny do szyfrowania jednokierunkowego oraz klucz prywatny, który jest zdolny de Cryption. Klucz publiczny można następnie przekazać każdemu na świecie i nikt nie będzie w stanie odszyfrować zaszyfrowanych danych, chociaż BĘDĄ one w stanie zaszyfrować dane, które można odszyfrować za pomocą klucza prywatnego.

Odpowiedź na twoje pytanie brzmi: „Twój klucz publiczny”.

— Satanicpuppy
źródło

Tak, dziękuję, wiem dokładnie, jak działa szyfrowanie klucza publicznego, ale chcę poznać specyfikę protokołu SSH i format klucza. Chcę wiedzieć, czy przechowuje on wykładnik publiczny w pliku klucza prywatnego, czy nie? Z tego co wiem, „oferowanie klucza publicznego” może również oznaczać podpisanie nonce za pomocą klucza prywatnego, aby serwer mógł znaleźć odpowiedni klucz publiczny.

— Alex B,

Tak. robi ssh-keygen -y da ci klucz publiczny klucza prywatnego, odwrotność nie działa

— Mâtt Frëëman

Nie sądzę, że powinienem w tym momencie wysyłać klucz publiczny lub prywatny. Klient powinien wykonać szyfrowanie przy użyciu klucza prywatnego w postaci zwykłego tekstu, który jest już znany serwerowi. Host może odszyfrować tę wiadomość za pomocą klucza publicznego, wiedząc, że jedynym, który mógł ją poprawnie zaszyfrować, jest klient, który przechowuje odpowiedni klucz prywatny, tym samym uwierzytelniając klienta.

Wierzę, że to mówi, Offering public key: ./id_rsaponieważ używa klucza prywatnego (przechowywanego w ./id_rsa) do wykonania szyfrowania tekstu jawnego znanego przez serwer, a następnie serwer użyje klucza publicznego do odszyfrowania tego tekstu zaszyfrowanego i potwierdzenia, że pasuje on do tekstu jawnego. Plik klucza publicznego ./id_rsa.pubnigdy nie powinien być potrzebny klientowi po początkowym wygenerowaniu klucza. Jest to używane tylko przez serwer do deszyfrowania.

— Trey Hunner
źródło

Podejrzewałem, że coś takiego się dzieje, ale chciałem trochę szczegółów (tj. Rzeczywisty protokół negocjacji klucza SSH). Nie jestem pewien, dlaczego zostałeś przegłosowany.

— Alex B,

Przepraszam, moja odpowiedź była tak porywcza. Nie znam specyfiki negocjacji klucza SSH, tylko ogólne negocjacje niezbędne do uwierzytelnienia klucza publicznego. Mogłem zostać odrzucony za niespecyficzną odpowiedź.

— Trey Hunner