Kulcsszivárgás PuTTY alatt

Security-all

A PuTTY egy hibás metódust használt az elliptikus ív kulcsgeneráláshoz, ami során kikerültek a privát kulcsok.

https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-b…

Javítás: frissíteni 0.81-re, és minden olyan kulcs cseréje, ami a korábbi verzióval használva volt.

Bővebben: a PuTTY a NIST P521-et használta (ecdsa-sha2-nistp521), amiben sérülékenységet fedeztek fel (CVE-2024-31497). A javított verzió nem használja már ezt a konkrét metódust ezzel a konkrét kulcsmérettel. Öröm az ürömben, hogy más kulcsméretek úgy látszik nem voltak érintettek, illetve akkor sincs baj, ha a szerver oldali SSH-ban le volt tiltva a NIST P521, ezért a handshake-nél más metódust választott a PuTTY. Az nem egészen világos számomra, hogy lehet kihasználni ezt (feltéve, hogy a szerver is ugyanaz a security domain), de jobb a biztonság.

  • 3033 megtekintés

( NevemTeve | 2024. 04. 16., k – 10:34 )

Szerkesztve: 2024. 04. 16., k – 10:41

Mondjuk nem egészen biztos, hogy nyugodt vagyok: azt mondja, hogy ha a generált 521-bites pszeudovéletlen értékből első 9 bit nulla, akkor 60 minta elég a privátkulcs (PK) visszaallításához.

Lehetséges-e, hogy átlagosan 1:512 eséllyel hibátlan véletlenszám-generátorral is nulla legyen az első 9 bit, ami azt sugallná, hogy átlagosan 512*60=30720 eset kell a PK visszaállításához.

Szerk: úgy vélem hallani, hogy ez azért nem gond, mert ez az egyszer-használatos érték (nonce) nem látszik a kommunikációban, tehát a rosszfickó nem tudja, hogy a 30720 esetből melyik 60-at válassza ki. (binom(30720,60)=2e187)

Igen, egyrészről így van, másrészről meg ne felejtsük el, hogy idegen gépre ritkán ssh-zik az ember. Azaz mind a kliens, mind a szerver ugyanaz a security domain, és csak a szerveren lehetne ezzel a módszerrel a privát kulcsot ellopni, harmadik fél számára továbbra is lehetetlen lehallgatni az SSL titkosított csatornát. (Felteszem ssh-t jellemzően cégen belül használnak az emberek, külsös tárhelyszolgáltatónál pl. tipikusan cpanel vagy valami hasonló csoda szokott lenni, nem ssh.)

De azért jobb frissíteni és kulcsot cserélni, biztos, ami biztos alapon.

Ha jól értem, itt elsősorban az a para, hogy ez a metódus volt az alapértelmezett a PuTTY-ban, de attól még ha az SSL/TLS handshake-nél a szerver nem mondta, hogy ezt is tudja, akkor egyáltalán nem is volt használva. Szóval a kérdés elsősorban az, hogy azoknál az OpenSSH-nál, ahova PuTTY-al csatlakozott az ember, és nem saját szerver, ott alapértelmezetten támogatva volt-e a NIST P521. Az openssl s_client tud olyant, hogy kiírja, milyen delivery encryption-öket támogat egy szerver.

A titkosítás az adott alkalmazás protokoll feletti réteg (transport layer).

Azt nem tudom, hogy PuTTY alatt lehet-e ezt dumpolni, és ha igen, akkor hogyan. OpenSSH-ban is viszonylag új feature, 6.8 óta van erre a -G kapcsoló (hirtelen nem is jutott eszembe, hogy már belekerült ez az opció).

Nem, az SSH az nem RSH over TLS. Ez nem olyan, mint a HTTPS, ami csak egy TLS csatornában HTTP üzeneteket küld.

Az SSH nem TLS csatornát nyit, saját protokollja van a handshake-re és minden másra. Nem is TLS tanúsítványokat használ a két oldal azonosítására, hanem SSH kulcsokat. Az SSH közvetlenül TCP felett működik, nem TLS felett.

Érdemes elolvasnod ezt: https://datatracker.ietf.org/doc/html/rfc4253#section-7

Az s_client az valóban csak egy TLS csatornát nyit, amin belül azt küldesz, amit akarsz.

Lehet, hogy csak az OpenSSH-t keverted az OpenSSL-lel?

Szerk: ahogy az FTPS (FTP over TLS) sem ugyanaz, mint az SFTP (file transzfer, de SSH használatával).

Az SSH nem TLS csatornát nyit

Dehogynem. TLS = Transport Layer Security, és láss csodát, az SSH is pont egy ilyen transport layer protokoll!

Az s_client az valóban csak egy TLS csatornát nyit, amin belül azt küldesz, amit akarsz.

Pont, mint az SSH. Láttál-e már SSH port forward-ot? Pont így működik, valóban csak egy TLS csatornát nyit, amin belül azt küldesz, amit akarsz (X11-et mondjuk).

A baj az, hogy nem vagy tisztában a TLS jelentésével, azt hiszed, az egy konkrét protokoll, holott valójában az egy réteg, számtalan implementációval (és még azon belül is számtalan opcióval). Bár mélyebb rétegeket valósít meg, de tulajdonképpen az IPSec és a VPN is pont ugyanezt csinálja, független titkosítási réteg, aminek tök mindegy, hogy a layer 7 forgalom mi (a különbség csak annyi, hogy itt az alkalmazásnak még csak tudnia sem kell róla, hogy titkosított a forgalom).

Lehet, hogy csak az OpenSSH-t keverted az OpenSSL-lel?

Nem, nem keverem, példának írtam. Jobb lett volna az ssh -G példának (de hirtelen nem jutott eszembe), vagy mégjobb lett volna, ha megtalálom a PuTTY doksiban azzal hogy kell, már ha egyáltalán lehet vele ilyent dumpolni, de nem találtam.

Nem. A TLS egy jól definiált protokoll neve, ugyanúgy, ahogy az IP, aTCP és az UDP is. Attól, hogy az ICMP is az interneten keresztüli protokoll, még nem lesz IP, hiába az az IP jelentése, hogy Internet Protocol.

Ugyanúgy, a gopher sem lesz HTTP, pedig az is hiperlinkelt dokumentumok kiszolgálására való.

A POP sem lesz IMAP, pedig ugyanúgy internetes levelek elérésére szolgáló protokoll.

Az SSH sem RSH, pedig mindkettő távelérésre szolgál. Az SCTP sem UDP, pedig az is datagram protokoll.

Az IT-ben a dolgoknak megvan a maga neve és jelentése, okkal.

A példásban az IPSec egy konkrét protokoll, a VPN nem. Eleve a VPN önmagában nem jelent titkosítást, csak virtuális hálózat kialakítást más hálózatok felett, ami önmagában egy routing/tunneling feladat, semmi köze titkosításhoz. Az L2TP-ben például a tunnel felépítése után alapértelmezetten nincs is titkosítás.Vagy éppen GRE/PPTP tunnel, tökéletesen alkalmas virtuális hálózat kialakításra, mégsincs benne encryption, mert az totál más feladatkör (nem tunneling/routing).

az SSH-nak semmi köze a TLS-hez

Olvasd el az RFC-t. Ugyanaz pepitában. Bitszinten eltér? Igen. Algoritmusszinten eltér? Nem. Funkcionalitásban eltér? Nem.

Tisztában vagyok vele, hogy a PuTTY effective configuration dumpolását illett volna linkelnem, de már mondtam (többször is), hogy azt nem találtam a doksiban, és Ti sem vagytok képesek leírni, hogy kell.
Bocs, hogy segíteni próbáltam! (szarkazmus)

Igen, egyrészről így van, másrészről meg ne felejtsük el, hogy idegen gépre ritkán ssh-zik az ember. Azaz mind a kliens, mind a szerver ugyanaz a security domain, és csak a szerveren lehetne ezzel a módszerrel a privát kulcsot ellopni, harmadik fél számára továbbra is lehetetlen lehallgatni az SSL titkosított csatornát. (Felteszem ssh-t jellemzően cégen belül használnak az emberek, külsös tárhelyszolgáltatónál pl. tipikusan cpanel vagy valami hasonló csoda szokott lenni, nem ssh.)

 

én nem ezt olvastam: 

An attacker in possession of a few dozen signed messages and the public key has enough information to recover the private key

én nem ezt olvastam

Csak azért, mert nem is olvastad végig:

To obtain these signatures, an attacker need only briefly compromise any server you use the key to authenticate to

However, these signatures are not exposed to passive eavesdroppers of SSH connections

Fabian Bäumer nem ezt írja... nem csak a szerverről lehet signature-öket "gyűjteni"... 

 

There are instances where this vulnerability can be exploited without the need to compromise a server in advance.

One such case is the use of SSH keys for signing Git commits. A common setup involves using Pageant, the ssh-agent of PuTTY, locally and forwarding the agent to a development host.

Here, you configure Git to use OpenSSH to sign Git commits with the SSH key provided by Pageant. The signature is then generated by Pageant, making it susceptible to private key recovery.

This is particularly concerning as git signatures may be publicly accessible, for example, if the commit is pushed to a public repository on GitHub.

nekifutottam... még mindig arról van szó, hogy a "cryptographic signature"-ből (ami lehet git aláírás is és amikből kell vagy 58-60, az a lényeg, hogy a private key lett erre használva) annyira le lehet szűkíteni a dolgokat, hogy a private key-t magát meg lehet rekonstruálni.

 

Felteszem ssh-t jellemzően cégen belül használnak az emberek, külsös tárhelyszolgáltatónál pl. tipikusan cpanel vagy valami hasonló csoda szokott lenni, nem ssh.

Ez az állításod is téves. Ezer olyan helyzet van, ahol ssh-t használnak nem "ugyanazon a security domain-en" belül, hogy idézzelek. A sima VPS-ektől elkezdve (ahol megadsz egy ssh public key-t a setupoláshoz, hogy el tudd ugye érni) egy mondjuk Bitbucket-ig... ezeknél mindenhol kompromittálva lehet a dolog szerveroldalon...

A sima VPS-ektől elkezdve (ahol megadsz egy ssh public key-t a setupoláshoz

Ott Te konfolod az ssh szervert.

Egyébként csak ismételni tudom magam,

Tök mindegy, ha valaki PuTTY-ot használ, az frissítsen és cseréljen kulcsot, pont. Better to be safe than sorry.

( zeller | 2024. 04. 16., k – 10:38 )

Mi köze van a kulcsgeneráláshoz a Föld keringési síkjának (ekliptika)...?

Az, hogy bazi nagy relatív prímekkel számolni macerás és lassú, ezért nem is használják a csatorna titkosítására. Helyette csak egy kulcsot beszél meg vele a kliens és a szerver a csatorna felépítésekor, aztán az adatokat már egy egyszerűbb, gyorsabban számolható metódussal titkosítják csak. Az "elliptic curve dsa" egy ilyen csatornatitkosító metódus (ráadásul a legáltalánosabban használt).

Ja, hogy azt mondod, elütöttem :-) Jogos, "elliptic".

( zitev v | 2024. 04. 17., sze – 15:49 )

Szerkesztve: 2024. 04. 17., sze – 15:53

érdekes, most 404-es a download-link, délelőtt még le tudtam szedni..

--

rossz a link, ha javítom a verziószámot benne, akkor már lejön.. átírhatták az exe verziószámát a fájlnévben, csak a rámutató link maradt a régi..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( Caro | 2024. 04. 17., sze – 21:23 )

Na akkor megnyugodtam, szerencsére mindig is maradtam a jól bevált 2048 bites RSA kulcsok mellett.

Amúgy valaki mondja már el, hogy mi a baj a hosszú RSA kulcsokkal? Mert manapság divat lett őket tiltani. Nem quantum-proof, ezt felfogom. Túl tudom élni.

"...This non-elliptic crypto algorithm is based on prime numbers. It is probably the most used algorithm used today. When generating keys with less then 2048-bits it is also considered insecure. The problem with RSA is it's source of entropy that is causing the weakest link. This is probable the first algorithm to fall when quantum computations will get more mature. Using a keysize of 3072-bit you should be safe for the upcoming 2 years, whereas the 4096-bit keys should probably put you on the safe side for at least the next 5 years...." - https://marcofranssen.nl/upgrade-your-ssh-security

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Oké, akkor csak a "kvantum hiszti" miatt. Ezzel kibékülök. Valamirevaló kvantumszámítógép egyelőre azért nincs minden kiberbűnöző zsebében.

Az, hogy az NSA meg egyéb GO meg tudja törni, az nem érdekel, mert ha nekik annyira fontos az információ, akkor úgyis megszerzik.

Majd ha tömegesen elkezdik törni az RSA kulcspárokat, akkor elkezdek rajta gondolkodni.

Nem tudom hogy számítási kapacitásban pl. egy cryptobányászatra már alkalmatlan bányásztelep minek számít, és mennyire van pariban egy kvantumszámítógéppel, de félni még mindig jobb, pláne a fent leírtak alapján..

"Majd ha tömegesen elkezdik törni az RSA kulcspárokat, akkor elkezdek rajta gondolkodni."

- ezt ugye nem fogják előre bejelenteni, utólag meg lehet majd filózni, hogy vajon átesett-e az ember rajta, vagy sem..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Semennyire nincs vele pariban. Itt tartanak jelenleg:

https://en.wikipedia.org/wiki/RSA_Factoring_Challenge

A kvantum csak azért "veszélyes", mert nagyon párhuzamosan tud dolgozni. A sok bittel nem tudsz versenyezni klasszikus CPU-k párhuzamosításával, mert minden plusz bitre kétszerezni kell a CPU számot.

Eszignoek jövőre már kivezetik a 2048bites kulcsokat (https://e-szigno.hu/news/changes-supported-cryptographic-algorithms-jan…),ezt a kulcsmeretet 2030-ig tartják biztonságosnak (persze attól függően, hogyan fejlődik az erre fenyegetést jelentő kriptograf-hacker-ipar): https://www.jscape.com/blog/should-i-start-using-4096-bit-rsa-keys

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Semennyire. Itthon is azt használok otvaros synologhoz és ezeréves Asus routerben. Persze még kellene mérni scp, vagy sftp-vel az átviteli sebességet mindkét kulcssal, de adminisztralasban nem érezhető sebesség különbség.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ezeréves Asus router jellegű eszközökre vonatkozott a kérdés legfőképpen ezek miatt:

1) CPU-erőből nem bírja a matekot. Ilyenkor működik ugyan, de minden új sessiön felépítés fájdalmasan hosszúra nyúlik el

2) a szoftver megállt a 2048 bites RootCA RSA kulcsoknál, a 4096-ossal már nem tud mit kezdeni, azaz fel sem tud épülni a kapcsolat

Attól függ, mennyire ezeréves - nekem egy Asus rt-ac66u_b1-el pl. popecul megy (most nem emlékszem pontosan, de mintha egy gatewaynek használt wl-500gp v2-on is lett volna 4096bites rsa kulcs és annak sem okozott gondot.).

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Hát, kezdetnek: milyen RFC-ben tárgyalják az ECC-vel való titkosítást szabványos módját? (a napló kedvéért: kifejezett az encryption műveletről van szó, nem a sign-ról vagy a key-exchange-ről).

Egyébként hallani véltem olyasmit, hogy az ElGamal nevű algoritmus DH-n alapszik, és ECDH felett is meg lehet csinálni, de ez nem egészen ugyanaz, mintha lenne egy RFC-ben rögzített szabványos módszer, amit elterjedt programok implementálnak.

Szerk: kezdeményezések voltak, pl.: https://github.com/openssl/openssl/issues/2842

( buga v | 2024. 04. 17., sze – 22:49 )

Szerkesztve: 2024. 04. 17., sze – 22:49

Nem vagyok egy kifejezett kripto-expert. Ha én szerverüzemeltető oldalon vagyok, akkor lehetséges egy blacklistet generálni hasonlóan ahhoz, amikor a Debian OpenSSL fiaskó idején történt, hogy a potenciáisan kompromitálódott kulcsokat ne fogadjuk el szerveroldalon?

Úgy értelmeztem a leírást a PuTTY vulnerability vuln-p521-bias (greenend.org.uk) oldalon leírtak alapján, hogy alapjában véve itt is a kulcs véletlenszerűségével van a gond, akárcsak a 2008-as debianos incidensnél.  Előfordulhat, hogy valamilyen lényegi különbség miatt (például túl sok van belőle) itt nem előállítható ilyen lista és a key blacklisting nem opció.  A kriptós/matekos hátterem nincs meg a lentiek alapos értelmezéséhez, ezért fogalmaztam óvatosan.
 

This means that it's dangerous to generate DSA signatures on systems with no high-quality source of randomness. Significantly more dangerous than generating the encryption keys for a single session: a leak of the private key compromises far more than one SSH session.

For this reason, since PuTTY was developed on Windows before it had any cryptographic random number generator at all, PuTTY has always generated its k using a deterministic method, avoiding the need for random numbers at all. The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key. Secure hash output is indistinguishable from random data (or else the hash function isn't doing its job), and this generation method can't be repeated by an attacker who's trying to find out the private key – if they could generate the same hash input as you, they'd already have the private key.

This technique is now mainstream, and RFC 6979 documents a specific well-known way of doing it. But PuTTY didn't follow that specification, because we started doing the same thing in 2001, and the RFC wasn't published until 2013.

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

This bias is sufficient to allow a key recovery attack.

Bocs, én is félreértettem a dolgot, elolvastam a levelet alaposan. Itt csak a PuTTY implementáció a gond az ECDSA nonce generálásnál. Ugyanezekből a kulcsokból más implementáció jó ECDSA nonce-okat generál.

Azt te nem tudhatod, hogy az X kulcsot hányszor használták PuTTY-val úgy, hogy egy támadó visszafejthette a privát kulcsot ezekből a használatokból.

Azaz nem maga a kulcs a problémás (nem is a kulcs generálása), hanem az, hogy ezt a kulcsot konkrétan PuTTY-val használták.

Ugyanezekből a kulcsokból más implementáció jó ECDSA nonce-okat generál.

Így van, valamint ugyanezzel az implementációval más kulcsméretnél sincs probléma PuTTY alatt. A gond inkább itt az, hogy ha jól értem, ez volt a default kulcs metódus és méret, szóval kevesen állították át másra.

( Raynes v | 2024. 04. 23., k – 18:00 )

Most komolyan, mennyien használják még ezt a PuTTY-t? A Win2k-8-as érában volt népszerű, a Win10-11 kapott rendes terminált, SSH klienst, amit fel lehet tenni, vagy akár WSL-lel is megoldható, Linuxra, meg egyéb unixlike rendszerekre van egy kazal jobb terminál, meg rendszerbe épített sshd, SSH kliensek.

Retró gépen lehet is értelme, bár a TeraTerm, vagy ha még régebbi, akkor Telix, Kermit is játszik, de modern környezetben nem látom sok értelmét. Gondolom aki még fel is teszi, pótcselekvésből, vagy mert ezt ismeri, vagy olyan tutorialt talál meg valahol a neten, ami azt használja.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A megszokás nagyon nagy úr ám... De igen, én is mondom mindenkinek, hogy felejtse már el a céemdéegzét meg a puttit :-) , és használjon "rendes" terminált meg ssh klienst...

Ahol putty érdemben szembe jött, az egy winscp-s feladat, ahol agent-forward kellett, amihez a pageant és az abba tölthető putty-os kulcs lett a megoldás.

Még Alacritty is van. Sőt, volt egy harmadik is, az valami JS-alapú, Electron app, de az is terminál. Szóval van opció már bőven.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ami azért lássuk be, ritkán használt feauturenél nem olyan nagy baj az a kattintgatás. Én elég jól ismerem az SSHt, de most annyi rémlik, hogy vagy masterchanneles connection kell, vagy a fasztudja milyen escape előhoz egy mini shellt, amibe be tudom gépelni hogy -L8080:8080 (de ez egyébként tud akadni valami paraméterrel), mire ezt kiguglizom, addigra kb 13x végzek azzal, hogy jobb klikk, megkeresem a szememmel azt a menüpontot, ahol a portforawardot lehet hozzáadni, és beírom mit szeretnék.

Egyrészt van az a szitu, amikor ezt nem igazán tudod megtenni (de legalábbis hosszabban kell hákolni).

Másrészt ja, most én is ezt csinálnám, mert a faszom se tudja megjegyezni az escapet, ha most megnézem, mire legközelebb kéne, úgyis elfelejtem. Cserébe akinél nem a megszokás nagy úr ;) annak azért feltűnik, hogy valójában elég macerás az emiatt újra autholok, visszamászok oda, ahol az előbb tartottam, esetleg elbaszódik a historym, ahhoz képest, hogy simán csak össze egérbuzgom midenféle extra körök nélkül , kényelmesen.

Ezeket egyébként karban lehet tartani egy ssh_config-ban is azért (bizonyos tekintetben jobban is, mint a guiban, mert vannak patternek), de ja, egyébként elég kényelmes. Én anno, mikor ilyen ezer helyre kellett járni, vetettem a céggel SecureCRT-t, elég fasza cucc volt.

A PuTTY a WindowsTerminal+openssh kombóval állítható párhuzamba, és ebből az egyik bizony a MS terméke. És méghozza user-élmény inkább a terminálemulátorból jön, nem abból, hogy milyen jól mennek a titkosított bitek a két készülék között.

WSL2 príma középút - ha CAD-es gép, akkor RAM gondolom van benne bőven, ergo az a 2-4GiB,a mit egy wsl2-es (=kicsontozott HyperV) Linux elvisz, az nem oszt, nem szoroz. Az X-es alkalmazások is mennek mindenféle bűvölés meg külön windows-os X-szerver nélkül, a /mnt/c alatt ott a C:\ meghajtód, illetve a Windows alól is látod a Linuxod teljes fájlrendszerét, úgyhogy azt az esetet kivéve, amikor Linux alatt is kell ugyanannyi erőforrás, mint Windows alatt, a dual boot nem biztos, hogy valóban jó és kényelmes megoldás.

Annyira nem bika (NYÁK tervező, nem olyan durva mint a 3D tervezők), csak 32G RAM, de van vagy 6-8 virtuális gépem is, mind linuxxal. Általában az egyes nagyobb projekteknek csinálok egy külön gépet. A linuxos gépeket általában fejlesztőkörnyezetnek (compiler toolchain az adott processzornak megfelelően) illetve égetésre használom. Ezt így könnyű becsomagolni, átadni, ha valakinek szükséges.

Hajrá ugyanezt WSL-el megcsinálni. Meg minek szívjak a M$ félmegoldásaival, amikor így dolgozhatok debianon is közvetlenül.

Windows alatt a winscp/notepad++/putty/virtualbox shared folderek egészen használható ökoszisztémát adnak ki. Erre szinte azt is mondom, hogy jobb user experience, mint a linuxos megoldások.

Win10-11 kapott rendes terminált, SSH klienst

Erről úgy néz ki lemaradtam.... kisegítenél hogy mi lenne az a 'rendes terminál' meg az SSH kliens ami gyárilag a windows része?

 

edit:

csak mert ha a mikroszoftos appsztórban található izékre utalsz... akoz bizony nem részei egy windows telepítésnek, ennek megfelelően nem is elérhetőek a legtöbb környezetben.

 

a pageant + puttygen + putty kombót pedig - szerintem - egyedül a MobaXterm tudná kiváltani, de az meg nem is open-source és nem is free (for commercial use)

 

Köszi.

zrubi.hu

sőt még curl is van, a hxxorok nagy örömére by default :)

C:\Windows\System32>curl.exe --version
curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
Release-Date: 2023-10-11
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets

Egyelőre nem "gyárilag a windows része", nem is ezt írta, hanem azt, hogy kapott rendes terminált meg OpenSSH-t. Anno a Windows kapcsán az volt sokaknak a se&&fájása, hogy "mindent is" felpakol, és nem lehet komponensenként válogatni, hogy mi az,a mit szeretne az ember telepíteni, és mi az, amit nem. Most a Windows terminal és az OpenSSH az ilyen, külön telepíthető komponens - most meg ez fáj...? Nem is értem...

"nem is elérhetőek a legtöbb környezetben." - Érdekes, hogy 3rd party alkalmazások "jók", de a Microsoft terméke, illetve a Windows-ra natívan portolt OpenSSH meg nem jó... Megmondom egyébként szerintem mi ennek az oka: a megszokás, a fejlődni lusta emberek hada. Tíz éve is céemdéegze volt meg putti, most is azt használunk... Igaz, hogy erősen sajtreszelő (pláne az előbbi...), de "mekszogtug"...  Igaz, hogy a lemez másik oldalánmeg megy a rinyálás, hogy milyen sz@r má' céemdéexe, meg hogy nincs egy rendes parancssor se' a vindózba'...

"pageant + puttygen + putty kombót pedig - szerintem - egyedül a MobaXterm " - ssh-agent, ssh-keygen, ssh trió tökéletesen megoldja a kérdést, ha ez utóbbi alá egy normális termnált rak az ember... Egyébként meg az ssh-agent/agent-forward használatát célszerű a minimálisra korlátozni, mert erősen megnöveli az érintett account támadhatóságát...
 

Most a Windows terminal és az OpenSSH az ilyen, külön telepíthető komponens - most meg ez fáj...? Nem is értem...

Nézd, én csak kényszer windows használó vagyok, és ilyenkor is általában admin jogok nélküli... Tehát azt használom amit 'adnak'.

Általában a 'nagyon szekjúr' cégek jump szerverei ezek, amikre telepíteni semmit 'nem lehet' DE statiku binárisok általában mégis könnyebben megoldhatóak, mint akármilyen hivatalos app telepítése a zappstore-ból...

Nem utolsó sorban, ezeknek általában internet elérése sincs -> tehát a zappstore sem elérhető. (azt nem tudom, hogy ez hozzáértéssel áthidalható-e)

 

És mivel SSH kliens azért mindenképpen kell, Így általában 'marad' a putty - extra esetben 'körítésekkel' együtt.

A 'normális terminál' ugyan ilyen okokból nincs - és erre alternatíva sem igazán.

zrubi.hu

Nincs net elérés? Na ilyenkor szoktam a jól bevált

base64 -d | gzip -d > output

kombóhoz fordulni, aztán ennek a parancsnak a tükörképének a kimenetét copy-paste be a terminálba :) Akár egy soros konzolon is működik, még ha szinte semmilyen normálisabb eszköz sincs telepítve.

Most a Windows terminal és az OpenSSH az ilyen, külön telepíthető komponens - most meg ez fáj...? Nem is értem...

Nézd, én csak kényszer windows használó vagyok, és ilyenkor is általában admin jogok nélküli... Tehát azt használom amit 'adnak'.

Általában a 'nagyon szekjúr' cégek jump szerverei ezek, amikre telepíteni semmit 'nem lehet' DE statiku binárisok általában mégis könnyebben megoldhatóak, mint akármilyen hivatalos app telepítése a zappstore-ból...

Nem utolsó sorban, ezeknek általában internet elérése sincs -> tehát a zappstore sem elérhető. (azt nem tudom, hogy ez hozzáértéssel áthidalható-e)

 

És mivel SSH kliens azért mindenképpen kell, Így általában 'marad' a putty - extra esetben 'körítésekkel' együtt.

A 'normális terminál' ugyan ilyen okokból nincs - és erre alternatíva sem igazán.

zrubi.hu