Jakie są wymagane kroki w celu uwierzytelnienia użytkowników z usługi Active Directory działającej w systemie Windows Server 2012 R2 we FreeBSD 10.0 przy użyciu sssdzaplecza AD przy działającym Kerberos TGT?

Istnieje kilka trudnych kwestii, aby wszystko działało od razu po wyjęciu z pudełka. FreeBSD obsługuje obecnie tylko sssdwersję 1.9.6. Dlatego nie ma obsługi głównych nazw korporacyjnych.

Jeśli masz domenę z niepasującymi UPN, logowanie się nie powiedzie, ponieważ uwierzytelnianie Kerberos zakończy się niepowodzeniem podczas procesu, nawet jeśli FreeBSD obsługuje główne nazwy korporacyjne z Kerberos, sssdnie może obsłużyć tego przypadku.

W rzeczywistej wersji sssdjesteś ograniczony do głównej nazwy użytkownika w tej samej nazwie domeny, na przykład:

Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
username@example.com sAMAccountName: username

Znając to, możemy opisać kroki do pomyślnego uwierzytelnienia użytkowników z AD we FreeBSD.

1. Skonfiguruj Kerberos

Utwórz plik /etc/krb5.confo następującej treści:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = yes

2. Zainstaluj Sambę 4.1 i skonfiguruj, aby dołączyć do domeny

Zainstaluj Samba 4.1:

$ pkg install samba41

Utwórz plik /usr/local/etc/smb4.confo następującej treści:

[global]
    security = ads
    realm = EXAMPLE.COM
    workgroup = EXAMPLE

    kerberos method = secrets and keytab

    client signing = yes
    client use spnego = yes
    log file = /var/log/samba/%m.log

Poproś o bilet Kerberos administratora:

$ kinit Administrator

Następnie dołącz do domeny i utwórz keytab

$ net ads join createupn=host/server-hostname.example.com@EXAMPLE.COM -k
$ net ads keytab create -k

3. Zainstaluj pakiet sssd i Cyrus SASL z obsługą Kerberos

Zainstaluj wymagane pakiety:

$ pkg install sssd cyrus-sasl-gssapi

Edytuj plik, /usr/local/etc/sssd/sssd.confaby dopasować te ustawienia:

[sssd]
    config_file_version = 2
    services = nss, pam
    domains = example.com

[nss]

[pam]

[domain/example.com]
    # Uncomment if you need offline logins
    #cache_credentials = true

    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad

    # Comment out if the users have the shell and home dir set on the AD side
    default_shell = /bin/tcsh
    fallback_homedir = /home/%u

    # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
    #ldap_sasl_mech = GSSAPI
    #ldap_sasl_authid = SERVER-HOSTNAME$@EXAMPLE.COM

4. Dodaj obsługę sssd do nsswitch.conf

Edytuj plik, /etc/nsswitch.confaby dopasować te ustawienia:

group: files sss
passwd: files sss

5. Skonfiguruj PAM, aby umożliwić uwierzytelnianie sssd i obsługiwać tworzenie katalogu domowego

Zainstaluj opcjonalne pakiety do tworzenia katalogu domowego:

$ pkg install pam_mkhomedir

Zmodyfikuj niezbędne PAMdziedziny, aby dopasować te ustawienia:

auth            sufficient      /usr/local/lib/pam_sss.so
account         required        /usr/local/lib/pam_sss.so        ignore_unknown_user
session         required        /usr/local/lib/pam_mkhomedir.so  mode=0700
session         optional        /usr/local/lib/pam_sss.so
password        sufficient      /usr/local/lib/pam_sss.so        use_authtok

6. Przejdź do klienta OpenLDAP z obsługą SASL

$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client

7. Na koniec potwierdź, że wszystko działa

$ getent passwd <username>

Którego protokołu Kerberos używasz tutaj? Wbudowany czy security / krb5 z MIT?

Podczas instalacji sssd wymaga zainstalowania security / krb5, które w tej chwili jest nadal uważane za eksperymentalne we FreeBSD. Zatem to pytanie.

Nie mam szczęścia w uzyskiwaniu użytkowników / grup AD podczas wykonywania poleceń „getent”. może to wynikać z faktu, że nazwa NETBIOS różni się od nazwy domeny -ie w moim przypadku nazwa domeny to dawnsign.com, a nazwa NETBIOS to DSP.

Skonfigurowałem tylko moduł logowania pam.d. Jakie inne moduły pam należy edytować, aby uwierzytelnienie przebiegło pomyślnie?

Wszelkie dodatkowe informacje będą mile widziane!

Ponowna kompilacja samba4 z portów jest możliwa przy użyciu uwierzytelnienia winbind, takiego jak Linux, nawet bez sssd. Po prostu ponownie skompiluj samba4 z portów po włączeniu sasl ldap

    pkg remove samba41 
    pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb 
    pkg remove -f openldap-client 
    pkg install openldap-sasl-client 
    cd /usr/ports/security/sssd && make install

Spowoduje to rekompilację samby z wszelkim niezbędnym wsparciem (gssapi, ldap, kerberos), a następnie edycję pliku nsswitch.conf w ten sposób

passwd: files winbind
group: files winbind

Witam

Jest to niewielka aktualizacja dotycząca używania sssd v1.11.7

Jeśli używasz „id_provider = reklama” i widzisz następujący błąd w pliku dziennika sssd:

/var/log/sssd/sssd_example.com.log
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-12)[Not Supported]
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error]

Aby rozwiązać ten problem i sprawić, że integracja AD działa poprawnie, możesz użyć poniższej procedury. Teraz buduj sssd v1.11.7 z obsługą Samby, potrzebna jest kompilacja z src sssd, więc jest ona połączona z libsasl2

​pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install

Oto mój przewodnik na temat integracji AD poprzez SSSD z tymi wersjami FreeBSD w momencie pisania tego tekstu (6/2017)

• FreeBSD 10.3 i 11.0 (10.3-RELEASE-p18 i 11.0-RELEASE-p9)

• Instalacja (i zabawne problemy z pakowaniem i zależnością)

  • Wymagane pakiety nie wydają się być kompatybilne z Heimdal Kerberos, więc rzeczy muszą zostać zainstalowane i skompilowane z włączonymi flagami MIT Kerberos. Jest to prawdopodobnie bardziej problem zależności od opakowania niż faktyczny problem ze zgodnością.
  • Heimdal jest instalowany z systemem podstawowym, więc pozostawia Ci dwa zestawy poleceń Kerberos, jeśli zainstalujesz MIT Kerberos, jeden zestaw w /usr/bin, a drugi w /usr/local/bin. Ponieważ żaden z podstawowych plików systemowych nie wydaje się być w pakiecie, nie można po prostu usunąć Heimdal KRB. Coś, o czym należy pamiętać.

  • Przekazywanie zależności między różnymi pakietami (interesujące pogrubione pisma, sprzeczne pogrubione kursywa):

    • net-mgmt/adcli:net/openldap24-sasl-client
    • security/cyrus-sasl2-gssapi: security/cyrus-sasl2
    • net/openldap24-sasl-client: security/cyrus-sasl2
    • security/sssd: security/nss
    • security/sssd:security/krb5
    • security/sssd: security/cyrus-sasl2
    • security/sssd:net/openldap24-client
    • security/sssd: lang/python27
    • security/sssd: lang/python2
    • security/sssd: dns/c-ares
    • security/sssd: devel/tevent
    • security/sssd: devel/talloc
    • security/sssd: devel/popt
    • security/sssd: devel/pcre
    • security/sssd: devel/libunistring
    • security/sssd: devel/libinotify
    • security/sssd: devel/gettext-runtime
    • security/sssd: devel/ding-libs
    • security/sssd: devel/dbus
    • security/sssd: databases/tdb
    • security/sssd: databases/ldb

  • Odwróć zależności różnych pakietów:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • Jak widzimy sssd, wymaga MIT Kerberos, mimo że Heimdal jest pakietem podstawowym
      • adclichce openldap-sasl-client, ale dołączają się inne pakiety (w tym zależności zależne sssd) openldap-client, co jest mutexem z klientem sasl (z jakiegokolwiek niemądrego powodu). To sprawia, że ​​instalacja jest trochę uciążliwa, nawet przy minimalnym zestawie pakietów binarnych.
      • Zależności te występują zarówno w przypadku binarnych pakietów repo, jak i jeśli pakiety są wbudowane w drzewo portów. Wymaga to irytującej konkretnej metody instalacji, aby uzyskać wszystko, czego potrzebujemy (omówione poniżej).

  • W tym momencie binarne pkg dla SSSD dla FreeBSD nie obejmuje obsługi AD w SSSD

    • Wersja SSSD dla portów musiała zostać zbudowana z włączonymi odpowiednimi opcjami (make config):
      • SMB
    • SSSD chce również pobrać klienta openldap, kiedy naprawdę potrzebuje klienta openldap-sasl do poprawnego działania.
  • Binarna wersja pkg adcliistnieje, ale w chwili pisania tego tekstu nie działa.
    • Ponownie wersja portów została skompilowana z włączonymi odpowiednimi opcjami:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi jest wymagana, ale wersja binarna pkg nie działa i ma dziwne problemy z zależnością, które powodują, że usuwa SSSD.
    • Zbuduj go z portów z włączoną opcją MIT-KRB5:
      • GSSAPI_MIT
  • openldap-sasl-client jest wymagany dla funkcjonalności, ale SSSD chce pobrać wersję Openldap inną niż SASL.
    • Aby to zadziałało
      • skonfiguruj openldap-sasl-clientz GSSAPIopcją wybraną ( make config) w portach.
      • Zrób make w portach, aby go zbudować
      • Przed instalacją wykonaj pkg remove –f openldap-client
        • Spowoduje to usunięcie openldap-clientbez robienia jakichkolwiek zapisków jakichkolwiek innych pakietów (takich jak SSSD) i umożliwi instalację wersji SASL
      • Wykonaj make install dla openldap-sasl-client
        • Spowoduje to zainstalowanie go w systemie
  • Zapewni to to, co jest potrzebne do funkcjonalnego dysku SSSD z funkcjami AD.
  • Pamiętaj, że jeśli skompilujesz SSSD z portów, pociągnie za sobą wiele zależności, co spowoduje, że zostaną one zbudowane i będą wymagać wybrania opcji konfiguracji.
    • Zaleca się, aby najpierw zainstalować pakiet binarny za pomocą pkg install sssd, a następnie go usunąć pkg remove –f sssd
      • Spowoduje to, że pakiety binarne dla większości rzeczy, które należy pobrać z SSSD, i wyeliminują potrzebę budowania wszystkich tych portów w portach, co zajmuje sporo czasu.
    • Po usunięciu zainstaluj ponownie dysk SSSD z portów z włączonymi wyżej wymienionymi opcjami, a będziesz musiał tylko odbudować cztery wymienione wyżej pakiety, aby uzyskać działającą konfigurację.

  • (Opcjonalnie) Gdy wszystko będzie już działać i zweryfikowane, możesz użyć pkg createdo tworzenia pakietów binarnych czterech pakietów z włączonymi odpowiednimi opcjami i używać ich zamiast budować je w portach w każdym systemie. Instalacja pliku binarnego przebiega podobnie do procesu budowania portów:

    • pkg install sssd-1.11.7_8.txz
      • Twoja wersja może być oczywiście inna
      • Spowoduje to zainstalowanie pakietu binarnego dla SSSD i pobranie wszystkiego, czego potrzebuje z repozytorium FreeBSD.
    • pkg add inne pakiety (nie instaluj, nie dodawaj), zachowując pakiet openldap na koniec.
    • Przed dodaniem openldap-sasl-clientwykonajpkg remove –f openldap-client
      • Pozbywa się to wersji innej niż SASL i pozwala na zainstalowanie naszej wersji
    • pkg add openldap-sasl-client-2.4.44.txz
      • Znowu twoja wersja może być inna
    • Powinieneś skończyć z zainstalowanymi wymaganymi pakietami.
    • To może być możliwe, aby zmienić metadane pliku binarnego SSSD przed wykonaniem pkg createzastąpić zależność od openldap-clientz openldap-sasl-clientdo usunięcia trzeba to zrobić usunąć / reinstall. Nie miałem czasu na zrobienie tego.
      • Ponadto istnieją zależności zależne od SSSD, które również się ściągają openldap-client, więc trzeba je również naprawić.
    • Należy pamiętać, że wszystkie te uwagi dotyczą wersji tych pakietów znajdujących się obecnie w drzewie portów w chwili pisania tego tekstu oraz zależności, które z nimi powiązano. Wszystko to może się zmienić, gdy FreeBSD aktualizuje drzewo portów i pliki binarne. Może kiedyś będziemy mieli binarną wersję wszystkiego, co wyciąga wszystkie właściwe zależności z odpowiednimi opcjami skonfigurowanymi dla funkcji AD od razu po wyjęciu z pudełka.

  • Konfiguracja Kerberos:

    • Przykładowy plik /etc/krb5.conf:

[libdefaults]
   default_realm = MYDOMAIN.NET
   forwardable = true
# Zwykle wszystko, czego potrzebujesz w środowisku AD, ponieważ rekordy DNS SRV
# zidentyfikuje serwery / usługi AD / KRB. Skomentuj, jeśli ty
# chcesz ręcznie wskazać serwer AD
dns_lookup_kdc = true
[dziedziny]
   MYDOMAIN.NET = {
# Jeśli ręcznie wskazujesz na inny serwer AD niż w DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[domain_realm]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET

• (akapit)
  • Konfiguracja SSSD:
    • W tym przykładzie zakłada się atrybuty POSIX w AD dla użytkowników i grup, zwykle wymagane w przypadku zastępowania istniejącego środowiska, które już ustanowiło UID i GID.
    • Przykładowy plik /usr/local/etc/sssd/sssd.conf:

[sssd]
config_file_version = 2
domeny = MYDOMAIN.NET
services = nss, pam, pac
fallback_homedir = / home /% u

[domena / MYDOMAIN.NET]
id_provider = reklama
access_provider = reklama
auth_provider = reklama
chpass_provider = reklama
# użyj atrybutów AD POSIX, skomentuj, jeśli używasz generowanego automatycznie
# UID i GID.
ldap_id_mapping = False
cache_credentials = true
ad_server = adserver.mydomain.net
# jeśli nie masz basha lub cokolwiek jest w loginShell konta AD
# atrybut zainstalowany
override_shell = / bin / tcsh

• (akapit)
  • Konfiguracja PAM:
    • Konfiguracja PAM na FreeBSD jest nieco trudna ze względu na sposób działania OpenPAM. Nie będę wchodził w szczegóły, ale aby użyć pam_sss dla SSSD i sprawić, aby działał, a także aby loginy passwd działały, musisz dwa razy umieścić pam_unix w pliku. Z tego, co rozumiem, ma to związek z dodatkowym sprawdzeniem przeprowadzanym „za kulisami”, które wymaga przejścia drugiego modułu pam_unix.
      • Oto lista /etc/pam.dplików, które musiałem zmodyfikować, aby SSSD działało z FreeBSD:

/etc/pam.d/sshd:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $
#
# Konfiguracja PAM dla usługi „sshd”
#

# auth
auth wystarczające pam_opie.so no_warn no_fake_prompts
wymagane uwierzytelnianie pam_opieaccess.so no_warn allow_local
#auth wystarczające pam_krb5.so no_warn try_first_pass
#auth wystarczające pam_ssh.so no_warn try_first_pass
auth wystarczające pam_unix.so no_warn try_first_pass nullok
auth wystarczające pam_sss.so use_first_pass
wymagane uwierzytelnianie pam_unix.so no_warn use_first_pass

# konto
wymagane konto pam_nologin.so
#account wymagane pam_krb5.so
wymagane konto pam_login_access.so
wymagane konto pam_unix.so
konto wystarczające pam_sss.so

# sesja
#session opcjonalne pam_ssh.so want_agent
sesja opcjonalna pam_sss.so
wymagana sesja tryb pam_mkhomedir.so = 0700
wymagana sesja pam_permit.so

# hasło
# hasło wystarczające pam_krb5.so no_warn try_first_pass
# hasło wystarczające pam_unix.so try_first_pass use_authtok nullok
hasło wystarczające pam_unix.so try_first_pass use_authtok
wystarczające hasło pam_sss.so use_authtok

/etc/pam.d/system:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / system 197769 2009-10-05 09: 28: 54Z des $
#
# Domyślne ustawienia systemowe
#

# auth
auth wystarczające pam_opie.so no_warn no_fake_prompts
wymagane uwierzytelnianie pam_opieaccess.so no_warn allow_local
#auth wystarczające pam_krb5.so no_warn try_first_pass
#auth wystarczające pam_ssh.so no_warn try_first_pass
#auth wymagane pam_unix.so no_warn try_first_pass nullok
auth wystarczające pam_unix.so no_warn try_first_pass
auth wystarczające pam_sss.so use_first_pass
wymagane uwierzytelnianie pam_deny.so

# konto
#account wymagane pam_krb5.so
wymagane konto pam_login_access.so
wymagane konto pam_unix.so
konto wystarczające pam_sss.so

# sesja
#session opcjonalne pam_ssh.so want_agent
wymagana sesja pam_lastlog.so no_fail
sesja opcjonalna pam_sss.so
wymagana sesja tryb pam_mkhomedir.so = 0700

# hasło
# hasło wystarczające pam_krb5.so no_warn try_first_pass
# hasło wymagane pam_unix.so no_warn try_first_pass
hasło wystarczające pam_unix.so no_warn try_first_pass nullok use_authtok
wystarczające hasło pam_sss.so use_authtok
# hasło wymagane pam_deny.so

/etc/pam.d/su:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 15.03.2011 10: 13: 35Z des $
#
# Konfiguracja PAM dla usługi „su”
#

# auth
auth wystarczające pam_rootok.so no_warn
auth wystarczające pam_self.so no_warn
auth Requisite pam_group.so no_warn group = koło root_only fail_safe ruser
auth include system.dist

# konto
konto obejmuje system.dist

# sesja
wymagana sesja pam_permit.so

• (akapit)

  • Uwagi:
    • system.distjest kopią /etc/pam.d/systempliku zapasowego . Jest on zawarty w /etc/pam.d/supowyższym pliku, aby uniknąć problemów z poleceniem su.
    • Nadal można sudodawać konta AD jako root, ponieważ raz root sunie musi się uwierzytelniać, a informacje o koncie są przeciągane przez przełącznik usługi nazw przez SSSD.
    • Jeśli naprawdę chcesz zmienić jednego użytkownika (nie root) na innego użytkownika, powinieneś używać go tylko sudoze względów bezpieczeństwa
    • Możesz także użyć ksui to działa do przełączania z użytkownika A na użytkownika B.
      • Heimdal ksu(in /usr/bin) nie ma domyślnie ustawionego SUID
        • Aby Heimdal ksudziałał,chmod u+s /usr/bin/ksu
      • MIT Kerberos ( krb5pakiet zainstalowany w /usr/local/bin) jest SUID podczas instalacji
    • Ponieważ Heimdal jest częścią pakietu podstawowego, będziesz mieć oba zestawy plików binarnych Kerberos.
      • Możesz dostosować domyślne ścieżki, tak jak /usr/local/binwcześniej /usr/binitd
    • ksu wyświetli monit o podanie hasła AD / Kerberos użytkownika docelowego
    • passwdnie będzie działać, aby zmienić hasło AD / Kerberos, nawet jeśli dodasz pam_sss.sodo pliku PAM passwd. Plik passwdbinarny obsługuje tylko lokalne i NIS Użyj kpasswddo zmiany hasła na serwerach AD / Kerberos.

  • Przełącznik usługi nazw:

    • /etc/nsswitch.confPlik powinien być skonfigurowany do korzystania z usługi dla SSS passwd i grup. Przykład:
      • group: files sss
      • passwd: files sss

  • Dołączanie do domeny:

    • Istnieją dwa główne narzędzia na * nixs, aby dołączyć do twojego Linux-a
      • adcli
        • To jest moje preferowane narzędzie. Działa bardzo dobrze i wszystko można zrobić w jednym wierszu poleceń. Poświadczenia można podawać w sposób nieinteraktywny (poprzez standardowe wejście itp.)
        • Nie wymaga zrobienia kinitprzed użyciem, robi to dla Ciebie na podstawie dostarczonych kredytów.
          • Przykład:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • Ten formularz jest zalecany, ponieważ narzędzie nie zawsze poprawnie rozpoznaje nazwę FQDN. Jeśli podasz nazwę FQDN, która jest zgodna zarówno z DNS do przodu, jak i do tyłu dla hosta, zasady są tworzone poprawnie. Jeśli narzędzie użyje niepoprawnej nazwy hosta (na przykład bez domeny DNS), niektóre podmioty główne usługi nie zostaną utworzone, a rzeczy takie jak SSH na hoście mogą zawieść.
      • netNarzędzie Samba
        • netNarzędzie jest częścią pakietu Samba.
        • To narzędzie wymaga skonfigurowania szczegółów domeny w smb.confpliku konfiguracyjnym, co sprawia, że ​​korzystanie z niego jest trudniejsze i bardziej niewygodne, zwłaszcza w sposób nieinteraktywny.
        • To narzędzie wymaga również uzyskania biletu Kerberos przed użyciem go za pomocą kinit. Ponownie jest to bardziej niewygodne i sprawia, że ​​nieco trudniej jest używać nieinteraktywnie w skrypcie, ponieważ istnieją dwa kroki zamiast jednego.
          

  • Uwagi dotyczące dysku SSHD:

    • Wprowadzenie SSHD do pracy z AD i SSSD jest zazwyczaj dość proste
    • Należy dodać następujące opcje /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Włącz uwierzytelnianie API GSS dla SSHD. Spowoduje to, że SSHD uwierzytelni się w AD KDC
      • PasswordAuthentication yes
        • Zezwalaj użytkownikom na logowanie się przy użyciu haseł. Wymagane, jeśli użytkownik chce uzyskać bilet KRB5 po zalogowaniu. Bez tej opcji system nie może odszyfrować biletu TGT przesłanego przez KDC.
      • ChallengeResponseAuthentication yes
        • W przypadku FreeBSD ta metoda wydaje się działać najlepiej.
          • Upewnij się, że skonfigurowałeś PasswordAuthentication nopodczas korzystania z tej opcji.
          • To jedyna metoda, jaką znalazłem dla FreeBSD, która działa, aby zmienić wygasłe hasło po zalogowaniu. Jeśli używasz drugiej, wywołuje /bin/passwd, która nie obsługuje nic poza NIS i lokalnym plikiem passwd.
      • GSSAPICleanupCredentials yes
        • (opcjonalnie) Wykona kdestroypo wylogowaniu
      • GSSAPIStrictAcceptorCheck no
        • (opcjonalnie) Ta opcja jest często wymagana, jeśli dysk SSHD jest mylony z własną nazwą hosta lub jest wieloadresowy itp. lub w inny sposób korzysta z innej nazwy głównej usługi do komunikacji z KDC. Zwykle SSHD użyje nazwy głównej usługi host/<FQDN>@REALMdo rozmowy z KDC, ale czasami robi się źle (na przykład, jeśli nazwa hosta nie zgadza się z nazwą DNS serwera SSH). Ta opcja pozwala SSHD na użycie dowolnej nazwy głównej w /etc/krb5.keytabpliku, która zawiera odpowiedniąhost/<FQDN>@REALM
    • W zależności od kombinacji użytych opcji może być konieczne dodanie zasad głównych hosta do KDC dla adresów IPv4 i IPv6 hosta, ssh -K <ip>aby działał bez pytania o hasło (zakładając, że już wykonałeś „kinit”, oczywiście).