Uwierzytelnianie SSH przy użyciu gssapi-keyex lub gssapi-with-mic (publickey nie jest dozwolone)

Moja firma wyłączyła uwierzytelnianie klucza publicznego SSH, dlatego muszę ręcznie wpisywać hasło za każdym razem (nie mam zamiaru tego zmieniać /etc/ssh/sshd_config).

Jednak gssapi-keyexi gssapi-with-micuwierzytelnianie są włączone (patrz poniżej sshdebugowania).

Jak mogę użyć automatycznego logowania w tym przypadku?
Czy mogę wykorzystać gssapi-keyexi / lub gssapi-with-micuwierzytelnienia?

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

Może.

• Czy możesz uzyskać bilet na swojego zleceniodawcę w systemie klienta w ramach standardowego procesu logowania lub ręcznie ( kinitMIT Kerberos dla Windows)?
• Czy serwer ma nazwę Kerberos, czy możesz ją podać? Powinien mieć formę host/server.example.com@EXAMPLE.COM.
• Czy GSSAPIuwierzytelnianie jest włączone na twoim kliencie?
• Czy Twój klient wie, do jakiej dziedziny należy serwer, za pomocą rekordu zasobu DNS TXT lub lokalnego mapowania?

Jeśli powiedziałeś „tak” wszystkim powyższym, to gratulacje, możesz użyć GSSAPIAuthentication.

• W zależności od konfiguracji może być konieczne włączenie delegowania poświadczeń.

Kroki testowania:
(Zakładając: domena = przykład.com; dziedzina = PRZYKŁAD.COM)

1. kinit username@EXAMPLE.COM
   • Idealnie to jest obsługiwane przez standardowy proces logowania przez włączenie albo pam_krb5lub pam_sss(z auth_provider = krb5) w odpowiednim pam stack.
2. kvno host/server.example.com@EXAMPLE.COM
   • To jest krok debugowania. sshrobi to automatycznie, jeśli masz prawidłową pamięć podręczną i rozmawiasz z urządzeniem sshdobsługującym gssapi-with-miclub gssapi-keyex.
3. dig _kerberos.example.com txt powinien wrócić "EXAMPLE.COM"
   • Alternatywnie mapowanie może być przechowywane w [domain_realm]sekcji /etc/krb5.confas .example.com = EXAMPLE.COM, ale dnsmetoda skaluje się znacznie lepiej.
4. ssh -o GSSAPIAuthentication=yes username@server.example.com
   • Aby zalogować się do nazwy użytkownika innej niż nazwa użytkownika na serwerze, trzeba będzie ją zmapować, której szczegółów nie wymienię tutaj.

Metoda 4-etapowa jest poprawna (w DNS są również rekordy Kerberos SRV w DNS, które są jeszcze bardziej eleganckie i są obecne w każdej usłudze Active Directory). Korzystam z tego cały czas i opowiadam się za powyższymi metodami ze względu na bezpieczeństwo i kontrolę.

To powiedziawszy, daje to tylko interaktywne logowanie, chociaż może być quasi-interaktywne, gdy zdobędziesz bilet na stacji roboczej. Bilet Kerberos działa podobnie jak agent SSH; gdy już to zrobisz, nowe połączenia będą natychmiastowe i pozbawione hasła; aczkolwiek z ograniczeniem czasowym.

Aby uzyskać interaktywne logowanie wsadowe, musisz uzyskać plik tabeli kluczy, który zasadniczo zawiera hasło do konta Kerberos, podobnie jak prywatna połowa klucza SSH. Obowiązują odpowiednie środki bezpieczeństwa; zwłaszcza, że ​​keytab nie jest szyfrowany ani chroniony hasłem.

Nie chcę podawać użytkownikom swoich kluczy do kont osobistych, ale agresywnie używam kont usług z minimalnymi uprawnieniami do różnych zadań wsadowych, szczególnie tam, gdzie kluczowe jest przekazanie poświadczeń do systemu zdalnego, coś po prostu może „ osiągnąć.

Klawisze kluczy można tworzyć za pomocą ktutil w systemie Unix lub KTPASS.EXE w systemie Windows (ten ostatni z usług AD Kerberos). Zauważ, że ktutil występuje w dwóch odmianach: Heimdal i MIT, a ich składnia jest różna. Pomaga odczytanie strony podręcznika na odpowiednim systemie.