JSCH addIdentity公钥参数没有任何区别 [英] JSCH addIdentity public key argument doesn't make a difference

问题描述

public class FTP {
  public static void main(String args[]){
    JSch jsch = new JSch();
    jsch.setKnownHosts("./known_hosts"); 

    Path privateKeyPath = Paths.get("./id_dsa");
    byte[] privateKey = Files.readAllBytes(privateKeyPath);

    Path publicKeyPath = Paths.get("./id_dsa.pub");
    byte[] publicKey = Files.readAllBytes(publicKeyPath);

    // Either of the lines below work... Why?
    // jsch.addIdentity("", privateKey, publicKey, null);
    // or 
    jsch.addIdentity("", privateKey, null, null);

    Session session = jsch.getSession("USER", "myHost.com", 22);

    session.connect();

  }
}

将publicKey设置为null并没有什么不同，我可以采用任何一种方式进行连接.为什么会这样?

似乎没有使用publicKey，那么为什么要首先将其传递给addIdentity?

解决方案

这是对(某些)加密私钥的优化.您没有注意到任何区别，因为您使用了未加密的私钥. /p>

如果您为jsch提供了OpenSSL格式的加密私钥，并且没有预先提供用于解密它的密码，而是提供了公钥(从未加密)，那么该密钥对将成为下一个选择.身份验证时，jsch使用公共密钥探测服务器，以确定服务器是否可能接受使用此密钥的身份验证.如果是这样，jsch必须提示输入密码来解密私钥以实际执行身份验证；如果不是，它将跳过提示并转到下一个可能性(如果有).参见com.jcraft.jsch.UserAuthPublicKey.java的来源.

OpenSSH客户端ssh做几乎相同的事情.如果您给它(作为选项，在配置中或默认情况下)使用OpenSSL格式的加密私钥，并且找到匹配的公钥，它将首先探测，并仅在此密钥可用时提示密码短语解密. ssh不允许像Jsch.addIdentity那样预先指定密码，但是它可以使用ssh-agent进程(或替代程序)来完成相同的工作.

OpenSSH自6.5起也支持使用ssh-keygen -o创建的新格式"密钥文件，该文件可以在一个文件中包含加密的私钥和未加密的公钥，从而避免了分别处理公钥的情况. Jsch还不支持这种格式，但是它确实支持PuTTY的PPK格式，该格式具有相同的功能，因此，您可以将单个文件提供为privatekey而不提供publickey.

public class FTP {
  public static void main(String args[]){
    JSch jsch = new JSch();
    jsch.setKnownHosts("./known_hosts"); 

    Path privateKeyPath = Paths.get("./id_dsa");
    byte[] privateKey = Files.readAllBytes(privateKeyPath);

    Path publicKeyPath = Paths.get("./id_dsa.pub");
    byte[] publicKey = Files.readAllBytes(publicKeyPath);

    // Either of the lines below work... Why?
    // jsch.addIdentity("", privateKey, publicKey, null);
    // or 
    jsch.addIdentity("", privateKey, null, null);

    Session session = jsch.getSession("USER", "myHost.com", 22);

    session.connect();

  }
}

Setting publicKey to null, doesn't make a difference, I can connect either way. Why is that?

It looks like the publicKey isn't being used, so why pass it to addIdentity in the first place?

解决方案

It's an optimization for (some) encrypted private keys. You didn't notice any difference because you used unencrypted private keys.

If you give jsch an OpenSSL-format encrypted private key, and don't up-front provide the passphrase to decrypt it, but do provide the public key (which is never encrypted), and that keypair becomes the next choice for authentication, jsch probes the server using the publickey to determine if the server will possibly accept auth with this key. If so, jsch must prompt for the passphrase to decrypt the privatekey to actually perform authentication; if not, it skips the prompting and goes to the next possibility, if any. See the source for com.jcraft.jsch.UserAuthPublicKey.java.

The OpenSSH client ssh does almost the same thing. If you give it (as an option, in config or by default) an OpenSSL-format encrypted privatekey, and it finds a matching publickey, it probes first, and prompts for the passphrase to decrypt only if this key is usable. ssh does not allow specifying the passphrase in advance like Jsch.addIdentity, but it can use an ssh-agent process (or substitute) that accomplishes the same thing.

OpenSSH since 6.5 also supports 'new format' key files created with ssh-keygen -o which can have encrypted privatekey and unencrypted publickey in one file, avoiding handling publickey separately. Jsch does not (yet?) support this format, but it does support PuTTY's PPK format, which does the same thing, and thus for which you provide the single file as privatekey and no publickey.

这篇关于JSCH addIdentity公钥参数没有任何区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！