W naszej aplikacji przesyłamy pliki na zdalny serwer, a wymaganą metodą uwierzytelnienia jest użycie kluczy SSH.
Tak więc utworzyłem parę kluczy za pomocą ssh-keygen i przesłałem mój klucz publiczny do wstawienia do pliku autoryzowanych kluczy zdalnego hosta. Zostało to jednak odrzucone przez IT Security, który powiedział, że wygeneruje dla mnie parę kluczy i wyśle mi klucz prywatny. Powód: „Potrzebujemy podpisu kluczy SSH przez zespół ds. Bezpieczeństwa IT. Ma to na celu zapewnienie nam pewnej przewagi w zakresie śledzenia i rozliczalności”.
Oczywiście mam z tym problemy. Generowanie klucza prywatnego przez kogoś innego oznacza, że mogę mieć tę osobę, która przebiera się za mnie bez mojej wiedzy. Próbuję znaleźć sposoby na obalenie tego argumentu.
O ile mogę google, wydaje się, że nie ma znanego sposobu podpisywania kluczy, który pomógłby w śledzeniu osoby, która się zalogowała. Fakt, że przesłałem klucz publiczny, oznacza, że jestem właścicielem tego klucza, a każda osoba, która zaloguje się na zdalnym serwerze przy użyciu tego klucza, jest domyślnie identyfikowana jako ja. W jaki sposób podpisywanie byłoby pomocne? A jak by się podpisali?
Niech ktoś mnie oszuka, jeśli się mylę, dzięki!
Ok, teraz, kiedy ustaliliśmy, że nie ma możliwości podpisania kluczy SSH, muszę pokazać IT Security, w jaki sposób mogą faktycznie śledzić, kto się loguje (chyba konstruktywnie, jeśli nie, zaczyna się od wysokiej rangi) ). Na własnym serwerze ustawiłem LogLevel sshd na DEBUG. Więc teraz, kiedy się loguję, widzę następujący fragment:
Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
To wydaje się być wartością skrótu. Jak powiązać to z tym, który klucz publiczny w pliku autoryzowanych_ kluczy został użyty? Wiem, że jest inna linia, która mówi:
debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1
ale nie jest to tak przydatne, ponieważ numery wierszy można łatwo zmienić, gdybym wstawił klucz u góry pliku, naciskając oryginalne klucze w dół.
Dzięki!
Odpowiedzi:
Od czasu, kiedy zadałeś swoje pytanie, wszechświat się zmienił.
Openssh5.4 dodał obsługę dokładnie tego rodzaju certyfikatów, o które chodziło. Aby uzyskać więcej informacji, zobacz informacje o wersji na stronie http://www.openssh.org/txt/release-5.4 (i strony podręcznika man), a jeśli naprawdę chcesz być szalony, zajrzyj do PROTOCOL.certkeys, aby uzyskać szczegółowe informacje na temat krwawych szczegółów
źródło
Moje pierwsze wrażenie podczas czytania twojego pytania polega na tym, że osoba IT pomieszała SSH i SSL (musi być przez nas podpisany), a także nie rozumie, jak naprawdę działa podpisywanie SSL.
W każdym razie nie ma możliwości podpisania klucza SSH (o którym wiem).
źródło
Coś jest nie tak z tym żądaniem.
Jeśli dostarcza podpisane pliki na serwer,
oczekiwałbym , że zostanie to zrobione na minimum.
my-key-privatemy-key-pubdo odszyfrowania plikuIstnieją inne sposoby robienia takich rzeczy,
jednak uzyskanie pary kluczy wygenerowanej przez kogoś innego jest bezużyteczne jako schemat uwierzytelniania .
Ma to silną implikację, że ufasz im tak samo jak sobie.
Oto pytania wstępne, które możesz zadać swojemu IT.
Jeśli odpowiedzialność dotyczy IT,
W takim razie po co męczyć się z parami kluczy.
źródło
Nie ma powodu, dla którego nie można używać certyfikatów X.509 do uwierzytelniania SSH zamiast samych kluczy - w rzeczywistości wolałbym, aby OpenSSH działał w ten sposób! Ale standardowa wersja OpenSSH tego nie robi i jest to obecnie dominująca implementacja.
Widziałem kilka poprawionych wersji OpenSSH unoszących się wokół nich, a komercyjna implementacja SSH.com wydaje się również obsługiwać uwierzytelnianie X.509. Tak więc, jeśli Twoja organizacja korzysta z jednego z nich, wymóg podpisywania kluczy przez organ centralny miałby sens.
To powiedziawszy, nie ma usprawiedliwienia dla wymogu generowania klucza prywatnego przez firmę zewnętrzną! Jeśli wybierają trasę X.509, powinni wygenerować parę kluczy i żądanie podpisania certyfikatu, tak jak w przypadku każdego innego certyfikatu X.509 używanego do SSL itp.
źródło