Dlaczego produkty JetBrains wykorzystują klucz prywatny przy tunelu SSH?

Odpowiedz Nowy wątek
2017-02-04 17:12
0

Do tej pory udawało mi się stawiać tunele trochę inaczej niż bym chciał, bo znałem hasło swojego użytkownika, więc tak też się łączyłem - z użyciem hasła.

Niestety jest jeden serwer z którym jedyną możliwością połączenia się jest połączenie z użyciem klucza publicznego, który siedzi w authorized_keys.

Nie rozumiem dlaczego wymagane jest ode mnie podanie ścieżki do klucza prywatnego. Z tego wynika, że nie jest to bezpieczne i nie powinno mieć miejsca. Wątpie, żeby JetBrains popełniło taką gafę, więc domyślam się, że to ja tu czegoś nie rozumiem i proszę o oświecenie.

edytowany 3x, ostatnio: Desu, 2017-02-04 17:18

Pozostało 580 znaków

2017-02-04 17:23
1

Chyba ci się coś pomieszało. Na SO gość pyta się czy bezpieczne jest wysłanie swojego klucza prywatnego na zewnątrz - oczywiście, że nie jest. Klucz prywatny, jak sama nazwa wskazuje, powinien być prywatny i nikomu nie pokazywany. To klucz publiczny można i trzeba rozsyłać wszędzie tam gdzie chcemy mieć za jego pomocą dostęp. Klucz prywatny jest jednak niezbędny do nawiązywania połączeń - tylko dzięki niemu jesteś w stanie udowodnić to, że klucz publiczny należy do ciebie. Gdyby klucz prywatny nie był potrzebny do nawiązywania połączenia to wtedy cały pomysł z asymetrycznymi kluczami nie miałby sensu - każdy mógłby się pod każdego innego podszywać, wykorzystując tylko klucze publiczne.

Gwoli ścisłości - to udowadnianie tożsamości można przedstawić na przykładzie algorytmu RSA: https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Operation W RSA można szyfrować zarówno prywatnym jak i publicznym kluczem. Trzeba tylko pamiętać, by przy deszyfracji użyć drugiego typu klucza, a więc przy szyfrowaniu kluczem publicznym trzeba odszyfrować prywatnym i vice versa. Jeśli chcę sprawdzić czy posiadasz klucz prywatny dla podanego klucza publicznego to:

  • losuję dużą liczbę,
  • szyfruję ją twoim kluczem publicznym,
  • wysyłam do ciebie i oczekuję, że odeślesz mi tę liczbę w formie odszyfrowanej,
  • ty możesz ją odszyfrować tylko i wyłącznie mając klucz prywatny i to jego używasz do deszyfracji,
  • ja otrzymuję od ciebie odszyfrowany klucz, porównuję z oryginałem i na podstawie tego stwierdzam czy jesteś właścicielem klucza prywatnego,

Przy podpisie elektronicznym kluczy używa się w odwrotnej kolejności. Jeżeli chcę podpisać dokument to:

  • najpierw liczę jego hash, by mieć niewielką ilość informacji do zaszyfrowania,
  • otrzymany hash szyfruję swoim kluczem prywatnym,
  • zaszyfrowany hash (+ może jakieś tam mniej znaczące dodatki) jest moim podpisem elektronicznym,
  • ów podpis elektroniczny mogę sobie wszędzie gdzie chcę publikować,
  • każdy kto znajdzie ten podpis i oryginalny dokument może stwierdzić czy ten podpis został wygenerowany przeze mnie,
  • sprawdzenie odbywa się przez deszyfrację hasha za pomocą mojego klucza publicznego i sprawdzenie czy jest identyczny z hashem wygenerowanym ponownie z podpisywanego dokumentu,

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 3x, ostatnio: Wibowit, 2017-02-04 17:36

Pozostało 580 znaków

2017-02-04 17:31
0

A widzisz, nie do końca wiedziałem jak to działa, więc stwierdziłem, że skoro mój klucz publiczny jest w authorized_keys, to powinienem podać ścieżkę do klucza, który tam siedzi. Skoro oni chcą prywatny, to pierwsza myśl była taka, że żeby to zadziałało to klucz prywatny powinienem zapakować do authorized_keys, a to już wzbudziło moje wątpliwości.

Okazało się, że nie podałem passphrase. Jak łączę się przez terminal, to mnie o niego nie pyta, więc myślałem, że to nie ma znaczenia :) W sumie jak generowałem klucz, to nie przypominam sobie, żebym podawał passphrase... ale jako passphrase zadziałało moje hasło, które użyłem przy szyfrowaniu dysku (podczas instalacji Ubuntu jest taka opcja).

Dzięki za dodatkowe wyjaśnienie.

edytowany 2x, ostatnio: Desu, 2017-02-04 17:34

Pozostało 580 znaków

2017-02-04 17:42
1

Najpierw upewnij się dlaczego jesteś pytany o hasło. SSH może pytać cię o hasło z dwóch powodów:

  • serwer nie rozpoznał twojego klucza publicznego, więc przeszedł w tryb pytania o hasło,
  • serwer cię rozpoznał, ale zaszyfrowałeś swój klucz prywatny,

Jeśli przy łączeniu się przez terminal SSH nie pyta cię o hasło to chyba nie zaszyfrowałeś swojego klucza prywatnego. W związku z tym jeśli inny klient SSH (tu: produkt JetBrains) pyta cię o hasło to pewnie podałeś złą ścieżkę do klucza publicznego i serwer cię nie rozpoznał. Ale to tylko zgadywanie. Posprawdzaj to jeszcze. Pamiętaj tylko by nie wysyłać nikomu klucza prywatnego, ani nie dopisywać go nigdzie do authorized_keys. W authorized_keys trzymamy tylko klucze publiczne!


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-02-04 18:08
0

Ależ sprawa jest prosta. Musisz wskazać klucz ponieważ Idea nie wie, którego ma użyć. Możesz mieć wiele par kluczy do łączenia się z różnymi hostami. W zwyczajnym linuxowym kliencie ssh masz folder .ssh i leci on przez zdefiniowane tam klucze próbując dobrać właściwy. Idea musi działać też na takim Windowsie, gdzie nie masz zdefiniowanego katalogu z kluczami.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0