2016-04-27 19 views
0

Ich versuche eine Objective-Git/libgit2 App über SSH mit einem entfernten mscdex Node ssh2 Server zu verbinden, unter Verwendung von Schlüsselpaaren.Node ssh2 Server akzeptiert keine Objective-Git/libgit2 SSH Verbindung

Die libgit2 App kann sich mit sshd auf dem Server verbinden und Push implementieren. Es implementiert libgit2 git_cred_ssh_key_new und dann git_remote_connect.

Wenn jedoch die Anwendung auf den ssh2 Server zu verbinden versucht, übernimmt der Server den Dienst ssh-userauth, aber im Dienst ssh-connection Verfahren Typ ist ‚kein‘, und nicht ‚publickey‘.

Alternativ, wenn ich eine Verbindung zum ssh2-Server mit Git (anstelle der App über libgit2), akzeptiert der ssh2-Server den Dienst ssh-connection und implementiert den Methodentyp 'publickey'.

Also ich bin mir nicht sicher, wo das Problem liegt: in der libgit2-Implementierung des "publickey" -Methodentyps, oder der ssh2-Server fällt durch zum Methodentyp "none".

Alle Hinweise oder Hilfe wird sehr geschätzt. Vielen Dank.

SSH2-Server (zB Server):

new ssh2.Server({ 
    hostKeys: [fs.readFileSync('/Users/almccann/Sites/thenewpop/ssh2server/host_rsa')], 
    debug: function (cfg) { 
    console.log('debug', cfg); 
    } 
}, function(client) { 
    console.log('Client connected!'); 
    client.on('authentication', function(ctx) { 
    // ctx.method === 'none', no ctx.key 
    if (ctx.method === 'publickey' 
     && ctx.key.algo === pubKey.fulltype 
     && buffersEqual(ctx.key.data, pubKey.public)) { 
     if (ctx.signature) { 
     var verifier = crypto.createVerify(ctx.sigAlgo); 
     verifier.update(ctx.blob); 
     if (verifier.verify(pubKey.publicOrig, ctx.signature)) 
      ctx.accept(); 
     else 
      ctx.reject(); 
     } else { 
     ctx.accept(); 
     } 
    } else 
     ctx.reject(); 
    }).on('ready', function() { 
    console.log('Client authenticated!'); 
    }).on('end', function() { 
    console.log('Client disconnected'); 
    }); 
}) 
.listen(22, '127.0.0.1', function() { 
    console.log('Listening on port ' + this.address().port); 
}); 
+0

Sie wahrscheinlich einen entsprechenden Code zeigen sollte, anderen helfen zu verstehen, was du redest. – mscdex

+0

@mscdex siehe Codebeispiele, obwohl dies auf Framework-/Bibliotheksebene problematisch zu sein scheint. – almccann

Antwort

1

Die none Authentifizierungsmethode ist im Grunde, was es klingt, es ist nur eine Authentifizierungsmethode, die ohne die Bereitstellung jede Art von Anmeldeinformationen oder andere Informationen, die Kunden Zugriff auf den Server erlaubt . Deshalb gibt es in diesem Fall keine ctx.key.

Die meisten Server werden beim Zurückweisen einer Authentifizierungsmethode gültige Authentifizierungsmethoden an den Client zurückgeben, dies ist jedoch nicht erforderlich (obwohl einige Clients sich speziell darauf verlassen, was eigentlich eine schlechte Sache ist). Unter der Annahme, der SSH-Client ist diese Liste erwarten, können Sie etwas tun, um zu signalisieren Sie akzeptieren nur publickey Authentifizierung:

client.on('authentication', function(ctx) { 
    if (ctx.method === 'publickey' 
     && ctx.key.algo === pubKey.fulltype 
     && buffersEqual(ctx.key.data, pubKey.public)) { 
    if (ctx.signature) { 
     var verifier = crypto.createVerify(ctx.sigAlgo); 
     verifier.update(ctx.blob); 
     if (verifier.verify(pubKey.publicOrig, ctx.signature)) 
     ctx.accept(); 
     else 
     ctx.reject(); 
    } else { 
     ctx.accept(); 
    } 
    } else 
    ctx.reject(['publickey']); // <============== 
}); 
+0

Okay, super danke @mscdex. Das ist interessant, dass Sie die Liste der akzeptierten Methoden zur Ablehnung übergeben. Bei der Methode 'none'-Status fragt der Client den Server effektiv ab, um zu sehen, welche Methoden akzeptiert werden. Unter der Annahme, dass der Server den Fall 'none' behandelt hat, würde er dann zum Typ mit der höchsten Priorität wechseln, der" publickey "sein könnte. – almccann

+0

Ja, wenn die meisten Clients "none" anfordern, tun sie dies aus zwei Gründen: um automatisch mit dem geringsten Aufwand authentifiziert zu werden (was aus Sicherheitsgründen unwahrscheinlich ist) und um herauszufinden, welche "tatsächlichen" Methoden der Server den Clients erlaubt mit etwas fortfahren. Es gibt keine definierte/standardisierte Reihenfolge für die Methoden, aber ich würde annehmen, dass die meisten Clients, die diese Methodenlisten verwenden, normalerweise von links nach rechts starten. – mscdex