Administrator serwera wysłał mi klucz prywatny do użycia. Dlaczego?

Mam uzyskiwać dostęp do serwera, aby połączyć serwery pośrednie i tymczasowe firmy z naszą pętlą wdrażania. Administrator po swojej stronie skonfigurował te dwie instancje, a następnie utworzył użytkownika na serwerze dla SSH w as. Do tego jestem przyzwyczajony.

Teraz myślę, że wyślę im mój klucz publiczny, który można umieścić w folderze kluczy autoryzowanych. Zamiast tego wysłali mi nazwę pliku, id_rsaktóra zawiera plik -----BEGIN RSA PRIVATE KEY-----w wiadomości e-mail. Czy to normalne?

Rozejrzałem się dookoła i mogę znaleźć mnóstwo zasobów przy generowaniu i konfigurowaniu własnych kluczy od zera, ale nic o startowaniu od kluczy prywatnych serwera. Czy powinienem używać tego do generowania klucza dla siebie czy?

Poprosiłbym bezpośrednio administratora systemu, ale nie chcę wyglądać na idiotę i marnować wszystkich pomiędzy nami. Czy powinienem po prostu zignorować klucz, który mi przysłał, i poprosić ich o umieszczenie mojego klucza publicznego w autoryzowanym folderze?

ssh security key-authentication administration Toby
źródło

Nie nazwałbym tego normalnym ani rozsądnym, ale skoro masz klucz prywatny (zakładając, że już dodali go jako autoryzowanego), możesz go używać tak jak każdego innego klucza prywatnego. Nie potrzebujesz odpowiedniego klucza publicznego, ale jeśli chcesz, zawsze możesz go wygenerować: askubuntu.com/a/53555/158442

muru

Przekazywanie -----BEGIN RSA PRIVATE KEY-----wiadomości e-mail to kolejna przerażająca rzecz po zobaczeniu użytkownika wymienionego '); DROP DATABASE;--w tabeli nazw użytkowników.

Dmitrij Grigoryev,

@DmitryGrigoryev nic strasznego w postrzeganiu '); DROP DATABASE;--nazwy użytkownika w tabeli bazy danych - pokazuje, że poprawnie

unikałeś

Z pewnością nie możesz „użyć go tak, jak innego klucza prywatnego”. Ten nie jest prywatny. Ergo to nie może pełnić funkcji, dla której zostało utworzone. Powinien zostać wyrzucony, a administrator systemu UNIX surowo ukarany. @muru

user207421,

Każdy, kto ma ten klucz prywatny, ma dostęp do nowych serwerów. Prawdopodobnie administrator i tak ma dostęp bez potrzeby posiadania klucza, ponieważ jest w stanie skonfigurować serwer, więc nie ma dodatkowego zagrożenia ze strony nieautoryzowanego dostępu. Ponieważ jednak jest to Twój klucz, może on w wiarygodny sposób podszyć się pod Ciebie. Istnieje również szansa, że ktoś inny niż ty przeczyta wiadomość e-mail, a następnie może ona również podszyć się pod Ciebie.

immibis,

Odpowiedzi:

116

Teraz myślę, że wyślę im mój klucz publiczny, który można umieścić w folderze kluczy autoryzowanych.

To, co „masz na myśli”, ponieważ to, co powinno się teraz wydarzyć, jest prawidłowe.

Poczta e-mail nie jest bezpiecznym kanałem komunikacji, dlatego z punktu widzenia odpowiedniego bezpieczeństwa należy (i oni) rozważyć naruszenie tego klucza prywatnego.

W zależności od twoich umiejętności technicznych i tego, jak chcesz być dyplomatyczny, możesz zrobić kilka różnych rzeczy. Poleciłbym jedno z poniższych:

Wygeneruj własną parę kluczy i dołącz klucz publiczny do wysłanego do nich e-maila, mówiąc:

Dzięki! Ponieważ e-mail nie jest bezpieczną metodą dystrybucji kluczy prywatnych, czy możesz zamiast tego umieścić mój klucz publiczny? Jest dołączony.
Podziękuj im i zapytaj, czy sprzeciwiają się zainstalowaniu Twojej pary kluczy, ponieważ przesłany przez nich klucz prywatny powinien zostać uznany za zagrożony po wysłaniu pocztą e-mail.

Wygeneruj własną parę kluczy, użyj klucza, który wysłali do pierwszego logowania, i skorzystaj z tego dostępu, aby edytować authorized_keysplik zawierający nowy klucz publiczny (i usuń klucz publiczny odpowiadający skompromitowanemu kluczowi prywatnemu).

Konkluzja: Nie będziesz wyglądać jak idiota. Ale drugiego administratora można bardzo łatwo wyglądać jak idiota. Dobra dyplomacja mogłaby tego uniknąć.

Edytuj w odpowiedzi na komentarze MontyHarder:

Żaden z moich sugerowanych sposobów działania nie obejmuje „naprawiania rzeczy bez mówienia drugiemu administratorowi, co zrobił źle”; Po prostu zrobiłem to delikatnie, nie wrzucając go pod autobus.

Jednak dodam, że ja również śledzić (grzecznie) jeśli subtelne wskazówki nie odebrano:

Witaj, widziałem, że nie odpowiedziałeś na mój komentarz na temat e-maila jako niebezpiecznego kanału. Chcę mieć pewność, że to się więcej nie powtórzy:

Czy rozumiesz, dlaczego mówię o bezpiecznej obsłudze kluczy prywatnych?

Najlepsza,

Toby

Dzika karta
źródło

+1 Najlepsza odpowiedź. I dodałbym: bądź szczególnie ostrożny, ponieważ ten sysadmin okazał się niekompetentny. Lepiej chroń plecy, gdy (a nie jeśli ) zepsuje serwer na dobre.

dr01,

Dzięki. Użyłem delikatnego sformułowania i przesłałem swój klucz publiczny. Wszystko wygląda na rozwiązane, ale cofnę autoryzację klucza, który mi teraz przysłał.

Toby

Nie chodzi o to, że drugiego administratora „można było sprawić, by wyglądał jak idiota”. Chodzi o to, że drugi administrator zrobił coś idiotycznego. Mogę wymyślić tylko jeden scenariusz, w którym klucz prywatny powinien być współużytkowany między komputerami, i tam jest dostęp do puli serwerów za pomocą tej samej nazwy (rozpoznawanie DNS w trybie round-robin itp.) I musi przedstawić ten sam klucz hosta SSH, aby zautomatyzowane procesy zaakceptują, że mają taką nazwę. W takim przypadku ta sama osoba byłaby administratorem wszystkich serwerów i obsługiwałaby przelewy bez udziału strony trzeciej.

Monty Harder

@zwol W mojej pracy obowiązuje filozofia „bez winy”, która rozumie, że popełniamy błędy, ale priorytetem jest, aby nie popełniać tego samego błędu dwa razy. Ale żeby nie popełnić tego samego błędu dwa razy, musisz wiedzieć, że to pomyłka, dlatego nie mogę głosować za odpowiedziami sugerującymi, że OP po prostu naprawia rzeczy, nie mówiąc drugiemu administratorowi, co zrobił źle. Zdecydowałem się nazywać ten błąd „idiotycznym”, zamiast nazywać się administratorami właśnie z tego powodu. (Ale nie jestem pewien, czy Twój nawias końcowy zawiera znaczące rozróżnienie.)

Monty Harder,

@LightnessRacesinOrbit, podejrzewam, że masz niepełne zrozumienie znaczenia „dyplomacji”. Czy próbowałeś wyjaśnić to w dobrym słowniku, takim jak Trzeci Nowy Międzynarodowy Słownik Webstera?

Wildcard

Czy powinienem po prostu zignorować klucz, który mi przysłał, i poprosić ich o umieszczenie mojego klucza publicznego w autoryzowanym folderze?

Tak, właśnie to powinieneś zrobić. Chodzi o to, że klucze prywatne są prywatne , co oznacza, że tylko ty masz swój klucz prywatny. Ponieważ otrzymałeś ten klucz od administratora, on również go ma. Dzięki temu może podszyć się pod ciebie w dowolnym momencie.

Nie ma znaczenia, czy klucz został wysłany za pośrednictwem bezpiecznego kanału, czy nie: nawet jeśli osobiście otrzymałeś swój klucz prywatny, nic by to nie zmieniło. Chociaż zgadzam się z komentarzami, że e-maile wrażliwe klucze kryptograficzne to wisienka na torcie: administrator nawet nie udaje, że istnieje jakaś polityka bezpieczeństwa.

Dmitrij Grigoriew
źródło

A ponieważ OP nie ma sposobu, aby dowiedzieć się, jak bezpieczna jest maszyna administratora (na podstawie historii, prawdopodobnie bardzo niepewnej), powinien założyć, że klucz prywatny jest (lub będzie) wyciekł również na inne osoby. Wysłanie klucza prywatnego pocztą e-mail jest dodatkowym faktem dla nieświadomości infosec.

dr01

Możesz założyć, że administrator, który jest w stanie tworzyć użytkowników, nie będzie potrzebował twojego klucza prywatnego do podszywania się pod Ciebie.

Max Ried

@MaxRied Może to być trudne z odpowiednimi dziennikami bezpieczeństwa. Za pomocą twojego klucza prywatnego nie musi nawet wyśmiewać dzienników. To tak, jakbyś mógł zresetować hasło, a nie znać swojego hasła.

Dmitrij Grigoryev,

@DmitryGrigoryev Zawsze może dodać kolejny klucz do pliku uprawnionych kluczy ...

Max Ried

@MaxRied Mówiłem o tym /var/log/securelub podobnym , jestem prawie pewien, że sztuczka kosmiczna tego nie zmyli.

Dmitrij Grigoriew

Dla mnie wygląda na to, że administrator wygenerował dla ciebie parę kluczy prywatny / publiczny, dodał klucz publiczny do kluczy autoryzowanych i wysłał ci klucz prywatny. W ten sposób musisz używać tego klucza prywatnego tylko do sesji ssh z serwerem. Nie musisz samodzielnie generować pary kluczy ani wysyłać administratorowi klucza publicznego do twojego prawdopodobnie uszkodzonego (zawsze pomyśl najgorszego przypadku: P) klucza prywatnego.

Jednak nie ufam kluczowi prywatnemu wysłanemu do Ciebie za pośrednictwem niezaszyfrowanej poczty.

Moje podejście brzmiałoby: użyj klucza prywatnego, aby się zalogować, dodać własny klucz publiczny do kluczy autoryzowanych na serwerze (zastępując oryginalny klucz publiczny) i wyrzucić ten prywatny klucz e-mail. Możesz następnie podziękować administratorowi, że dostarczył ci klucz prywatny, ale wolałbyś, aby takie informacje / klucze nie były wysyłane pocztą elektroniczną (/ w ogóle).

użytkownik204269
źródło

@Toby Jedynym powodem, dla którego mogę sobie wyobrazić, że wysyłają klucz prywatny, jest to, że nie rozumieją używanych przez nich narzędzi. I możesz użyć -iw wierszu polecenia, aby wybrać klucz prywatny, którego chcesz użyć.

kasperd

@kasperd Powodem, dla którego mogę sobie wyobrazić, jest przepracowany sysadmin, który zdecydował, że ryzyko związane z wysyłaniem klucza prywatnego przez e-mail jest niwelowane przez kłopoty z próbą wyjaśnienia mniej zaawansowanym użytkownikom, jak prawidłowo wygenerować parę kluczy i wysłać klucz publiczny z powrotem.

mattdm,

Świetnie, że możesz to naprawić samodzielnie. Lepiej zrób to sam, niż czekanie, aż administrator zainstaluje klucz publiczny dla nowej pary kluczy. Unikanie używania niejawnego klucza prywatnego nic nie pomaga; po prostu daje potencjalnym podsłuchującym więcej czasu na użycie go, zanim będziesz mógł wejść i usunąć go authorized_keys(po dodaniu + przetestowanie własnego).

Peter Cordes,

@mattdm To ... jest całkowicie logiczne, ale przerażające. Osoba, która nie może wygenerować pary kluczy i wysłać mi klucza publicznego, prawdopodobnie nie zrobi nic lepszego z kluczem prywatnym, który mu dam.

Monty Harder

@mattdm, w porządku, ale ponieważ to ja poprosiłem go o zrobienie tego wszystkiego, trudno mi uwierzyć, że myślał, że nie wiem, jak połączyć się z ssh. W każdym razie kroki, które podjął, były bardziej mylące, ponieważ znam tylko podstawowy powszechny sposób korzystania z kluczy publicznych. : x

Toby