Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.
Ultra Ethernet Consortium (UEC), jehož cílem je optimalizace a další vývoj Ethernetu s důrazem na rostoucí síťové požadavky AI a HPC, vydalo specifikaci Ultra Ethernet 1.0 (pdf, YouTube).
Francouzský prezident Emmanuel Macron chce zakázat přístup na sociální sítě pro děti do 15 let. Francie podle něj tento krok udělá sama do několika měsíců, i pokud se na něm neshodnou další státy Evropské unie. Reaguje tak na úterní vraždu vychovatelky, kterou ve východofrancouzském městě Nogent pobodal 14letý mladík. Jednotlivé sociální sítě podle něj mají možnost věk ověřit a vymáhat zákaz pomocí systémů na rozpoznávání tváří.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.
OpenSSH je od začátku vyvíjeno v rámci projektu OpenBSD a jeho zdrojové kódy jsou zveřejněny pod BSD licencí. Distribuce obsahuje SSH server, SSH klienta a přidružené programy.
Jako u většiny bezpečnostního softwaru, závisí bezpečnost především na způsobu používání. Je proto třeba pečlivě vyvažovat bezpečnost a pohodlí nebo najít způsob, jak skloubit obojí.
Dříve, než začnete pracovat na vzdáleném počítači nebo mu pošlete heslo, byste měli vědět, jestli se opravdu připojujete na správný server a ne na nějaký cizí stroj. K tomu slouží klíč SSH serveru (SSH host key).
Klient si udržuje seznam serverů a jejich veřejných klíčů. Pokud se spojíte s jiným serverem, klient to ohlásí a odmítne se připojit. Jediným slabým bodem je v tomto případě první přihlášení, kdy ještě server v seznamu není. V takovém případě OpenSSH zobrazí otisk (fingerprint) klíče uživateli, aby ho mohl zkontrolovat. Na serveru zjistíte otisky klíčů serveru příkazem ssh-keygen.
(server)$ ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key (server)$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Pokud spravujete server, který z nějakého důvodu nemá SSH klíč, musíte ho nechat vygenerovat (mně se vygenerovaly při prvním spuštění serveru). Můžete vygenerovat DSA klíč i RSA klíč.
(server)$ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N '' (server)$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
Nabízí se otázka, co dělat, když administrátor z nějakého důvodu klíč serveru změní. Stačí nechat vymazat záznam o serveru, znovu se přihlásit, zkontrolovat otisk a nechat klienta, ať si přidá nový veřejný klíč.
(klient)$ ssh-keygen -R example.net (klient)$ ssh uzivatel@example.net
Nejzákladnější metodou autentizace uživatele je zadání hesla (to se posílá až po ověření totožnosti serveru). Pokud máte pro každou službu nebo server vymyšlené bezpečné heslo, může se vám stát, že těch hesel bude příliš mnoho a nebudete si je všechny pamatovat. V horším případě začnete používat jedno heslo pro větší množství služeb, což může ohrozit bezpečné ověření vás jako uživatele.
Zajímavější alternativou je autentizace veřejným klíčem (public key authentication). V takovém případě stačí, aby server znal veřejný klíč uživatele. Veřejný klíč se vytváří příkazem ssh-keygen. Pro jednoduchost můžete vybrat DSA klíč. Pro bezpečnější práci je vhodné chránit (šifrovat) klíč nějakou bezpečnou passphrase (program se na ni zeptá).
(klient)$ ssh-keygen -t dsa
Kdybyste chtěli někdy změnit passphrase, opět pomůže příkaz ssh-keygen.
(klient)$ ssh-keygen -p -t dsa
Na každý server, kam se chcete touto metodou přihlašovat, zkopírujte svůj veřejný klíč. Přidejte ho do souboru .ssh/authorized_keys ve svém domácím adresáři na serveru. V sekci o SSH agentovi se dozvíte o elegantnějším způsobu přidávání veřejných klíču na server.
(server)$ cat id_dsa.pub >> ~/.ssh/authorized_keys
V tuhle chvíli se můžete přihlašovat bez zadávání hesla. Místo hesla ke vzdálenému počítači teď zadáváte passphrase vašeho klíče.
Na první pohled se toho moc nezměnilo, ale od této chvíle už neposíláte žádné heslo po síti. Pomocí passphrase se pouze rozšifruje klíč před použitím. To znamená, že můžete jeden klíč (s jednou passphrase) bezpečně používat pro přihlašování na mnoho serverů.
Bezpečnost autentizace veřejným klíčem spočívá v tom, že na straně serveru je uložený pouze veřejný klíč. Ten se dá použít pouze k ověření vaší totožnosti, pokud vy máte k dispozici svůj soukromý klíč (ověření serveru funguje podobně). To je velká výhoda oproti heslu, které musí být (v nějaké formě) uložené na serveru. Pokud chcete vědět více, přečtěte si něco o asymetrickém šifrování (viz odkazy a zdroje).
Používání klíčů usnadňuje i komunikaci s administrátorem, který vám zakládá účet pro vzdálený přístup. Nemusí vymýšlet žádné dočasné heslo, které byste si stejně změnili. Stačí, když mu dáte svůj veřejný klíč (nebo má možnost si ho najít).
Abyste nemuseli zadávat passphrase při každém použití SSH, je tu pro vás program ssh-agent. Nejdřív je potřeba zařídit, aby se agent spouštěl a ukončoval, když se přihlásíte nebo odhlásíte.
(klient)$ echo eval \`ssh-agent\` >> .bash_login (klient)$ echo eval \`ssh-agent -k\` >> .bash_logout
Po odhlášení a opětovném přihlášení by měl agent běžet. Můžete mu přidat svůj klíč pomocí ssh-add (bude po vás chtít zadat passphrase).
(klient)$ ssh-add
Rozšifrovaný klíč je teď uložený v paměti a připravený k použití. Do odhlášení nebudete muset passphrase zadávat. Navíc teď už můžete provést slibované elegantnější přidání veřejného klíče na server. Místo ssh spusťte ssh-copy-id. Příští přihlášení pomocí ssh už by mělo proběhnout bez zadávání hesla.
(klient)$ ssh-copy-id uzivatel@example.net (klient)$ ssh uzivatel@example.net
Pokud se vám nelíbí, že musíte po každém přihlášení ještě spouštět ssh-add a zadávat passphrase, potěším vás. Existuje modul pam_ssh pro PAM (Pluggable Authentication Modules, systém pro autentizaci uživatele), který umožňuje rozšířit přihlašování do systému o zavedení SSH agenta a přidání SSH klíče. K tomu, abyste tuto službu nastavili, samozřejmě potřebujete administrátorský účet.
Předpokládám, že balíček pam_ssh už jste si nainstalovali. V /etc/pam.d najdete konfigurační soubor služby (například xdm), u které chcete k přihlašování přidat podporu SSH agenta, a upravíte ho.
Nejdříve je potřeba přidat autentizaci pomocí pam_ssh a nastavit klasickou (pam_unix), aby v případě potřeby použila již zadané heslo (parametr try_first_pass). Pokud tento parametr vynecháte, bude se vás v případě neúspěchu systém ptát na vaše unixové heslo zvlášť.
auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_ssh.so auth sufficient /lib/security/pam_unix.so try_first_pass likeauth nullok auth required /lib/security/pam_deny.so
Pak se ještě hodí zavést pam_ssh session, která zajistí spuštění a ukončení SSH agenta. Pokud vám SSH agenta do teď spouštěl a ukončoval nějaký skript (například .bash_login a .bash_logout), nezapomeňte příslušné řádky zrušit.
session required /lib/security/pam_limits.so session sufficient /lib/security/pam_ssh.so session required /lib/security/pam_unix.so
Po dokončení této konfigurace se můžete začít přihlašovat do systému svou ssh passphrase. Po přihlášení máte automaticky spuštěného agenta a zavedený klíč. Pořád vám samozřejmě zůstává možnost přihlásit se starým heslem (bez načtení SSH klíče).
Příště se odpoutáme od bezpečnosti a podíváme se, co nám může SSH nabídnout kromě očekávaného bezpečného připojení ke vzdálenému shellu. Dotazy a připomínky jsou vítány.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
pokial by pouzival heslo, tak nemoze!Nahraď slovo "heslo" slovem "passphrase" a máš vyřešeno. Navíc můžeš bezpečně používat stejnou passphrase pro klíč, kterým se přihlašuješ k mnoha počítačům.
- ssh -w - .ssh/config - HashKnownHosts - .ssh/config - LocalCommand, SendEnv - /etc/ssh/sshd_config - ForceCommand, Match # s tim se daji delat kouzla ;)ad
.bash_login
& ssh-agent
, no... neni to kvapek mateni ctenare? uz vidim jak si kazdy pepa dela .bash_login
, kdyz treba ma .profile
:) jednodussi by bylo napsat do konfiguracnich souboru vaseho shellu - man bash/ksh
...
celkove ta sekce s ssh-agent
em je takove rychlokvasena. ocekaval bych vice o spojeni s X11 nebo pry i gnome ma neco na gtk.
ssh -w
Díky za tip, desktop jedu na Ubuntu 6.06 LTS a to tohle ještě nemá :-o.
Pro běžné použití snad jen jako osobní VPN na vlastní server, je zapotřebí mít roota na obou stranách (konfigurace rozhraní tun) a defaultně je to na serveru zakázáno (což je dobře). Na rychlé/nouzové/dočasné zprovoznění tunelu ovšem ideální (možnost zprovoznění i přes http proxy via ProxyCommand, viz ssh_config). Pro trvalejší účely je IMHO lepší OpenVPN.
Ale i docela možný scénář pro Road Warriors:
- pam-ssh s nahráním klíče do ssh-agenta - na serveru klíč klienta u roota v authorized_keys s restrikcemi: tunnel="1",command="/usr/local/sbin/tuncfg.sh tun1; read",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty * /usr/local/sbin/tuncfg.sh se stará o konfiguraci tun1 - server poslouchá na portu 443 - na klientu mít nějaký skript vpnviassh.sh co provede: * zaklepání, pokud se používá * nahození tunelu via ssh (ssh -C -f -w 0:1 -p 443 root@server) * konfigurace rozhraní tun0 přes "sudo /usr/local/sbin/tuncfg.sh tun0" - do /etc/sudoers dát /usr/local/sbin/tuncfg.sh bez hesla, třeba takto * Cmnd_Alias TUNCONFIG = /usr/local/sbin/tuncfg.sh * %vpnusers ALL=NOPASSWD: TUNCONFIG
A Je tu poměrně jednoduchá VPN co projde i z restriktivních sítí s transparent proxy. Oproti stejnému postupu s OpenVPN je tu jen jedno heslo po přihlášení na klienta a na disku nikde neleží nešifrovaný klíč či heslo. Nevýhodou je asi maximální počet klientů dle počtu tun rozhraní na serveru (sdílení tunX point-to-point ? Či použití Level2 tunelu ?). Dále by bylo dobré vědět, jak se to chová v případě výpadku spojení (tcp timeout a pak to shodí tun0 ?) a jak je to s výkonností
* Add support for tunneling arbitrary network packets over a connection between an OpenSSH client and server via tun(4) virtual network interfaces. This allows the use of OpenSSH (4.3+) to create a true VPN between the client and server providing real network connectivity at layer 2 or 3. This feature is experimental and is currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and FreeBSD. Other operating systems with tun/tap interface capability may be added in future portable OpenSSH releases. Please refer to the README.tun file in the source distribution for further details and usage examples.tu tvoji strategii jsem nepochopil... jednodussi by bylo pouzit
Match
a AcceptEnv
, ForceCommand
a obalit to do skriptu, ktery se provede pri prihlaseni :)
do .ssh/config
si date SendEnv
a poslete nejaky string, ssh server to ochekuje a pripadne nastavi tunneling... dale LocalCommand
:)
na kazdy si chce instalovat openvpn. samozrejme, ze skutecna VPN postavena na IPSec je lepsi reseni, ale toto je takovy rychly tip a taky takovy truc na openvpn :)
Příště se odpoutáme od bezpečnosti a podíváme se, co nám může SSH nabídnout kromě očekávaného bezpečného připojení ke vzdálenému shellu. Dotazy a připomínky jsou vítány.Mne by třeba jako námět do nějakého dalšího dílu zajímalo, zda existuje nějaká náhrada za vestavěný
sftp_server
pro subprotokol sftp
, který v OpenSSH zamrzl na verzi protokolu sftp 3. Ta má tu "drobnou" nevýhodu, že neřeší kódování názvů souborů, což je v síťovém prostředí poněkud hloupé (pak z toho vzniká "já mám systém v UTF-8, tak se přizpůsobte"). Já naštěstí systém mám v UTF-8 a WinSCP je možné vnutit UTF-8 i pro sftp předverzí 4, takže jsem to vyřešil. Ale je to ostuda, že tentokrát je to program pro Windows, který je pružnější v nastavení a podporuje novější protokol.
Pokud má na serveru 'opravdové' účty třeba 30 lidí kvůli poště, tak se můžete vsadit, že 1/3 z nich má jako heslo jména svých dětí
Pro takové účely máme cracklib.
Pokud má na serveru 'opravdové' účty třeba 30 lidí kvůli poště, tak se můžete vsadit, že 1/3 z nich má jako heslo jména svých dětí...Ti, co si alespoň jednou prolítli
sshd_config(5)
a zařídili se podle něj takové uživatele vůbec neřeší. :-P
chroot
, ale jestli neco umi omezit uzivatele aby nemohl prochazet jine slozky nez tu svoji...
chroot
je nesystemove a slozite reseni. reseni existuje, nejaky Mandatory Access Control :P