Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
id_rsa.pub na onen pocitac do ~/.ssh/authorized_keys, ale porad to po me chce heslo. Nejdivnejsi je, ze na jinem pocitaci, kde bezi uplne stejna verze sshd s uplne stejnymi ssh_config a sshd_config to bezi bez problemu bez hesla. Nenapada nekoho kde bych mel hledat problem?
Verze ssh:
OpenSSH_4.3p2 Debian-8, OpenSSL 0.9.8c 05 Sep 2006
Tady je vypis, co ssh rika pri prihlasovani:
... debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 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 debug2: dh_gen_key: priv key bits set: 132/256 debug2: bits set: 532/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'zordon' is known and matches the RSA host key. debug1: Found key in /home/marek/.ssh/known_hosts:1 debug2: bits set: 508/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/marek/.ssh/identity ((nil)) debug2: key: /home/marek/.ssh/id_rsa (0x8095420) debug2: key: /home/marek/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/marek/.ssh/identity debug1: Offering public key: /home/marek/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/marek/.ssh/id_dsa debug2: we did not send a packet, disable method debug1: Next authentication method: password
sshd je zajimavy radek
debug2: key_type_from_name: unknown key type 'sh-rsa'Jakoby ssh nerozumel rsa? Porad me nenapada co s tim...
ssh-rsa je... a porad netusim kde mam hledat problem kdyz na jinych pocitacich to za stejnych podminek (vcetne stejne verze sshd) a pri stejnem konfiguraku funguje....
... debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/marek/.ssh/authorized_keys debug2: key_type_from_name: unknown key type 'sh-rsa' debug2: user_key_allowed: check options: 'sh-rsa AAAAB3N...atakdale.../Q== marek@pontius ' debug2: key_type_from_name: unknown key type 'AAAAB3N...atakdale.../Q==' debug2: user_key_allowed: advance: 'AAAAB3N...atakdale.../Q== marek@pontius ' debug1: restore_uid: 0/0 debug2: key not found debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/marek/.ssh/authorized_keys2 ...Mne opravdu prijde, ze ten sshd snad nezna rsa sifrovani ci co
Co treba nejaka kryptovaci knihovna? Neni mozne, ze mi tam neco chybi?
Minule jsem si toho nevsiml, ze jde prave o ten rozdil mezi ssh-rsa a sh-rsa.
Tiskni
Sdílej: