Jé, sch

Jó hírem van: addig berheltem szegény jsch-t, míg végül egy PuTTY-féle PPK-fájlból kiolvasott ECDSA-kulccsal is tudott kapcsolódni a derék termék. És méghozzá nem kellett Windows-os CRLF-es sorok legyenek a .PPK fájlban.
 

Normálisan ugye ilyenkor kapcsolatba lépünk a maintainer-rel. Esetünkben (surprise!) ez nem látszik perspektivikusnak. Vagy kapcsolatba lépünk a fork maintainerével. Sajnos a fork nem tetszik nekem, az első lambdánál elment tőle a kedvem. Tehát a C-terv az, hogy újabb forkot berhelünk, de azért valamelyes engedményt teszünk a múló időnek, és Java1.5 kompatibilisen alkotunk. Egyelőre nincs belőle letölthető release, de ha lesz, 0.1.55a lesz a verziószám, hogy ne lehessen összetéveszteni a másik forkkal.

https://sourceforge.net/projects/jsch/
https://github.com/mwiede/jsch
https://github.com/lzsiga/jsch

Hozzászólások

Az egy borzalom. Mondjuk legalább van valami, Javaban nem jellemző, inkább C-ben: libssh meg libssh2. Javaban sshd van, Apache-s.

Valamikor régen én is használtam ezt a libet. Nagyon hasznos jószág. Nincs valami hasonló a jgit "alatt"? Az is tud natívan ssh-n keresztül kapcsolódni. Azt nem tudnád használni, az biztosan rendesen karban van tartva?

Én mostanában ami ssh-s dolgot csináltam Java-ban, azt úgy csináltam, hogy parancssori ssh-t indítottam ProcessBuilderrel, és azon pájpoltam át az oxigént. Persze csak a két program közötti kommunikációt kellett megoldanom, port forwarding, stb nem kellett. És arra sem volt igényem, hogy rendes multiplatform programként mindenhol fusson a produktum, tehát feltételezhettem, hogy parancssori ssh telepítve van.

Szerkesztve: 2020. 07. 09., cs – 14:28

> az első lambdánál elment tőle a kedvem. 

Mi a baj a lambdakkal amugy? A map/reduce fuggvenyeket azzal a legjobb kezelni.

> Java1.5 kompatibilisen alkotunk. 

1.6 ala nem erdemes menni, de Java 8-nal regebbi Java sehol nincs mar.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-