Če je tvoj strežnik Linux prek SSSD član domene Active Directory (AD), se lahko uporabniki prijavijo ne le z geslom, temveč tudi s ključem SSH, pri čemer je njihov javni ključ v imeniku AD. Tako ključev ni treba kopirati v datoteke authorized_keys na vsakem strežniku: nov ključ ali preklic ključa sodelavca, ki odide, se zgodi na enem mestu, v AD, in velja za vse povezane strežnike.

Bistvo rešitve: ključ hraniš v atributu altSecurityIdentities uporabnika, SSSD nastaviš, da ta atribut zahteva, OpenSSH pa javne ključe uporabnika vpraša ukaz sss_ssh_authorizedkeys.

Predpogoji

• Strežnik se je že pridružil domeni (na primer z ukazom realm join) in uporabniki AD se lahko prijavijo z geslom. To preveriš z ukazom id felhasznalo@example.com.
• Uporabnik ima par ključev in njegov javni ključ (na primer ssh-ed25519 AAAA... bob@example.com) je pri roki. Ključ lahko ustvariš z ukazom ssh-keygen -t ed25519, glej: Ustvarjanje ključa SSH.
• V AD imaš pravico urejati atribute uporabnikov, na strežniku Linux pa pravice root.

1. Active Directory

V konzoli Active Directory Users and Computers v meniju View vklopi možnost Advanced Features, da se prikaže zavihek Attribute Editor.

Poišči uporabnika, odpri njegove lastnosti in klikni zavihek Attribute Editor. Poišči atribut altSecurityIdentities, ga odpri za urejanje in vanj kot eno samo vrstico prilepi javni ključ SSH uporabnika. Atribut lahko hrani več vrednosti, zato je mogoče enemu uporabniku dodati več ključev.

Isto iz PowerShella: Set-ADUser bob -Add @{altSecurityIdentities="ssh-ed25519 AAAA... bob@example.com"}.

Atribut altSecurityIdentities AD uporablja tudi za preslikavo potrdil in identifikatorjev Kerberos. Če taka preslikava pri uporabniku že obstaja, je ne prepiši, le dodaj novo vrednost.

2. SSSD

V razdelku [sssd] datoteke /etc/sssd/sssd.conf vrstici services dodaj vrednost ssh:

services = nss, pam, ssh

V razdelek domene dodaj, v katerem atributu so ključi:

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

Izprazni predpomnilnik SSSD in znova zaženi storitev:

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

3. OpenSSH

V datoteko /etc/ssh/sshd_config dodaj spodnje vrstice:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Po dokumentaciji sss_ssh_authorizedkeys naj ukaz zaganja neprivilegirani uporabnik nobody, ne root. Preveri nastavitev, nato znova zaženi strežnik SSH (v Debianu in Ubuntuju je ime storitve ssh):

sshd -t
systemctl restart sshd

Preverjanje in odpravljanje težav

Ukaz sss_ssh_authorizedkeys izpiše, katere javne ključe SSSD vidi za uporabnika:

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

Če ta pokaže ključ, prijava pa kljub temu ne uspe:

• sshd -T | grep -i authorizedkeyscommand pokaže dejansko veljavno nastavitev. Datoteke v imeniku /etc/ssh/sshd_config.d/ lahko preglasijo glavno konfiguracijo, ker OpenSSH uporabi prvo prebrano vrednost.
• Na strani odjemalca ssh -v bob@szerver podrobno izpiše, katere ključe je poskusil.
• V dnevniku strežnika (journalctl -u sshd oziroma journalctl -u sssd) je viden vzrok zavrnitve.

Če ukaz ne vrne ničesar, preveri, ali ima sssd.conf dovoljenja 600 in lastnika root (sicer se SSSD sploh ne zažene) ter ali je ključ v atributu natanko v eni vrstici, brez preloma vrstice. Pregled delovanja SSH in overjanja s ključem daje članek Linux Secure Shell (SSH).