Czy istnieje coś takiego jak podpisana para kluczy SSH?

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!

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

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).

Coś jest nie tak z tym żądaniem.

Jeśli dostarcza podpisane pliki na serwer,
oczekiwałbym , że zostanie to zrobione na minimum.

1. Tworzysz dla siebie parę kluczy (nazwij ten mój klucz)
   • Kiedy chcesz coś wysłać,
   • najpierw go zaszyfrujesz my-key-private
   • następnie przesłał na serwer ten zaszyfrowany plik
   • Ktoś na serwerze musi odwrócić ten proces,
   • używają twojego my-key-pubdo odszyfrowania pliku
   • jeśli wysłałeś plik, odszyfrujesz go
   • w przeciwnym razie nie otrzymają żadnego użytecznego pliku
   • skutecznie podpisałeś plik swoim kluczem prywatnym
   • zweryfikowali podpis za pomocą twojego klucza publicznego
   • odpowiedzialność jest przez nich potwierdzana, że ​​wysłałeś plik

Istnieją 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,

1. W jaki sposób upewniają się, że nie udostępniasz / nie tracisz podanej Ci pary kluczy? i,
   • Czym różni się ta koncepcja klucz-para-od-IT od hasła podanego przez IT?
     W takim razie po co męczyć się z parami kluczy.

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.