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.
Hozzászólások
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.
mi köze a s_client-nek az ssh-hoz? két különböző protokollról van szó...
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).
Ez lehetne felvételi kérdés bármilyen szekus munkahelyre. Kíváncsi lennék hányan vannak ezzel az elmélettel tisztában.
Dehogynem. TLS = Transport Layer Security, és láss csodát, az SSH is pont egy ilyen transport layer protokoll!
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).
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).
félrebeszélsz... a TLS-t kb. 99-ben "definiálták", akkor már rég volt SSH....
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)
de attól nem TLS
nekem meg ebből az jött le, hogy te s_client-tel akartad megnézni, hogy mit támogat egy ssh szerver.
Csak ismételni tudom magam,
Igen. Azonban, ebbol a munkapontbol csak tanulassal johetsz ki.
én nem ezt olvastam:
Csak azért, mert nem is olvastad végig:
Fabian Bäumer nem ezt írja... nem csak a szerverről lehet signature-öket "gyűjteni"...
Fuss neki mégegyszer, itt a git signatures may be publicly accessible, nem is a csatorna titkosító kulcsáról van szó, hanem a git aláírásokról!
Tök mindegy, ha valaki PuTTY-ot használ, az frissítsen és cseréljen kulcsot, pont. Better to be safe than sorry.
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.
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...
Ott Te konfolod az ssh szervert.
Egyébként csak ismételni tudom magam,
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".
Igen, azt mondom :-) Köszi a javítást :)
Nem, én kösz, hogy szóltál! Tényleg elírtam.
Szerintem eklektikus lenne helyesen. De bár ez lenne a legnagyobb gondunk.
Elliptic Curves - Computerphile (youtube.com)
Ív helyett én görbének hallottam még. Párszor nekifutottam, hogy megértsem, de nem sikerült, csak annyit, hogy mintha biztonságosabb lenne, mint prímtényezőkkel vacakolni... ...persze ha helyesen implementálják :D
hat hogy akkora a biztonsagossaga hogy meg a holdrol is latszik! ja nem.
Megint egy olyan eset, amikor a "feltéve hogy..." részt is el kellett volna olvasni.
é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
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
4096bit-es RSA kulcsok kezelése mennyire izzasztja meg a kommunikációban levő feleket amíg összeáll a session key?
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
A boldog jövőben egyáltalán nem lesz RSA-kulcs, még titkosítani (encrypt) is ECC-vel fognak. Oh wait...
Mi a baj az ECC-vel?
Ahogy így visszaemlékszem, pont az encryption (amihez csak a partner publikus kulcsa kell), az nem megy ECC-vel, legalábbis az OpenSSL-ben nincs ilyen feature.
Az, hogy mit implementál, meg mit nem implementál az OpenSSL, az hol érdekes magában az ECC-ben?
Nem csak az OpenSSL, pl. az OutLook és a Thunderbird is csak RSA-kulccsal titkosít. (Az aláírás megy EEC-vel is.)
Ettől még mi a baj az ECC-vel mint titkosítással? Az, hogy bizonyos szoftverek nem implementálják, az egy dolog. Ha én írok egy Javas appot, ami a titkosítást mindkét oldalon ECC-vel végzi, akkor mi a gond az ECC-vel?
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
Mi lenne a gyakorlati haszna? Eleve nem szokas aszimmetrikus titkositast hasznalni nagy adatmennyiseghez, ezert van mindenhol csak egy szimmetrikus kulcs titkositva aszimmetrikus titkositassal (akar tobb peer publikus kulcsaval is egyesevel), a bulk encryption meg szimmentikus.
Így van, ezt a dolgot hívják hibrid-titkosításnak; ezért is van az x509-es tanusítványban is a 'keyUsage' résznél külön 'dataEncipherment' meg 'keyEncipherment', a hibrid titkosításhoz elég az utóbbit engedélyezni, az előbbi nem kell.
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?
Ezt hogy érted? Ezek a kliensek privát kulcsai, amelyek csak a kliensnél vannak meg.
Ú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.
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.
Í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.
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.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
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.
az hagyjan, de van valami kitty is, par windozos ismeros azt hasznalja ujabban
http://www.9bis.net/kitty/#!index.md
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.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Jó, az igaz, hogy PuTTY-val mcedit-ben nem megy a Shift+Nyíl kombó, de a Shift+PgUp legalább megy (vagyis visszafelé lapoz a scrollback bufferben), szemben WSL-vel.
Egyszerűen praktikus, könnyű költöztetni a sessionoket, ha sok beállított tunneled, kulcsod van, akkor szóba se jöhet egy cli-s bejelentkezés
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
nálam a PuTTY annyiban simán veri a konzolos SSH klienst, hogy (win alatt) on-the-fly lehet port forwardokat létrehozni/módosítani
Az ssh-val is... Igaz, nem egérbuz...gó kattintásmániás módon... :-P
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.
_egyszer_ kell megírni a .ssh/config fájlt, és a megfelelő Host alá beírni, hogy pl. LocalForward 127.0.0.1:8080 127.0.0.1:8080
A ControlMaster-es móka jópofa, de kellemetlen tud lenni, ha az az ssh session-öd megszakad, ami a master...
Az on-the-fly portforwardot nem írod be az ssh configba, azt a konkrét sessiontől kéred extrában, hogy most, ezen a konkrét kapcsolaton légyszi csináld még meg ezt a portforwardot.
Akkor azt a session-t úgy indítod parancssorból... :-P
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.
A GUI-s felületen összeegerészett beállításokat egyszer kell .ssh/config fájllá konvertálni - azt ugyanis pont ugyanúgy megeszi a windows alá portolt OpenSSH (nálam épp a 8.1.p1 van felrakva, LibreSSL 3.0.2-vel), mint Linux alatt...
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.
Ami működik és bevált, azt miért kell szinte mindig leváltani? Nincs a PuTTY-val semmi gond. Ezt csak a babzsák IT-sok gondolják így.
Hat, miota megtalaltam a MobaXtermet, azota vissza sem nezek.
Mondjuk nem vagyok ITs :)
naponta használom...
Nem tudtam, hogy a windows kapott rendes terminált, de akkor sem használnám a M$ sz*rját, ha ott a PuTTY. Teljesen jó az.
Azért alkalomadtán nézd meg a windows terminal-t meg az openssh klienst... (Az mondjuk funny, hogy "akkor sem használnám a M$ sz*rját, ha ott a PuTTY", de az OS az nem az "M$ sz*rja", de a windows-ra portolt openssh-t meg annak tekinted... )
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.
Kapcsolódó történeti áttekintés 2018-ból (több-részes egész jól helyreteszi ki-kivel-miért-mikor-hogyan), hol áll(t) jelenleg a windows commandline technológiája:
https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/
Céges gépen bár választhatnék linuxot, de a CAD szoftver windows only, tehát dual-boot kéne. Emiatt windows.
Otthon nyilván linux.
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.
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
Windows Terminal
OpenSSH
Start > Terminal
C:\Windows\System32\OpenSSH
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
Csak vigyázz, nehogy póversellből próbáld indítani, mert ott az csak egy alias az invoke-webrequest-re!
Ugyanúgy ahogy sok más linuxból ismert parancsra is csináltak beépített alias-t.
Mondjuk ezt nem tudom, ki találta ki az MS-nél, de személye felveti a change review-k két klasszikus kérdését....
ubuntunal is szorakoznak ilyenekkel, pl. a mailx egy alias hol ilyen hol olyan implementaciora, amiknek nem kompatibilis a parameter szintaxisa...
A mailx attól függően az egyik vagy a másik, hogy melyik csomagot (bsd-mailx vagy mailutils) rakod föl, illetve hogy az alternatives-t hogyan mókolod meg... (Igen, én is khm. örvendeztem vala ennek...)
az meg oke is lenne, csak epp egy do-release-upgrade soran magatol megvaltozott, aztan neztek a babzsakfejlesztok hogy miert nem mukodik a cron-bol futo report mailezo scriptjuk...
Igen, azok is tehetnek egy szívességet. De az ilyeneknél legalább tényleg kb ugyanannak az alternatív implementációi vannak, szopatós különbségekkel. Az se jó, de nem ennyire irritálóan alaptalan marhaság.
A WTF és a Whyyyy? :)
ki volt az, és a többiek miért nem verték agyon?
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...
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.
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
Kulon telepitheto? W11 Pro-n szerintem gyarilag fent volt, de fixme.
szerintem a szerver reszet (service) kell kulon telepiteni, ssh kliens benne van alapbol. en legalabbis sose telepitettem es altalaban mukodik az ssh parancs cmd.exe ablakban
Igen, a szerver kulon jon, a kliensre gondoltam. Egyebkent konkretan ennyi a megoldas:
Ahol a user nem telepíthet külső programot, ott azzal kell dolgozni, amit adnak. Nálunk putty van, az említett terminál viszont nincs. És ilyenkor számít, hogy mi "gyárilag a Windows része".