Comment made by: manderson202
I ran into this issue as well and found the underlying cause before I found this workaround, so I thought I'd submit a patch. As alluded to in the gist, JSCH does not know about jsch-agent-proxy and so it attempts to resolve keys as it would normally. In normal execution it expects a UserInfo
implementation when it encounters an encrypted (password protected) private key. The code throws an Exception right off the bat if the UserInfo
implementation doesn't exist and doesn't give the jsch-agent-proxy a chance to pull the keys from the ssh-agent. Below snippet from com.jcraft.jsch.UserAuthPublicKey#start
lines 118-130:
`
java
if((identity.isEncrypted() && passphrase==null)){
if(userinfo==null) throw new JSchException("USERAUTH fail");
if(identity.isEncrypted() &&
!userinfo.promptPassphrase("Passphrase for "+identity.getName())){
throw new JSchAuthCancelException("publickey");
//throw new JSchException("USERAUTH cancel");
//break;
}
String _passphrase=userinfo.getPassphrase();
if(_passphrase!=null){
passphrase=Util.str2byte(_passphrase);
}
}
`
The fix is to set a placeholder UserInfo
implementation on the Session
so that the above Exception isn't thrown and the ssh-agent can handle returning the keys to JSCH. With the patch, there is no need to perform the workaround of removing the IdentityFile
property from your ~/.ssh/config
file.
The patch is attached (today: 2018-11-27) and is called tdeps-49-fix.patch
. Let me know if you have questions.