ssh2模块使用从CLI成功的信用卡静默失败

Question

I've successfully ssh 'd into Google Cloud Compute via CLI with a command like the following:

ssh -i ~/.ssh/my-ssh-key me@ipnumber

But using the ssh2 module isn't giving any output, including errors.

var fs = require('fs');
var Client = require('ssh2').Client;

var connSettings = {
  host: IP, // 'XXX.XXX.XXX.XX'
  port: PORT, // XXXX
  username: ME, 
  privateKey: privateKey, //fs.readFileSync(location, 'utf8')
  passphrase: passphrase,
  password: password
};

var conn = new Client();

conn.on('ready', function() { //first example in README
  console.log('Client :: ready');
  conn.exec('uptime', function(err, stream) {
    if (err) throw err; //nothing
    stream.on('close', function(code, signal) {
      console.log('Stream :: close :: code: ' + code + ', signal: ' + signal); //nothing
      conn.end();
    }).on('data', function(data) {
      console.log('STDOUT: ' + data); //nothing
    }).stderr.on('data', function(data) {
      console.log('STDERR: ' + data); //nothing
    });
  });
})
.on('error', function(err) {
  console.error('err', error); //nothing
})
.connect(connSettings);

I'm tailing /var/log/secure as I'm debugging the node script and I can see log entries when I ssh in and close the session from CLI, but nothing at all when I try through node ssh2 .

What could be causing this connection to fail silently?

Answer 1

UPDATE : I have it on good authority that your client would log the server ident string , and that is sent immediately upon connection. So if you don't see that information, it must be the case that the server is not sending anything . Now since you tried with CLI SSH and it works, once we exclude the impossible, the only remaining explanation, unlikely as it may seem, is that you are not connecting to the same server/port . For some reason, port 8080 on the destination server isn't running a SSH2 server.

One possible interpretation is this: the server is running something else on port 8080, that allows connection but doesn't send anything initially (eg a HTTP server). When you connect with the CLI SSH, you think that it is using port 8080, but for some reason that directive in the ssh_config file does not kick in, and the CLI SSH connects to the true SSH server, and works, while the node SSH connects to a different server, and that's why it does not work.

To check, try telnet'ting to port 8080 of that server and verify that it does respond with a SSH2 banner:

Connected to xxx.xxx.xxx.xxx port 22
Escape character is '^]'.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
^C
Connection closed by foreign host.

If it does not answer with the "SSH-..." banner, I think this demonstrates sufficiently that the CLI SSH is connecting elsewhere. Where? To discover this, run again the CLI SSH with debug:

ssh -vvv xxx.xxx.xxx.xxx ... 2>&1 | grep "Connecting to"

(You'll have to exit by hitting Ctrl-C). This should give you:

debug1: Connecting to whatever [xxx.xxx.xxx.xxx] port XYZK

And that xxx.xxx.xxx.xxx and XYZK values are the ones you'll need to pass to the node client.

PREVIOUS ANSWER

I am not familiar with nodejs 's SSH2, but I had a SSH2 library (closed source, at that) play this exact trick to me some months ago. "Connected..." followed by nothing .

It turned out that the client was using a cipher that the server did not support, and for some reason while this is shown by OpenSSH2's CLI client, the library chose not to display the error. It was quite messy to get to the bottom of things.

I see from the GitHub page that some ciphers require "node v0.11.12 or newer". Is this your case? If not, you may want to try updating node .

In any case I'd follow @AttRigh's suggestion and run a sshd on the server in debug mode. If you cannot:

• log the ssh2 CLI client's output in full debug mode and extract what cipher it uses,
• set up a sshd server with that cipher and no others,
• run your node client against that server.

Also, now that I come to think of it, you might set up a sshd server anyway with default settings, and ensure that you can connect to that . This would circumscribe somewhat the problem.