Ha Linux szervere SSSD-n keresztül tagja egy Active Directory (AD) tartománynak, a felhasználók nemcsak jelszóval, hanem SSH kulccsal is beléphetnek úgy, hogy a nyilvános kulcsuk az AD címtárban van. Így a kulcsokat nem kell szerverenként az authorized_keys fájlokba másolni: egy új kulcs vagy egy kilépő munkatárs kulcsának visszavonása egy helyen, az AD-ban történik, és minden csatlakoztatott szerverre érvényes.

A megoldás lényege: a kulcsot a felhasználó altSecurityIdentities attribútumában tárolja, az SSSD-t beállítja, hogy ezt az attribútumot kérje le, az OpenSSH pedig az sss_ssh_authorizedkeys parancstól kérdezi meg a felhasználó nyilvános kulcsait.

Előfeltételek

• A szerver már csatlakozott a tartományhoz (például realm join paranccsal), és az AD-felhasználók jelszóval be tudnak lépni. Ezt az id felhasznalo@example.com paranccsal ellenőrizheti.
• A felhasználónak van kulcspárja, és a nyilvános kulcsa (például ssh-ed25519 AAAA... bob@example.com) kéznél van. Kulcsot az ssh-keygen -t ed25519 paranccsal hozhat létre, lásd: SSH kulcs létrehozása.
• Az AD-ban jogosultsága van a felhasználói attribútumok szerkesztésére, a Linux szerveren pedig root jogosultsága.

1. Active Directory

Az Active Directory Users and Computers konzolban a View menüben kapcsolja be az Advanced Features opciót, hogy megjelenjen az Attribute Editor fül.

Keresse meg a felhasználót, nyissa meg a tulajdonságait, és kattintson az Attribute Editor fülre. Keresse meg az altSecurityIdentities attribútumot, nyissa meg szerkesztésre, és illessze be a felhasználó nyilvános SSH kulcsát egyetlen sorként. Az attribútum több értéket is tárolhat, így egy felhasználóhoz több kulcs is felvehető.

PowerShellből ugyanez: Set-ADUser bob -Add @{altSecurityIdentities="ssh-ed25519 AAAA... bob@example.com"}.

Az altSecurityIdentities attribútumot az AD tanúsítványok és Kerberos-azonosítók hozzárendelésére is használja. Ha ilyen hozzárendelés már létezik a felhasználónál, azt ne írja felül, csak adjon hozzá új értéket.

2. SSSD

Az /etc/sssd/sssd.conf fájl [sssd] szakaszában a services sorhoz adja hozzá az ssh értéket:

services = nss, pam, ssh

A tartomány szakaszába vegye fel, melyik attribútumban vannak a kulcsok:

[domain/example.com]
ldap_user_extra_attrs = altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities

Ürítse ki az SSSD gyorsítótárát, és indítsa újra a szolgáltatást:

systemctl stop sssd
rm -rf /var/lib/sss/db/* /var/lib/sss/mc/*
systemctl start sssd

3. OpenSSH

Adja hozzá az alábbi sorokat az /etc/ssh/sshd_config fájlhoz:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

A parancsot az sss_ssh_authorizedkeys dokumentációja szerint a jogosultság nélküli nobody felhasználó futtassa, nem a root. Ellenőrizze a beállítást, majd indítsa újra az SSH-kiszolgálót (Debianon és Ubuntun a szolgáltatás neve ssh):

sshd -t
systemctl restart sshd

Ellenőrzés és hibakeresés

Az sss_ssh_authorizedkeys parancs kiírja, milyen nyilvános kulcsokat lát az SSSD a felhasználóhoz:

# sss_ssh_authorizedkeys bob
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... bob@example.com

Ha ez a kulcsot mutatja, de a belépés mégsem sikerül:

• Az sshd -T | grep -i authorizedkeyscommand megmutatja a ténylegesen érvényes beállítást. Az /etc/ssh/sshd_config.d/ könyvtárban lévő fájlok felülírhatják a fő konfigurációt, mert az OpenSSH az elsőként olvasott értéket használja.
• A kliensoldalon az ssh -v bob@szerver részletesen kiírja, mely kulcsokat próbálta.
• A szerver naplójában (journalctl -u sshd, illetve journalctl -u sssd) látszik az elutasítás oka.

Ha a parancs nem ad vissza semmit, ellenőrizze, hogy az sssd.conf jogosultsága 600, a tulajdonosa root (különben az SSSD el sem indul), és hogy a kulcs pontosan egy sorban, sortörés nélkül került az attribútumba. Az SSH működéséről és a kulcsos azonosításról a Linux Secure Shell (SSH) cikk ad áttekintést.