Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Dobrý den, potřeboval bych se připojovat z mého PC na vzdálený server. K tomu účelu jsem od správce už dostal vygenerovaný soukromý klíč, kterým jsem se až do nedávna z win úspěšně připojoval přes putty. Ale z nějakého důvodu mi nefunguje při přihlášení přes ssh. Respektive k serveru se připojím, co se mi podařilo vyčíst z parametru -v tak to i odešle klíče, ale hned na to se mě zeptá na heslo, bez kterého mě dál nepustí:
pavel@pavel-PC:~/.ssh$ ssh -p yyyyy -l "name" -v "server.cz" OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to server.cz [xxxxxxxxx] port yyyyy. debug1: Connection established. debug1: identity file /home/pavel/.ssh/identity type -1 debug1: identity file /home/pavel/.ssh/id_rsa type -1 debug1: identity file /home/pavel/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '[server.cz]:yyyyy' is known and matches the RSA host key. debug1: Found key in /home/pavel/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/pavel/.ssh/id_dsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/pavel/.ssh/identity debug1: Trying private key: /home/pavel/.ssh/id_rsa debug1: Next authentication method: password name@server.cz's password:
Abych ještě upřesnil jak jsem se k tomu dostal:
Upřímně se v tom debug výpisu moc nevyznám, ale docela mě zaráží řádek:
debug1: Offering public key: /home/pavel/.ssh/id_dsa
podle toho co vím by to měl být spíš id_dsa.pub...
Jestli někdo víte co s tím, tak budu vděčný za jakékoliv konstruktivní rady, už se s tím babrám docela dlouho a několik posledních dnů jsem zaseknutý v tomhle bodě...
Řešení dotazu:
1.10.2009 23:22
Jendа | skóre: 78
| blog: Jenda
| JO70FB
1. ssh-keygen -t dsa 2. id_dsa jsem nahradil svým klíčem 3. cat id_dsa.pub >> authorized_keys 4. chmod 700 . chmod 600 authorized_ keys chmod 600 id_dsa chmod 644 id_dsa.pubMáš to nějak blbě...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
id_dsa je tvůj privátní klíč. Ten musíš mít u sebe.
id_dsa.pub je tvůj veřejný klíč. Ten musíš nakopírovat do uthorized_keys vzdáleného stroje.
Tj. 3. je nějaká divná (mělo by to být asi cat id_dsa.pub | ssh blabla 'cat >> authorized_keys') a ve dvojce nevím, co tím myslíš...
Btw. zkus víc véček (ssh -vvv), bude ukecanější 
Abych ještě upřesnil jak jsem se k tomu dostal: ...Ano, spravne, treba to upresnit. To, co si napisal, je zmatok. Nie je jasne, co si spustal v ktorom adresari, dokonca ani to, co si spustil na serveri a co na klientovi. Typujem dve mozne priciny, preco to nefunguje: A) Sukromny a verejny kluc spolu akosi nekoresponduju - obsahom ci umiestnenim; pozri poznamky predrecnikov k bodu 2). B) Kluce nie su dostatocne chranene spravnymi pristupovymi pravami, co je najcastejsia pricina tychto problemov. Prenos privatneho kluca spod windowsu do linux, resp. vseobecne prenos privatneho kluca odkialkolvek kamkolvek je nezmysel. Ten kluc je privatny prave preto, ze naveky zostava na tom jedinom mieste, pre ktore sa zrodil, a akykolvek jeho unik mimo je porusenim bezpecnosti, ktoru ma zabezpecovat.
Hlavně, soukromý klíč (.ppk) mám už vygenerovaný od správce serveru a potřebuji se připojovat pouze z PC na server, ne obráceně, takže jestli jsem to teď pochopil dobře ani bych u sebe veřejný klíč mít nemusel (veřejný klíč k soukromému klíči, který jsem dostal, je správně uložený na serveru).
Tahle část (generování nových klíčů) je pravděpodobně zbytečná, ale známý my to takhle radil a nemělo by to nic zkazit:
v adresáří ~/.ssh
ssh-keygen -t dsa
id_dsa jsem přepsal svým (na serveru vygenerovaným) klíčem, který mám uložený bokem.
Nastavil jsem práva:
id_dsa 600
id_dsa.pub 644
~/.ssh 700
(můj home má 755, takže tady by být problém neměl)
a potom už se jenom zkusil přihlásit pomocí:
ssh -p 01.234.567.890 -l "name" -v "server.cz"
Jinak proč by měl být přenos klíče blbost? Pokud by to bylo mezi počítači, tak bych dokázal pochopit, že se zvyšuje pravděpodobnost, že někdo někde klíč zachytí, ale jenom z win na linux a to na stejném počítači?
client$ ssh-keygen -t dsaSubor
.pub prenes na server. Na serveri jeho obsah pripoj k suboru authorized_keys:
server$ cat id_dsa.pub >> ~/.ssh/authorized_keysOver spravne pristupove prava na serveri:
server$ chmod 700 ~/.ssh server$ chmod 600 ~/.ssh/authorized_keys
Jinak proč by měl být přenos klíče blbost?Lebo spravca servera, ktori Ti ten private kluc pre Tvojho klienta poslal, si ho moze nechat, moze ho poskytnut niekomu inemu, alebo mu ho niekto iny moze ukradnut. Kazdy, kto ho akymkolvek sposobom ziska, zaroven ziska aj pristup k Tvojmu kontu. Privatny kluc je proste PRIVATNY a nema ho mat nikto okrem majitela uctu. Ani spravca servera nie. Ak to tak nie je, je cela wannabe-security v haji a namiesto trapenia sa s SSH klucmi mozete pouzivat rovno telnet.
-i můžete ssh klientovi vnutit natvrdo soubor, odkud má vzít váš soukromý klíč. Pokud to neprojde, zřejmě nemáte na serveru v příslušném souboru authorized_keys zkopírován veřejný protějšek tohoto soukromého klíče. Asi bych to zkusil s novým párem klíčů (pokud máte možnost si ten veřejný umístit na server sám), a pokud to znovu selže, asi vám nezbude než požádat o spolupráci administrátora serveru. V logu serveru o tom spojení budou další informace, které pomůžou dál v pátrání (možná server hledá váš veřejný klíč v jiném umístění, než kam jste ho ve skutečnosti umístil, na to bych se zaměřil ze všeho nejdřív), administrátor navíc může zvýšit úroveň verbosity serveru, aby získal další podrobnosti. Pokud na serveru běží selinux, podíval bych se též, jestli ten pokus o použití klíče nezabíjí právě on.
debug1: Authentications that can continue: publickey,password - seznam moznych zpusobu autentizace
debug1: Next authentication method: publickey
debug1: Offering public key: /home/pavel/.ssh/id_dsa - nabidnutej dsa klic
debug1: Authentications that can continue: publickey,password - neni akceptovan proto znovu seznam
debug1: Trying private key: /home/pavel/.ssh/identity
debug1: Trying private key: /home/pavel/.ssh/id_rsa - nabidnutej rsa klic
debug1: Next authentication method: password - opet neni akceptovan znovu seznam
name@server.cz's password: - uz to chce normalni uzivatelsky heslo
debug1: Offering public key: /home/pavel/.ssh/id_dsa authorized_keys – buď tam můžete nechat oba, nebo si nově vytvořený klíč zkonvertujte i do Putty a ten starý z authorized_keys smažte (pokud jej používáte jen vy, což je rozumné).
Jinak kdyby měl někdo stejný problém, tak ...... tak nech to vyriesi tak, ako sa to ma - vygenerovanim noveho klucoveho paru pre nove pristupove miesto - a podobne misuse pouziva iba ak nic ine nie je mozne.
Tiskni
Sdílej:
2.10.2009 12:31