アカウント名:
パスワード:
ありがとうございます!裏で jcabi-ssh.key という一時ファイルを作っていますね。 com.jcbi.ssh.SSH [github.com]JSchを使う以上仕方ない実装かと思います。ファイルパスで渡しても読み込んで改めて自分で一時ファイルを作ってるのでちょっとお行儀悪くも感じますねこれ。できれば全部メモリ上で済ませたいことなので、ちょっと違うんですよね…Pythonで言うStringIOのようなものがJavaにあればいいんですが、結局それってInputStreamになるのでそっち使ってくれよ!って色んなライブラリ見るたびに思ってしまう…引き続き自分でも探してみます。
ありがとうございます&反応が遅れてすみません。試そうとしたところビルドエラーで引っかかっていて、ちょっと原因調査は週末に…となってました。
どうもOSによるパスの扱いで問題…とまでは言いませんがテストケース通りに動いていないみたいです。(テストケースではパスの区切りが "/" 固定で取れることを期待しているが Windows では "\" になる)私の使おうとしているプログラムはLinux/Windowsいずれのサーバ環境でも動かす必要があるため、もしかしたら問題が出そうです。
さて上記についてはテストケースを通るようにしてしまえばいいので、ビルドはできました。実際動作を確認してみたところ以下のようになっていていい感じです。・known_hosts はなくてもいいし、勝手に作ることもない(もちろん見ることもできる)・キー情報は SSHClient の loadKeys で文字列をよしなに読み込んでくれる。 引数には PublicKey もあるが、null でいい。・リモートからのファイルの取得も全部メモリ上で出来る。(&直接ファイル出力もできる)・鍵周りに必要な処理は BouncyCastle 依存にできるからそっちが更新されていれば不安が少ない
ちょっといけてないのは・ビルドの際に Java Cryptography Extension (JCE) が必要(java-home/lib に入れる必要あり)・先述のようにWindows環境で検証されてないっぽいというところでしょうか。メンテは止まってないっぽいので一番実用的に感じます。
以下サンプルです。
try( SSHClient ssh = new SSHClient() ) { ssh.addHostKeyVerifier((s, i, publicKey) -> true); ssh.connect(hostname, port); List<KeyProvider> keyProviders = new LinkedList<>(); keyProviders.add( ssh.loadKeys( privateKey, publicKey, new PasswordFinder() { public char[] reqPassword(Resource<?> resource) { return privateKeyPassphrase.toCharArray(); } public boolean shouldRetry(Resource<?> resource) { return false; } }) ); ssh.authPublickey(username, keyProviders); ByteArrayOutputStream output = new ByteArrayOutputStream(); try( SFTPClient sftp = ssh.newSFTPClient() ) { RemoteFile file = sftp.open(sampleFilePath); IOUtils.copy(file.new RemoteFileInputStream(), output); } System.out.println(output);}
ホームディレクトリパスの取り方は…StatefulSFTPClientを使ってログイン時に pwd() するのが正しいのかな?使いやすくもありますので、実際のコードに入れて問題ないかどうか確かめてみます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
jcabi-ssh (スコア:1)
APIは極めてシンプルなので目的にあっているかどうかわかりませんが。
Re:jcabi-ssh (スコア:1)
ありがとうございます!
裏で jcabi-ssh.key という一時ファイルを作っていますね。 com.jcbi.ssh.SSH [github.com]
JSchを使う以上仕方ない実装かと思います。
ファイルパスで渡しても読み込んで改めて自分で一時ファイルを作ってるのでちょっとお行儀悪くも感じますねこれ。
できれば全部メモリ上で済ませたいことなので、ちょっと違うんですよね…
Pythonで言うStringIOのようなものがJavaにあればいいんですが、結局それってInputStreamになるのでそっち使ってくれよ!って色んなライブラリ見るたびに思ってしまう…
引き続き自分でも探してみます。
sshj (スコア:1)
> JSchを使う以上仕方ない実装かと思います。
まあ、JSchに対するラッパーライブラリであるため一時ファイルを使っているだろうと思っていました。
他にないか調べてみたらsshj [github.com]を見つけました。
キーファイルを扱うクラスのベースの実装BaseFileKeyProvider.java [github.com]を見るとキーファイルの初期化のためのクラスとしてReader, File, Stringのいずれかを指定できるようになっているようです。
キー情報の読み込み部分の実装は(初期化で指定したキー情報から変換した)Reader経由で行うようになっているため一時ファイルは作成されないと思います。
Re:sshj (スコア:1)
ありがとうございます&反応が遅れてすみません。
試そうとしたところビルドエラーで引っかかっていて、ちょっと原因調査は週末に…となってました。
どうもOSによるパスの扱いで問題…とまでは言いませんがテストケース通りに動いていないみたいです。
(テストケースではパスの区切りが "/" 固定で取れることを期待しているが Windows では "\" になる)
私の使おうとしているプログラムはLinux/Windowsいずれのサーバ環境でも動かす必要があるため、もしかしたら問題が出そうです。
さて上記についてはテストケースを通るようにしてしまえばいいので、ビルドはできました。
実際動作を確認してみたところ以下のようになっていていい感じです。
・known_hosts はなくてもいいし、勝手に作ることもない(もちろん見ることもできる)
・キー情報は SSHClient の loadKeys で文字列をよしなに読み込んでくれる。
引数には PublicKey もあるが、null でいい。
・リモートからのファイルの取得も全部メモリ上で出来る。(&直接ファイル出力もできる)
・鍵周りに必要な処理は BouncyCastle 依存にできるからそっちが更新されていれば不安が少ない
ちょっといけてないのは
・ビルドの際に Java Cryptography Extension (JCE) が必要(java-home/lib に入れる必要あり)
・先述のようにWindows環境で検証されてないっぽい
というところでしょうか。
メンテは止まってないっぽいので一番実用的に感じます。
以下サンプルです。
ホームディレクトリパスの取り方は…StatefulSFTPClientを使ってログイン時に pwd() するのが正しいのかな?
使いやすくもありますので、実際のコードに入れて問題ないかどうか確かめてみます。