Kerberos a SSO: služby - SSH

29. 5. 2008 | Jiří Mlíka | Bezpečnost | 9834×

V dnešním dílu si na příkladu SSH ukážeme, jak využít Kerberos pro autentizaci ke službám. Konečně přijde na řadu i slibované Single Sign-on. Nakonfigurujeme si stroj, který bude sloužit jako SSH server.

Obsah

• Úvod
• Konfigurace serveru
  • Nezbytná systémová nastavení
  • Konfigurace stroje jako klienta Kerbera a LDAPu
  • Principal stroje a keytab
  • Konfigurace SSH démona
• Konfigurace klienta
  • Nezbytná systémová nastavení
  • Konfigurace SSH klienta
• Použití a testování
  • Krok 1: Přihlášení ke klientskému stroji pc1.firma.local
  • Krok 2: přihlášení k serveru srv-hpc1 pomocí SSH s podporou SSO
• Závěr

Úvod

Můžeme si třeba představit, že se jedná o vyhrazený výpočetní systém, který zpracovává dávkové úlohy spouštěné z příkazové řádky. Nakonfigurujeme nový stroj (server), který se bude jmenovat třeba srv-hpc1.firma.local. Jako klienta budeme používat stroj pc1.firma.local, který jsme nakonfigurovali v předchozích dílech.

Konfigurace serveru

V naší síti nainstalujeme nový linuxový stroj srv-hpc1.firma local (v mé testovací síti 172.16.51.11). Nakonfigurujeme na něm sdílení uživatelských účtů a autentizaci podle 2. a 3. dílu seriálu - stejně, jako jsme to udělali u stroje pc1.firma.local. Postup je tedy známý. Nainstalujeme samozřejmě také démona SSH. Pro úplnost pouze uvedu důležité konfigurační soubory.

Nezbytná systémová nastavení

# Soubor /etc/hosts na stroji srv-hpc1.firma.local

127.0.0.1       localhost.localdomain   localhost
172.16.51.10    srv-infra1.firma.local  srv-infra1

Konfigurace stroje jako klienta Kerbera a LDAPu

# Soubor /etc/krb5.conf na stroji srv-hpc1.firma.local

[realms]
FIRMA.LOCAL = {
kdc = srv-infra1.firma.local:88
admin_server = srv-infra1.firma.local:749
default_domain = firma.local
}

[domain_realm]
.firma.local = FIRMA.LOCAL
firma.local = FIRMA.LOCAL

[libdefaults]
default_realm = FIRMA.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
forwardable = yes

[logging]
default = FILE:/var/log/kerberos/krb5libs.log # Soubor /etc/nsswitch.conf na stroji srv-hpc1.firma.local

passwd: files ldap
shadow: files
group: files ldap
... # Soubor /etc/ldap.conf na stroji srv-hpc1.firma.local

host srv-infra1.firma.local
base dc=firma,dc=local # Soubor /etc/pam.d/system-auth na stroji srv-hpc1.firma.local

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so

account sufficient pam_unix.so
account required pam_deny.so

password sufficient pam_unix.so nullok use_authtok md5 shadow
password sufficient pam_krb5.so
password required pam_deny.so

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional pam_keyinit.so revoke
session required pam_limits.so
session required pam_unix.so

Principal stroje a keytab

Vytvoříme principal stroje srv-hpc1.firma.local pomocí nástroje kadmin. Principal bude mít náhodné heslo (parametr -randkey příkazu addprinc). Můžeme to provést z libovolného stroje, kde nám funguje nástroj kadmin (např. srv-infra1.firma.local, pc1.firma.local nebo srv-hpc1.firma.local).

kadmin: addprinc -randkey host/srv-hpc1.firma.local@FIRMA.LOCAL
WARNING: no policy specified for host/srv-hpc1.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "host/srv-hpc1.firma.local@FIRMA.LOCAL" created.

Na stroji srv-hpc1.firma.local vyexportujeme soukromý klíč principalu host/srv-hpc1.firma.local@FIRMA.LOCAL pomocí nástroje kadmin do "keytabu" /etc/krb5.keytab. Keytab je soubor, kam exportujeme soukromé klíče principalů strojů nebo služeb pro účely autentizace bez zásahu člověka, tj. bez zadání hesla, což je užitečné u automaticky běžících služeb nebo skriptů.

kadmin: ktadd host/srv-hpc1.firma.local@FIRMA.LOCAL
Entry for principal host/srv-hpc1.firma.local@FIRMA.LOCAL with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab
WRFILE:/etc/krb5.keytab.
Entry for principal host/srv-hpc1.firma.local@FIRMA.LOCAL with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab
WRFILE:/etc/krb5.keytab.

Je důležité, aby byl keytab byl čitelný pro uživatele, pod kterým služba nebo skript běží. Zároveň je však z bezpečnostního hlediska nezbytné, aby je nemohl číst nikdo jiný. Služba SSH v našem případě běží pod uživatelem root, neměli bychom tedy narazit na problém.

[root@srv-hpc1 ~]# ls -l /etc/krb5.keytab
-rw------- 1 root root 154 květen 10 12:01 /etc/krb5.keytab

Obsah keytabu pro jistotu ověříme.

[root@srv-hpc1 ~]# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -------------------------------------------------
   6 host/srv-hpc1.firma.local@FIRMA.LOCAL
   6 host/srv-hpc1.firma.local@FIRMA.LOCAL

Konfigurace SSH démona

Podpora Kerbera je v SSH démonu implementována přes GSSAPI, což je speciální programové rozhraní, které umožňuje integrovat aplikaci s libovolnou autenzitační službou, která toto API podporuje. Nastavíme-li proměnnou GSSAPIAuthentication na yes, máme zajištěno, že SSH démon použije Kerberos jako autentizační metodu.

# Soubor /etc/ssh/sshd_conf na stroji srv-hpc1.firma.local
...
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
...


Konfigurace klienta

Nezbytná systémová nastavení

Jako klienta použijeme opět stroj pc1.firma.local, který jsme si připravili v předchozích dílech seriálu. Vzhledem k tomu, že nepoužíváme DNS (a už to začíná být na škodu věci), musíme upravit soubor /etc/hosts, abychom mohli na klientu přeložit na IP adresu jméno serveru srv-hpc1.firma.local, kam se budeme pomocí SSO přihlašovat.

# Soubor /etc/hosts na stroji pc1.firma.local

127.0.0.1       localhost localhost.localdomain
172.16.51.10    srv-infra1.firma.local srv-infra1
172.16.51.11   srv-hpc1.firma.local srv-hpc1
172.16.51.130   pc1.firma.local pc1

Konfigurace SSH klienta

Konfiguraci klienta provedeme v souboru /etc/ssh/ssh_config. Aby klient použil Kerberos autentizaci, zapneme volbu GSSAPIAuthentication.

# Soubor /etc/ssh/ssh_config na stroji pc1.firma.local

Host *
    ForwardX11 yes
    ForwardX11Trusted yes
    Protocol 2,1
    StrictHostKeyChecking no
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes

Pokud bychom chtěli ze stroje srv-hpc1.firma.local přistupovat k dalším službám v síti při využití SSO, je třeba delegovat TGT získaný při přihlášení k pc1.firma.local na stroj-hpc1.firma local. To zajistí volba GSSAPIDelegateCredentials. Má to však ještě jednu nutnou podmínku, TGT musí být tzv. "forwardovatelný". Abychom automaticky získali "forwardovatelný TGT již při přihlášení k pc1.firma.local, musíme mírně upravit soubor /etc/krb5.conf na klientském stroji pc1.firma.local (resp. všude, kde to más smysl). Nastavíme možnost forwardable na yes v sekci [libdefaults]. V druhém díle seriálu jsme toto nastavení opomněli, proto jej nyní uvádím zde.

# Soubor /etc/krb5.conf na stroji pc1.firma.local

[realms]
 FIRMA.LOCAL = {
  kdc = srv-infra1.firma.local:88
  admin_server = srv-infra1.firma.local:749
  default_domain = firma.local
 }

[domain_realm]
 .firma.local = FIRMA.LOCAL
  firma.local = FIRMA.LOCAL

[libdefaults]
 default_realm = FIRMA.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 forwardable = yes

[logging]
 default = FILE:/var/log/kerberos/krb5libs.log

Použití a testování

Nyní, když máme vše tak hezky nakonfigurované, vyzkoušíme, zda to skutečně funguje.

Krok 1: Přihlášení ke klientskému stroji pc1.firma.local

Přihlásíme se ke klientskému stroji pc1.firma.local jako uživatel josef_vosahlo (tohoto uživatele jsme si vytvořili v minulém díle seriálu) a ověříme, zda jsme získali TGT a zda je tento TGT forwardovatelný. Učiníme tak pomocí příkazu klist volbou -f. Má-li TGT nastaven příznak F je "forwardovatelný".

[josef_vosahlo@pc1 ~]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_10002_w80pc4
Default principal: josef_vosahlo@FIRMA.LOCAL

Valid starting     Expires            Service principal
05/10/08 14:55:53  05/11/08 00:55:53  krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
        renew until 05/11/08 14:55:53, Flags: FRI

Krok 2: přihlášení k serveru srv-hpc1 pomocí SSH s podporou SSO

Nyní se můžeme pomocí SSH přihlásit s identitou josef_vosahlo ze stroje pc1.firma.local na stroj srv-hpc1.firma.local. U příkazu ssh použijeme volbu -v, získáme tak "ukecanější" výstup pro případ, že by něco nefungovalo.

[josef_vosahlo@pc1 ~]$ ssh -v srv-hpc1
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to srv-hpc1 [172.16.51.11] port 22.
debug1: Connection established.
debug1: identity file /home/josef_vosahlo/.ssh/identity type -1
debug1: identity file /home/josef_vosahlo/.ssh/id_rsa type -1
debug1: identity file /home/josef_vosahlo/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6
debug1: match: OpenSSH_4.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 'srv-hpc1' is known and matches the RSA host key.
debug1: Found key in /home/josef_vosahlo/.ssh/known_hosts:1
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: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Sat May 10 14:27:14 2008 from 172.16.51.130
[josef_vosahlo@srv-hpc1 ~]$

Všimněte si, že z možných autentizačních metod (publickey, gssapi-with-mic, password) byla použita právě metoda gssapi-with-mic. Autentizace proběhla úspěšně a objevila se příkazová řádka stroje srv-hpc1.firma.local, aniž bychom byli vyzváni k zadání hesla. SSO funguje. Potěšeni tímto povzbuzujícím výsledkem zkontrolujeme ještě forwardování TGT. Příznak F ukazuje, že na stroji srv-hpc1.firma.local máme forwardovatelný TGT. Tento TGT byl získán forwardováním, což ukazuje příznak f.

[josef_vosahlo@srv-hpc1 ~]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_10002_dFhAhF4040
Default principal: josef_vosahlo@FIRMA.LOCAL

Valid starting     Expires            Service principal
05/10/08 15:01:32  05/11/08 00:55:53  krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
        renew until 05/11/08 14:55:53, Flags: FfRT

Závěr

V dnešním dílu jsme si na příkladu SSH ukázali, jak použít Kerbera spolu se službami. U ostatních kerberizovatelných služeb je konfigurace v principu obdobná. Některé služby používají místo systémového keytabu /etc/krb5.keytab svůj vlastní vyhrazený keytab a také vyžadují vytvoření speciálního principalu pro danou službu. Služby také nemusí vždy realizovat podporu Kerbera pomocí GSSAPI, ale mohou tak činit jiným způsobem, např. pomocí SASL.

V dalším díle seriálu nakonfigurujeme souborový server NFS4 s podporou Kerbera, což nám umožní nahlédnout do problematiky zase o kousek hlouběji.

       

Komentáře

[Ondar]

Mno nevim, vždycky jsem si myslel, že GSSAPI je podmnožinou SASL. Respektive, pokud mluvíme o SASL s Kerberosem, tak je to GSSAPI. Více zde.

[Matlass]

Nikoli. "GSS-API" a SASL mechanism" není rovnítko. GSS-API je standardizované programátorské rozhraní, které zapouzdřuje bezpečnostní mechanismy (jako např zde používaný krb5 protokol - krb5 mechanism byl standardizován v RFC 1964, které je nahrazeno vámi odkazovaným RFC 4752). Je to sada funkcí, které poskytují přístup k bezpečnostním výkonným mechanismům. Programátor se nemusí starat o to, jak se tvoří kontext pro kerberos5, nebo pro jiný mechanismus. Pouze zavolá funkci stvorit_bezpecnostni_kontext(krb5) a api se postará o zbytek.

GSS-API je popsáno vRFC 2743 RFC 4752, který odkazujete je pouze mechanismem (tedy jakýmsi modulem).

Jiné mechanismy jsou např pro použití X.509 certifikátů...atd.

[Ondar]

Aha, takže pokud (jako programátor) chci použit zabezpečené připojení pomocí SASL/Kerberos, tak použiji rozhraní GSSAPI (pokud tomu dobře rozumím).

[bonci]

Dobry den,

Postupoval som podla clanku, ale prihlasenie konci s chybou (Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database) a pokracuje standardnym loginom. Ako keby nevedel najst principal, db. Neviete kde by mohol byt problem? Musim spomenut, ze to skusam na jednom test PC, ktore sluzi ako server a klient naraz. Prijam aj vystup zo ssh. D.

[root@XXX ~]# ssh -l frantisek_hnipirdo XXX
frantisek_hnipirdo@XXX's password: 
Creating directory '/home/frantisek_hnipirdo'.
Last login: Thu May 29 16:10:57 2008 from XXX.XX.XX
/usr/bin/xauth:  creating new authority file /home/frantisek_hnipirdo/.Xauthority
[frantisek_hnipirdo@XXX ~]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_10001_VDrwmE
Default principal: frantisek_hnipirdo@XX.XX

Valid starting     Expires            Service principal
05/29/08 16:24:50  05/30/08 02:24:50  krbtgt/XX.XX@XX.XX
        renew until 05/30/08 02:24:50, Flags: FRI


Kerberos 4 ticket cache: /tmp/tkt10001
klist: You have no tickets cached
[frantisek_hnipirdo@XXX ~]$ ssh -v XXX
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to labcentos [10.1.1.10] port 22.
debug1: Connection established.
debug1: identity file /home/frantisek_hnipirdo/.ssh/identity type -1
debug1: identity file /home/frantisek_hnipirdo/.ssh/id_rsa type -1
debug1: identity file /home/frantisek_hnipirdo/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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
Warning: Permanently added 'XXX,10.1.1.10' (RSA) to the list of known hosts.
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: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Next authentication method: publickey
debug1: Trying private key: /home/frantisek_hnipirdo/.ssh/identity
debug1: Trying private key: /home/frantisek_hnipirdo/.ssh/id_rsa
debug1: Trying private key: /home/frantisek_hnipirdo/.ssh/id_dsa
debug1: Next authentication method: password
frantisek_hnipirdo@XXX's password:

[Matlas]

Problém je, že se snažíte připojit k serveru se jménem pro které neexistuje pricipal v KDC databázi. říká to tato hláška: debug1: Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database máte pro server založený pricipal? Máte na serveru keytab?

Připojujete se k serveru se jménem stejným jako zní principal?

příklad:

matlas@stanice $ ssh mujserver.domena.cz

v tomto případě je principal serveru host/mujserver.domena.cz@NEJAKY.REALM

pokud se chcete připojit k serveru pouze ssh mujserver musíte mít zajištěno, že mujserver se převede na FQDN. jinak se snažíte získat service ticket pro principal host/mujserver@NEJAKY.REALM a to je špatně.

Podívejte se do logu KDC. tam uvidíte jaký principal se snažíte kontaktovat.

[bonci]

Dik za tip, uplne som zabudol na KDC log. Problem bol v tom, ze v /etc/hosts mam server velkym + malym pismenom tak pri prevode na principal ho konvertoval na male pismena.

Po pridani principalu len s lowercase to uz ide.

Este raz vdaka.

[Honza Jaroš]

Už jsem se chtěl zeptat u minulého dílu, ale nakonec jsem se k tomu nedostal, takže se poptám tady: jde nějak nastavit systém tak, aby bylo možné se pomocí sdílených účtů přihlašovat i v offline režimu (třeba na notebooku když zrovna není na síti)? A pokud ano, plánuje se zmínka na toto téma v některém z příštích dílů?

[Mudrc]

Ano

[Honza Jaroš]

Výborně.