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.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
ale pokud jde o automaty, tak ti jdou vetsinou primo po te 22..
to byl priklad, dam si tam treba 512487
Obávám se, že to se démonovi líbit nebude. Ale mělo by to výhodu, že na takový port by se vám zaručeně nikdo bourat nezkoušel.
ale pokud jde o automaty, tak ti jdou vetsinou primo po te 22
Pokud máte takové heslo, že reálně hrozí jeho uhodnutí takovým automatem, o jakých mluvíte, pak toto je váš problém a toto je třeba řešit. Ne schování sshd na nedefaultní port.
Proc neskusis nastavit #MaxAuthTries 6 napr...
To snad vi ne:). Sem to kopcil z configuraku a uprimne receno nechtelo se mi to nejak upravovat :P. Taky by se nejdriv mohl mrknout do configu nez tady neco resi co tam je popsano:)
PermitEmptyPasswords no AllowUsers user1 user2to su celkom uzitocne veci
ale tim preci nevyresim to, aby se me tam snazily prihlasivat nejaky ty automaty, ktery testujou port 22 a jemu podobne
A co na tom vlastně chcete řešit? Pokud se nebojíte toho, že uspějí, nevidím v tom žádný problém.
Muzu zakazat prihlaseni na roota a pouzivat treba su pod jinym uzivatelem
Další podobné populární a efektní opatření, které je z praktického hlediska k ničemu.
ale logy se mi stejne budou plnit tim, ze server tchaionku.com.tw se mi snazi prihlasit jako root
Pokud tohle vidíte jako hlavní problém, tak si ty hlášky odfiltrujte a budete mít klid. :-)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
17.1.2008 12:13
17.1.2008 12:09
17.1.2008 13:36
17.1.2008 14:40
sshd na jiný port, se to přeci nezmění.
sshd odsunout na jiný port. Pokud chci řešit zbytečné hlášky v logu, použiju filtrování logů. Ale používat na filtrování hlášek v logu odsunutí sshd na jiný port, to je docela zvláštní, ne? Pokud je někde něco špatně, bývá lepší opravit problém, ne zamaskovat jeho projevy.
Dvouprvkove prihlaseni ma jiste kouzlo.
V implementacích, o kterých se tu bavíme, jde ale jen o to kouzlo… :-)
Zaheslovani certifikatu tohle ale neresi
Proč ne?
b) protoze jde stale o jednoprvkove prihlaseni - u jednou distribuovaneho certifikatu uz neumim vynutit zmenu hesla.Distribuovaného? Vy privátní klíče někam distribuujete? Nejsem si jist, co přesně tím myslíte, ale hesla a privátní klíče se uchovávají v tajnosti, na tom je celý princip zabezpečení heslem nebo privátním klíčem založen.
ssh nepotřebujete, protože tam se uživatel neidentifikuje nijak, „identifikací“ je přímo veřejný klíč. Soukromý certifikát je tajemství uživatele, a má-li se jednat o skutečné zabezpečení, klientský certifikát nikdy nesmí nikdo mimo uživatele vidět – ani certifikační autorita.
Ne, ne. Klientsky certifikat je podepsany privatni klic. Ale treba serverovy certifikat je podepsany verejny klic toho serveru.Člověče, běžte si o tom rychle něco přečíst, třeba aspoň na Wikipedii: Digital certificate. Proč myslíte, že žádost o klientský certifikát má dvě části, jednu si necháte a druhou předáte certifikační autoritě? Aby soukromý klíč nikam neputoval a zůstal jenom u vás. Nebo proč se skoro všude u klientského certifikátu zobrazuje, zda k němu máte i privátní klíč? Pokud má být zabezpečení párem klíčů opravdu bezpečné, nesmíte dát privátní klíč z ruky, tak nemůže být na nějakém veřejném certifikátu. Pokud by byl certifikát tajný, pak zase nemá smysl, aby byl podepsán, sám sobě člověk většinou důvěřuje a nepotřebuje to mít potvrzené od certifikační autority. Když už to nechcete nikde číst, zapojte aspoň logiku…
Ohledne ssh - prave proto jsem zavedl rec na klientske certifikaty, ze stavajici praxe neni uplne optimalni - chybi tam moznost klientskych certifikatu.To by znamenalo oproti současné praxi znamenalo, že bych na serveru neregistroval veřejný klíč, ale řekl bych, že přijímám libovolný veřejný klíč, který se shoduje v nějakých údajích (třeba jméno a příjmení) a byl podepsán nějakou důvěryhodnou certifikační autoritou. Zatím to mylsím není potřeba (lidé nemění veřejné klíče moc často), a hlavně chybí nějaký (celosvětově) jendoznačný údaj. Protože já nechci povolit přístup každému Frantovi Novákovi, ale jenom tomu jedinému. Tady v ČR bych to mohl určit třeba kombinací jméno, příjmení, rodné číslo, bydliště – ale to není celosvětově univerzální.
Zkusím vám to vysvětlit ještě jinak. Základním principem autentizace s veřejným klíčem je implementace tzv. zero knowledge proof. Tedy toho, že mohu (dostatečně) spolehlivě prokázat znalost určité tajné informace (zde tajný klíč) i tomu, kdo ji sám nezná. Funguje to tak, že veřejný klíč stačí k ověření toho, zda byla určitá data podepsána odpovídajícím tajným klíčem, ale z veřejného klíče se nedá odvodit tajný. Proto kdokoli, kdo má můj veřejný klíč, může ověřovat, zda jsem data podepsal opravdu já, ale nemůže sám podepisovat, a tedy se za mne vydávat.
Autorita slouží pouze k tomu, aby se zjednodušilo ověření, že daný veřejný klíč patří pouze mne. Pokud tedy druhá strana nemá možnost ode mne věrohodným způsobem získat veřejný klíč, nechám si vystavit certifikát. Ten vypadá tak, že se vezme můj veřejný klíč (možná jen fingerprinty, to si teď z hlavy nevzpomínám), nějaké identifikační údaje, a celé se to podepíše (tajným) klíčem autority. Výsledku se říká certifikát. Takže kdokoli, kdo má veřejný klíč (certifikát) autority, může ověřit, že autorita na svou zodpovědnost tvrdí, že daný veřejný klíč patří mně. A pokud té autoritě důvěřuje, bude věřit, že je ten veřejný klíč opravdu můj a bude moci ověřovat mnou podepsaná data.
Porad trvam na tom, ze KLIENTSKY certifikat obsahuje privatni klic.
Klidně si na tom trvejte, když vás ani oficiální dokumenty nezajímají, jen, prosím vás, taková tvrzení nešiřte dál.
Ne, to se nemýlím. Tajný klíč není třeba nikam distribuovat. Ten si vygeneruje uživatel sám a nemusí (přesněji: neměl by) ho nikomu poskystovat, natož ho někam distribuovat.
Mýlíte se vy, dokonce dvojmo: certifikát je veřejný klíč uživatele (plus nějaké identifikační údaje) podepsaný tajným klíčem autority (veřejným by to nemělo smysl, ten je komukoli k dispozici).
veřejný klíč – identifikační údaje. Šifruje se veřejným klíčem, rozšifrovat pak může jedině ten, kdo má odpovídající klíč soukromý. Podepisuje se soukromým klíčem, ověřit podpis pak může každý, kdo má odpovídající klíč veřejný. Asymetrická kryptografie funguje tak, že pokud na výchozí text „aplikujete“ po sobě veřejný a soukromý klíč z páru klíčů, a to v libovolném pořadí, dostanete zpět výchozí text.
A ta shoda názvů s elektronickým privátním klíčem není náhodná. Takže privátní klíče „distribuuju“ (předám) někomu jedině v případě, kdy předpokládám, že by bylo příliš chtít po něm, aby si privátní klíč vytvořil sám – pak dvojici klíčů vytvořím za něj a předám mu ji. Každopádně ale prozrazení privátního klíče je stejné jako prozrazení hesla – v obou případech je nutné na serveru toto „přihlašovací tajemství“ zneplatnit a nahradit jej jiným – v případě hesla jiným heslem, v případě klíče jiným klíčem.
Princip klientský certifikátů spočívá v tom, že uživatel má svůj tajný privátní klíč, a k němu do páru veřejný klíč. Pokud má získat přístup k nějakému serveru, správce toho serveru přiřadí tento veřejný klíč do seznamu klíčů, které opravňují daného uživatele se přihlásit. Principiálně tedy privátní klíč nikam neputuje.
ssh žádná certifikační autorita nepodepisuje, protože na serveru slouží pro „identifikaci“ přímo veřejný klíč.
Tak jsem to pro zajímavost udělal a hned první odkaz vede na stránku, kde se o PKCS #12 mimo jiné píše
Defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key. … This is a container format that can contain multiple embeded objects, eg. multiple certificates. …
Ani slovo o tom, že by se tomu kontejneru jako celku říkalo certifikát. A další zdroje jsou na tom podobně. Pokud chcete něco opravdu oficiálního, tak tady je specifikace.
ssh se pro přihlášení klienta žádné certifikáty nepoužívají, protože se používají přímo veřejný a soukromý klíč (žádný certifikát není potřeba, v úložišti máte přímo veřejné klíče, kterým důvěřujete).
Co se týče ostatního, nezáleží na tom, jestli se něčemu říká certifikát nebo ne, ale záleží na podstatě věci – soukromý klíč má mít v plné moci pouze majitel „podpisového certifikátu“ a nikdo jiný (ani CA) k němu nemá mít přístup. Soukromý klíč není součástí žádosti o „certifikát“ – žádost sestává z veřejného klíče a identifikačních údajů, to celé podepsáno odpovídajícím soukromým klíčem. CA z takové žádosti vyrobí podepsaný certifikát (podepsaný je soukromým klíčem CA). Formáty pro uložení „certifikátů“ zpravidla umožňují uložit do jednoho souboru vedle certifikátu veřejného klíče i soukromý klíč a/nebo celou certifikační cestu až ke kořenovému certifikátu.
Pokud tedy někdo někam posílá svůj soukromý klíč, je to pouze jeho nevědomost nebo hloupost. Žádný technický postup v oblasti asymetrické kryptografie nic takového nevyžaduje. Všechny tři české kvalifikované certifikační autority vydávají certifikáty na základě žádosti (neobsahující soukromý klíč) podané zákazníkem, tj. certifikační autorita nepřijde do styku s privátním klíčem. Je možné, že některé banky vydávají svoje certifikáty tak, že za klienta vygenerují i žádost a privátní klíč, certifikát mu pak podepíšou a dají mu podepsaný certifikát i s klíčem. To ale neznamená, že by takový postup byl potřeba – pouze to cosi vypovídá o tom, jak bere banka vážně zabezpečení.
Neodpovedel jste mi ani jeden na otazku, jak se dostane vas bankovni soukromy klic k vam na pocitac.Vznikne tam při generování páru soukromého a veřejného klíče. Z veřejného klíče a identifikačních údajů se následně vygeneruje žádost o certifikát, která se dopraví k podpisu certifikační autoritě. Soukromý klíč neopouští počítač žadatele (pokud jej tedy žadatel sám nevyexportuje, aby si klíč zazálohoval). Např. ve Windows probíhá generování žádosti tak, že se soukromý klíč uloží kamsi do uživatelského profilu a jako soubor dostanete jenom žádost. Tu pak předáte CA, tam vám vystaví podepsaný certifikát, který naimportujete zpátky do Windows, a teprve v tomto okamžiku vám Windows ten privátní klíč zpřístupní (jako soukromý klíč k certifikátu). V době mezi vygenerováním žádosti a importem podepsaného certifikátu (a případnou zálohou klíče) nesmíte Windows přeinstalovat, nesmí se vám uživatelský profil poškodit nebo ztratit, jinak přijdete o jedinou kopii soukromého klíče a tím pádem vám bude „certifikát“ k ničemu. Kdyby ten soukromý klíč byl kdekoliv jinde, než v počítači žadatele, nebyl by přece problém jej v takovém případě obnovit.
jeho důvěryhodnost je pak stejná, jako důvěryhodnost toho obchodníka co ten keystore vytvořil + důvěryhodnost distribučního kanálu
Přičemž znak "+" zde znamená minimum z argumentů. :-)
Nikdo nikomu nebrani (ba se to primo doporucuje, ze) si vygenerovat novy par ihned po importu klientskeho certifikatu.Cožeto? Importuju si klientský certifikát, pak ho zahodím a vygeneruji si novou žádost? To je jak v tom vtipu, jak Matfyzák vaří čaj…
Jasne, ze to ma smysl, protoze novy soukromy klic oni tam vubec nevideli a stary uz je revokovan.Nebo si ten nový soukromý klíč vytvořili oni a neviděl jste ho vy. Kdo to ve skutečnosti udělal se zjistit nedá, protože to bylo podepsáno vaším předchozím soukromým klíčem, který ve vašem modelu sdílíte s bankou. Takže to mohl udělat kdokoli, kdo k tomu klíči měl přístup. Podle práva za ten klíč ale zodpovídáte vy.
Jasne, ze banka nebo obchodnik muze defraudovat vase penize a vubec k tomu nepotrebuje vas klic, protoze proste a jednoduse kontroluje vas ucet, a tudiz jim proste musite verit, ze jejich kontrolni mechanizmy funguji.Jenomže je něco jiného, když někdo z banky např. přinutí bankovní systém odeslat někam peníze z mého účtu,a nebude k tomu možné dohledat žádný můj příkaz – to je pak jisté, že se muselo nějak manipulovat přímo s bankovním systémem. Pokud ale takový převod bude podepsaný mým soukromým klíčem, nebude to pro kontrolní mechanizmy žádný problém, a pokud si budu stěžovat, budu muset nejprve já složitě dokazovat, že já jsem takový příkaz rozhodně dát nemohl. To je jeden ze základních principů kontroly – že jde i zpětně dohledat, kdo co udělal. Pokud bude banka archivovat všechny příkazy k úhradě i s jejich podpisem, a dotyčný falšovatel nebude mít můj privátní klíč, bude muset podstrčit příkaz podepsaný jiným podpisem. Pokud to bude někdo, kdo má přístup k CA té banky, může si vyrobit klíč a certifikát na moje jméno, a podstrčit to – pak mám ale já pořád šanci dokázat, že já jsem měl ale vydaný jiný certifikát s těmi samými údaji, což ukazuje minimálně na to, že CA té banky udělala něco podivného – a nebudu v tom sám. Pokud ten klíč a certifikát bude od jiné CA, musel by mít pachatel v bance nějakého spolupachatele v té externí CA, který mu vydá ten zfalšovaný certifikát. Pokud však bude můj privátní klíč mít k dispozici banka, prostě to dotyčný podepíše tím klíčem a má po starostech.
Nastudujte si, jak pres internet funguji dnesni banky. Pro uvodni ziskani klientskeho certifikatu mnohdy staci pridelene jmeno a heslo.Že takhle nějaké banky fungují, to ještě neznamená, že je to tak správně. Banky taky dovolují autorizovat platbu přeříkáním nějakého 4místného pinu po telefonu, pošlou kód k autorizaci jako nešifrovanou SMS, nebo používají certifikát uložený na disketě (a jejich aplikace funguje jen ve Windows), takže si privátní klíč může přečíst každý vir. To ale ještě neznamená, že je to tak správně. A už vůbec bych z toho nevyvozoval, co je součástí certifikátu nebo kde je uložen privátní klíč.
ssh. Tam žádné certifikáty, ani revokované ani klientské, nejsou. Co by ten certifikát certifikoval?
ssh žádná taková identifikace není – tam máte jen veřejný klíč (u něj můžete mít v souboru autorizovaných klíčů poznámku, ale ta není podepsaná, takže to není žádný certifikát).
.ssh uživatele, který má povoleno přihlášení přes ssh s klíčem. Najdete tam soubor authorized_keys. Podívejte se dovnitř. Jsou tam certifikáty, nebo jen veřejné klíče (případně s komentářem)?
Klientsky certifikat apache podepisuje, protoze obsahuje soukromy klic.Ne, klientský certifikát nic nepodepisuje. Podepisuje soukromý klíč, který patří k certifikátu, a ten certifikát vás identifikuje (a zároveň je podepsaný – certifikovaný – aby bylo potvrzené, že někdo ověřil, že jste ten, za koho se v certifikátu vydáváte). Při přihlášení k HTTPS serveru certifikátem se odešle elektronický podpis (podle kterého server pozná, že máte soukromý klíč) a vedle něj také certifikát (ze kterého si server ověří, že patří k tomu soukromému klíči, a ze kterého zjistí, kdo jste). Takže certifikát nemůže obsahovat soukromý klíč, protože byste svůj soukromý klíč při každém přihlášení poslal bůhvíkam.
A to je vlastnost, ktera mi chybi u ssh.Co konkrétně vám chybí u
ssh? U ssh se neověřuje identita uživatele podle nějakých dodatečných identifikačních údajů, tam je identita jednoduše dána veřejným klíčem. K ssh se nepřihlašuje „Petr Novák, Praha“ (jako je tomu u HTTPS – i když i tam se často používá identifikace např. sériovým číslem certifikátu), ale přihlašuje se tam majitel soukromého klíče odpovídajícího určenému veřejnému klíči. Protože přístup k ssh se většinou nedává potenciálně neomezenému množství lidí (k čemuž je dobré to všechno okolo certifikačních autorit, co je vystavené nad základním principem asymetrické kryptografie dvou klíčů), ale dáváte to jen omezené skupince lidí, takže není problém si obstarat přímo jejich veřejné klíče.
p. Michal Kubecek mi zaslani soukromeho klice v certifikatu postou primo doporucilA co Michal Kubeček doopravdy napsal:
Můžete mu ho přinejhorším poslat mailemObrázek už si snad každý udělá sám…
Jak říkám, nevím z hlavy, jestli Mozilla umožňuje použít klíč přímo ze souboru. Nejspíš by ale šlo udělat to, že přesunete soubor s jejím repozitářem klíčů a certifikátů na flashdisk a místo něj tam dáte symbolický link.
Ten soubor, kam si Mozilla ukládá klíče a certifikáty, je ale chráněný heslem.
Jsou v podstatě dvě možnosti. Jednak autorita vydává CRL (Certificate Revocation List), tj. jakýsi stoplist certifikátů, kterým ještě nevypršela platnost, ale nemají být akceptovány. Tan, kdo považuje autoritu za věrohodnou, by si měl tyto CRL pravidelně stahovat. Druhou možností je použít protokol OCSP (Online Certificate Status Protocol), který umožňuje se online dotázat na platnost certifikátu v okamžiku, kdy ho někdo použije.
Oboje ale samozřejmě předpokládá, že se ten, kdo váš podpis ověřuje, bude chovat zodpovědně, tedy že buď bude stahovat CRL nebo ověřovat pomocí OCSP. Nebude-li dělat ani jedno, máte problém. Tedy měl by ho mít spíš on, protože když akceptuje podpis revokovaným certifikátem, vy byste měl být schopen prokázat, že už byl v tu chvíli revokován, a takový podpis by neměl být pro vás závazný.
soubor klient.key je ten jeho soukromy klic, ktery by si mel chranit?
Přesně tak.
Tzn, ze napr. pri podepisovani dokumentu musim mit k dispozici oba sve klice (soukromy a verejny) a do podpisu se potom zahrne muj verejny klic?
Dokument podepíšete tajným klíčem a součástí toho podpisu je identifikace toho, o jaký klíč se jedná. V jednodušším případě má příjemce přímo váš veřejný klíč, takže může provést ověření rovnou pomocí něj. Pokud ho nemá, vy mu ho pošlete, ale on nemá jistotu, že je opravdu váš (že ho cestou nějaký záškodník nevyměnil). Pokud nemá možnost váš veřejný klíč získat nějakým důvěryhodným kanálem, můžete použít ten certifikát, který si může ověřit pomocí veřejného klíče autority, která ten certifikát vydala. Autorita pak ručí za to, že klíč je opravdu váš.
Ad 1: to by bylo hezké, ale použitím defaultního portu nic takového neuděláte.
Ad 2: nedávno tu na toto téma byla dlouhá a bouřlivá diskuse, kde jsem důvody popsal velmi podrobně.
Ad 3: Poud je jediný problém v tom, že vám vadí ty hlášky v logu - a to by měl být - pak mi jejich odfiltrování připadá jako velmi jednoduché a praktické řešení.
IMHO dávat sshd na jiný port a zakazovat přímé přihlášení roota v zájmu zvýšení bezpečnosti je dobré tak akorát pro lepší pocit.
Vlákno bylo přesunuto do samostatné diskuse.
Tiskni
Sdílej:
