Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
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.
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.
# 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
# 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
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
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
...
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
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
Nyní, když máme vše tak hezky nakonfigurované, vyzkoušíme, zda to skutečně funguje.
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
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
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.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
[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:
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.