abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:44 | Zajímavý projekt

Kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů, úspěšně skončila. Bylo vybráno více než 2,1 milionu dolarů, tj. cíl kampaně byl splněn na více než 141 %. Objednáno bylo cca 3 000 telefonů. Telefon Librem 5 by měl být k dispozici v lednu 2019.

Ladislav Hagara | Komentářů: 1
včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 1
včera 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
včera 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
22.10. 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 7
22.10. 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (0%)
 (1%)
 (75%)
 (12%)
Celkem 236 hlasů
 Komentářů: 8, poslední 22.10. 23:02
    Rozcestník

    Kerberos a SSO: služby - SSH

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

    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

    link

    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

    link

    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í

    link
    # 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

    link # 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

    link

    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

    link

    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

    link

    Nezbytná systémová nastavení

    link

    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

    link

    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í

    link

    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

    link

    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

    link

    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

    link

    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.

    Nejčtenější články posledního měsíce

    HW novinky: návrat skleněných ploten v HDD
    Zpověď VSHostingu: Jak vypadalo zákulisí českého hostingu a internetu před 11 lety
    HW novinky: PCI Express 4.0 prý ještě letos

    Nejkomentovanější články posledního měsíce

    HW novinky: návrat skleněných ploten v HDD
    Jaderné noviny - 17. 8. 2017: Škálovaní souboru MAINTAINERS v jádře
    Jaderné noviny – 21. 9. 2017: Zbytek začleňovacího okna 4.14
      všechny statistiky »

    Seriál Centrální správa účtů a Single Sign-On (dílů: 8)

    Centrální správa účtů a Single Sign-On v Linuxu (první díl)
    <—« Kerberos a SSO: Jednotné účty v LDAP
    »—> Kerberos a SSO: sdílení souborů - NFS4
    Kerberos a LDAP (poslední díl)

    Související články

    Integrace linuxového serveru do domény Windows 2003
    NFS+NIS+LTSP - přihlašování na server
    OpenSSH - bezpečně a pohodlně
    OpenSSH - více než jen Secure Shell
    SSL - je vaše bezpečné připojení opravdu zabezpečené?
    SSL - 1 (certifikáty)
    SSL - 2 (elektronický podpis)
    IPTraf - sledování sítě v reálném čase
    Podepisování a šifrování s GnuPG
    Samba - Linux jako server v sítích s Windows
    PEAR - III (Autentizace)
    Čo keď nechodí sieť?
    Mailserver s odvirováním pošty

    Odkazy a zdroje

    OpenSSH & Kerberos
    Jednotná autentizace prostrednictvím služeb LDAP a Kerberos v prostředí UNIX
    SSH: The Secure Shell The Definitive Guide

    Další články z této rubriky

    V sobotu se uskuteční konference CryptoFest
    Pozor na androidové aplikace
    Silent Circle představil bezpečný smartphone Blackphone 2
    Android je bezpečnější, řada hrozeb však stále přetrvává
    Avast varuje před nebezpečnými aplikacemi v Google Play
           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    29.5.2008 10:32 Ondar | skóre: 25 | blog: Linux_blog
    Rozbalit Rozbalit vše GSSAPI / SASL
    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.
    29.5.2008 16:46 Matlass
    Rozbalit Rozbalit vše Re: GSSAPI / SASL
    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.
    29.5.2008 17:41 Ondar | skóre: 25 | blog: Linux_blog
    Rozbalit Rozbalit vše Re: GSSAPI / SASL
    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).
    29.5.2008 16:27 bonci
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    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:
    29.5.2008 17:06 Matlas
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    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.
    29.5.2008 17:26 bonci
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    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.
    1.6.2008 01:35 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    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ů?
    1.6.2008 02:31 Mudrc | skóre: 24 | Plzeň
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    Ano :-)
    1.6.2008 08:09 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Kerberos a SSO: služby - SSH
    Výborně. :-)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.