“Auth échouer” dans jsch-0.1.42 avec Java 1.4.2

J'ai ce simple programme Java qui utilise Jsch pour se connecter à un serveur SFTP.

La connexion échoue avec un "Auth échec" d'exception sur l'île de Java 1.4.2, mais il se connecte parfaitement sur Java 1.7.

try {
    JSch jsch = new JSch();

    jsch.setKnownHosts(KNOWN_HOSTS_PATH);
    jsch.addIdentity(PRIVATE_KEY_PATH, PASSPHRASE);

    Session session = jsch.getSession(USERNAME, HOSTNAME, 22);
    session.connect(2500);

    Channel channel = session.openChannel("shell");
    channel.setInputStream(System. in );
    channel.setOutputStream(System.out);
    channel.connect();
} catch (Exception e) {
    e.printStackTrace(System.err);
}

La clé que j'utilise est une ssh-rsa 4096 bits de la clé. Le .pub fichier de clé existe dans le même répertoire que la clé privée.

Lors de la connexion d'un enregistreur, je vois le message suivant avant de l'exception (qui se produit sur channel.connect();):

INFO: Connexion <rédigé> le port 22 
INFO: Connexion établie 
INFO: version à Distance de la chaîne: SSH-2.0-OpenSSH_5.1p1 Debian-5 
INFO: la version Locale de la chaîne: SSH-2.0-JSCH-0.1.42 
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256 
INFO: arcfour n'est pas disponible. 
INFO: arcfour128 n'est pas disponible. 
INFO: arcfour256 n'est pas disponible. 
INFO: SSH_MSG_KEXINIT envoyé 
INFO: SSH_MSG_KEXINIT reçu 
INFO: kex: serveur->client aes128-ctr hmac-md5 aucun 
INFO: kex: client->serveur aes128-ctr hmac-md5 aucun 
INFO: SSH_MSG_KEXDH_INIT envoyé 
INFO: attend SSH_MSG_KEXDH_REPLY 
INFO: ssh_rsa_verify: signature vrai 
INFO: Accueil " <rédigé>' est connu et mathces le RSA clé d'hôte 
INFO: SSH_MSG_NEWKEYS envoyé 
INFO: SSH_MSG_NEWKEYS reçu 
INFO: SSH_MSG_SERVICE_REQUEST envoyé 
INFO: SSH_MSG_SERVICE_ACCEPT reçu 
INFO: les Authentifications qui peut continuer: publickey,clavier interactif,le mot de passe 
INFO: Suivant la méthode d'authentification: publickey 
INFO: les Authentifications qui peut continuer: mot de passe 
INFO: Suivant la méthode d'authentification: mot de passe 
INFO: Déconnexion <rédigé> le port 22 
com.jcraft.jsch.JSchException: Auth échouer 
au com.jcraft.jsch.Session.connexion(Session.java:452) 
au TestJsch.principale(TestJsch.java:19)

Lorsque j'exécute le même programme avec Java 1.7, il est dit

INFO: Connexion <rédigé> le port 22 
INFO: Connexion établie 
INFO: version à Distance de la chaîne: SSH-2.0-OpenSSH_5.1p1 Debian-5 
INFO: la version Locale de la chaîne: SSH-2.0-JSCH-0.1.42 
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256 
INFO: SSH_MSG_KEXINIT envoyé 
INFO: SSH_MSG_KEXINIT reçu 
INFO: kex: serveur->client aes128-ctr hmac-md5 aucun 
INFO: kex: client->serveur aes128-ctr hmac-md5 aucun 
INFO: SSH_MSG_KEXDH_INIT envoyé 
INFO: attend SSH_MSG_KEXDH_REPLY 
INFO: ssh_rsa_verify: signature vrai 
INFO: Accueil " <rédigé>' est connu et mathces le RSA clé d'hôte 
INFO: SSH_MSG_NEWKEYS envoyé 
INFO: SSH_MSG_NEWKEYS reçu 
INFO: SSH_MSG_SERVICE_REQUEST envoyé 
INFO: SSH_MSG_SERVICE_ACCEPT receivedINFO: les Authentifications qui peut continuer: publickey,clavier interactif,le mot de passe 
INFO: Suivant la méthode d'authentification: publickey 
INFO: l'Authentification a réussi (publickey). 
Linux <rédigé> 2.6.26-2-amd64 #1 SMP Mon Jun 13 16:29:33 UTC 2011 x86_64 

<server message de bienvenue suit>

J'ai installé le Java Cryptography Extension (JCE) de la VM 1.4.

Ce qui pourrait être la source de ce problème?

  • avez-vous remarqué qu'il saute le publickey authentification et va tout de suite le mot de passe auth? : Les authentifications qui peut continuer: mot de passe
  • Oui, je l'ai fait. Je n'ai pas d'explication, autre que l'hypothèse qu'une partie de la clé d'authentification échoue silencieusement (par exemple parce que la clé est trop long ou une condition préalable n'a pas été respecté) et il saute à la prochaine méthode sans l'émission d'un avertissement. "Java 1.4 ne prend pas en charge 4096 bits clés car XYZ" est la réponse, je serais prêt à accepter (même si je ne peux vraiment pas imaginer maintenant que cela pourrait être vrai).
  • En regardant les UserAuthPublicKey.java de JSch, il semble que ce processus n'a vraiment émettent que peu de renseignements utiles. Je suggère la compilation JSch à partir de la source, et en ajoutant plus de la sortie de la classe, de sorte que vous ayez une idée de ce qui se passe, où les choses ne.
  • Je pourrais le faire,mais de creuser dans une bibliothèque je sais à côté-à-rien à ce sujet n'a pas vraiment d'attrait pour moi. :/ J'ai vu l'auteur de Jsch autour DONC, j'espérais qu'il allait venir.
  • La recherche sur les JSch source, UserAuthPublicKey.java et IdentityFile.java déjà, comprennent un certain nombre de commenté System.err.println() des niveaux de débogage, alors peut-être tout simplement ré-activation de ceux qui seraient assez pour faire la lumière sur pourquoi (ou au moins où) les choses ne sont pas.
  • Oui, je pense que c'est ce que j'ai à faire. Dommage que je n'obtiendrez pas mon +100 butin si je réponds à ma propre question. 🙂
  • Oui, mais ne vous inquiétez pas. Je suis sûr que si vous appliquez vous-même, alors peut-être qu'un jour, dans un avenir lointain, vous aurez réussi à gagner le plus de ce retour et peut mettre une prime sur une autre question. 🙂
  • En regardant le code source (docjar.com/html/api/com/jcraft/jsch/UserAuthPublicKey.java.html, la ligne 122), il semble qu'il vient de identity.isEncrypted() qui renvoie la valeur true. Par la recherche de l'identité var (constructeur de docjar.com/html/api/com/jcraft/jsch/IdentityFile.java.html), la encrypted est pas défini à false, alors que vous l'avez déjà fait, je soupçonne aussi que le JDK 1.4 ne manipulez pas votre clé RSA.

InformationsquelleAutor Tomalak | 2012-07-10
  1. 4

    Java a une limitation pour l'utilisation de fortes algorithme de chiffrement. Vérifier le contenu de $JRE_HOME/lib/security/US_Export_policy.jar et $JRE_HOME/lib/security/local_policy.jar. Si vous trouvez quelque chose comme ceci:

    //File: default_local.policy
//Some countries have import limits on crypto strength.
//This policy file is worldwide importable.
grant {
    permission javax.crypto.CryptoPermission "DES", 64;
    permission javax.crypto.CryptoPermission "DESede", *;
    permission javax.crypto.CryptoPermission "RC2", 128,
                   "javax.crypto.spec.RC2ParameterSpec", 128;
    permission javax.crypto.CryptoPermission "RC4", 128;
    permission javax.crypto.CryptoPermission "RC5", 128,
          "javax.crypto.spec.RC5ParameterSpec", *, 12, *;
    permission javax.crypto.CryptoPermission "RSA", 2048;
    permission javax.crypto.CryptoPermission *, 128;
};

    Décision est de télécharger et d'installer JCE Force Illimitée de la Compétence Politique. Auparavant, il était situé sur les Chaises du site, maintenant je ne sais pas où il peut être trouvé.

    Vous pouvez en lire plus dans cet article

    EDIT:
    Après quelques recherches, j'ai trouvé ma réponse était incorrecte.

    Java 1.4 ne prend pas en charge les clés RSA de plus de 2048 octets de longueur BUG 4524097

    • J' pour installé la JCE Force Illimitée de la Compétence Politique. Si vous regardez à nouveau à ma question, vous constaterez que j'ai dit ça.
    • désolé, regardez sur votre question et de voir que le "Java Cryptography Extension (JCE)", ce qui n'est pas le même que "la JCE Force Illimitée de la Compétence Politique de la" pour moi.
    • Bon, alors je n'ai pas été assez clair (le Sun/Oracle terminologie pour ce non-sens est source de confusion). J'ai installé ceci: Java Cryptography Extension (JCE) Force Illimitée de la Compétence de la Politique de Fichiers 1.4.2. Je suis aussi assez sûr il n'y a pas d'autre fichier avec un nom semblable, mais un effet différent.
    • Hm. Pour permettre la cryptographie forte dans la version 1.4, vous avez besoin de deux paquets: JCE - il est forfait optionnel (non livré par défaut) avec des implémentations d'algorithmes, ce qui donne capacité de l'utilisation de la cryptographie, et JCE Illimité Politique, ce que la suppression des restrictions pour certains de l'algorithme, comme le RSA avec une clé de 4096. Êtes-vous shure vous avez tous les deux installés? Je trouve que vous avez installé JCE, parce que si elle n'est pas, vous ne pouvez pas utiliser criptography à tous, mais ont manqué de la JCE de la Politique.
    • Bon, alors nous allons le faire dans l'autre sens. Pouvez-vous faire une simple liste définitive des fichiers que je dois installer et les endroits où je dois les installer?
    • d'abord: Java Cryptography Extension (JCE) 1.2.2 et la deuxième: Java Cryptography Extension (JCE) Force Illimitée de la Compétence de la Politique de Fichiers 1.4.2. Télécharger à partir de oracle.com/technetwork/java/javasebusiness/downloads/..., décompressez-le et suivez les instructions dans INSTALL.html et Readme.txt.
    • Alors même si je suis assez sûr que c'est inutile, j'ai maintenant installé le jce1_2_2.jar fichier à la jre/lib/ext répertoire de la machine virtuelle Java et fait en sorte que la stratégie de sécurité locale permet l'accès à ce fichier. Je pense que c'était inutile puisque sunjce_provider.jar existait déjà et apparemment contient les algorithmes de chiffrement, afin de Java 1.4 il n'est pas nécessaire d'installer une bibliothèque. Comme prévu, l'ajout de la JCE 1.2 bibliothèque trouvai rien. L'erreur est toujours là.
    • peut-être que mon anglais n'est pas parfait, je ne suis pas un locuteur natif. Vous ne comprenez pas ce que j'essaie de dire, et je ne sais pas comment le dire en des termes différents. Désolé pour perdre votre temps. Bye.
    • Il n'y a rien de mal avec votre anglais (pourquoi pensez-vous cela?). Je ne suis pas un locuteur natif de moi-même. J'ai juste essayé d'être aussi précis que possible sur ce que j'ai fait et à propos de mon raisonnement. Je n'ai pas l'intention de son agacé/irritée. Désolé si j'ai fait cette impression.
    • ok, après quelques recherches, j'ai trouvé cela, c'est un bug, et il a été résolu qu'en java 5. Ma réponse précédente n'était pas éligible pour ce cas particulier. bugs.sun.com/bugdatabase/view_bug.do?bug_id=4524097. Mise à jour de réponse.
    • C'est fantastique d'Info. Merci pour creuser ça. 🙂 Je vais configurer un bounty sur la question et d'accepter votre réponse dès qu'il est techniquement possible de le faire.
    • au-user1516873 veux Juste ajouter que c'est une bonne recherche ... même après plus de 2 ans, j'ai creusé ce jusqu'à résoudre mon problème spécifique. Je suis également heureux de voir qu'il y a un grand respect et de la patience. (désolé pour ce moi -, mais pensé qu'il a eu lieu ici, dans ce cas).

    InformationsquelleAutor user1516873
  2. 3

    Mes problèmes avec jsch ont été autour des autorisations. Je voudrais donc prendre les mesures suivantes pour les éliminer comme des problèmes

    1. Assurez-vous que vous pouvez ssh à distance sur la ligne de commande à l'aide de la
      des clés générées.
    2. Passer le mot de passe et assurez-vous que vous pouvez obtenir une connexion à la télécommande.
    3. Vérifiez les autorisations sur le répertoire local et sur la distance bon ssh résumé.
    4. Essayez d'utiliser l'hôte local comme à distance.

    À défaut de télécharger le code source et l'étape s'il en une session de débogage.

    • Les Points 1 à 3 sont couverts par le fait que la connexion avec Java 1.7 œuvres. Je suis en utilisant le même .class fichier dans une autre VM. Strictement parlant, cela rend le point 4 obsolètes ainsi.
    • savez-vous quelle erreur, il est à jeter? si c'est un JSchException -- l'attraper directement et imprimer la chaîne peut être instructif. (même avec le JSchPartialAuthException).
    • Répondre à cette question, dans le premier des deux documents imprimés dans ma réponse. Mais si vous pensez à l'attraper directement qui fera toute la différence, je vais le faire demain.
    • la dernière fois que j'ai travaillé avec cette bibliothèque normalement imprimer des codes d'erreur qui pourrait être adressés directement à des problèmes. Mais je ne l'ai compris quand j'ai téléchargé la source et renforcé à travers elle. si vous avez un coup d'oeil dans Session.java vous verrez ce que je veux dire (j'ai été à la recherche à la version de 0,148). l'ajout d'une impression pour l'e.getMessage() je pense peut faire la même chose. Le truc, c'est que j'aurais besoin de l'erreur plutôt que de le enveloppés trace de la pile avant que je puisse vraiment ajouter de la valeur. bonne chance
    • Ouais, je l'avais espéré pour l'éviter. Peut-être que je viens d'utiliser un shell appel à une ligne de commande exécutable et être fait avec elle. Dépend si ma curiosité obtient le meilleur de moi. Ce n'est pas une question de vie ou de mort dans ce cas.
    InformationsquelleAutor shainnif
  3. 1

    Avez-vous essayé d'utiliser une ouverture de clé SSH? jsch utilise Open SSH les principaux formats. Vous pouvez convertir votre existant à un Open SSH format. C'est comment: Utiliser de mastic keygen et charger votre clé existante. Vous pouvez être invité à entrer votre mot de passe pour le décrypter. Après cela, cliquez sur les conversions option ci-dessus et choisissez la fonction "Exporter OpenSSH Clé". Utilisez cette nouvelle clé générée dans votre programme ci-dessus. Espérons que cette aide.

    • Si il y a quelque chose de mal avec la clé de format de fichier, il ne fonctionnera pas sur Java 1.7.
    InformationsquelleAutor Horse Voice
  4. -2

    Ce code fonctionne très bien...

    public class Exec2 {
static String SSH_SERVER_PATH = "localhost";
static String SSH_SERVER_USERNAME = "root";
static String SSH_SERVER_PASSWORD = "root";
public static void main(String[] arg) {
try {
JSch jsch = new JSch();
String host = SSH_SERVER_PATH;
String user = SSH_SERVER_USERNAME;
Session session = jsch.getSession(user, host, 22);
//username and password will be given via UserInfo interface.
UserInfo ui = new MyUserInfo();
session.setUserInfo(ui);
session.connect();
String command = "uname";
Channel channel = session.openChannel("exec");
((ChannelExec) channel).setCommand(command);
channel.setInputStream(null);
((ChannelExec) channel).setErrStream(System.err);
InputStream in = channel.getInputStream();
channel.connect();
byte[] tmp = new byte[1024];
while (true) {
while (in.available() > 0) {
int i = in.read(tmp, 0, 1024);
if (i < 0)
break;
System.out.print(new String(tmp, 0, i));
}
if (channel.isClosed()) {
System.out.println("exit-status: " + channel.getExitStatus());
break;
}
try {
Thread.sleep(1000);
} catch (Exception ee) {
}
}
channel.disconnect();
session.disconnect();
} catch (Exception e) {
System.out.println(e);
}
}
public static class MyUserInfo implements UserInfo, UIKeyboardInteractive {
String passwd;
public String getPassword() {
return passwd;
}
public boolean promptYesNo(String str) {
return true;
}
public String getPassphrase() {
return null;
}
public boolean promptPassphrase(String message) {
return true;
}
public boolean promptPassword(String message) {
passwd = SSH_SERVER_PASSWORD;
return true;
}
public void showMessage(String message) {
System.out.println("message = " + message);
}
public String[] promptKeyboardInteractive(String destination,
String name, String instruction, String[] prompt, boolean[] echo) {
if (prompt[0].equals("Password: ")){
String[] response = new String[1];
response[0] = SSH_SERVER_PASSWORD;
return response;
}
return null;
}
}
}
    InformationsquelleAutor murat
  5. -3

    public String getPassphrase() {
    return null;
    }

    public boolean promptPassphrase(String message) {
return true;
}
public boolean promptPassword(String message) {
passwd = SSH_SERVER_PASSWORD;
return true;
}
public void showMessage(String message) {
System.out.println("message = " + message);
    InformationsquelleAutor user3078759