publickey auth fails in ssh2, but works from command line #989
Comments
No. Out of curiosity, can you try with the current master branch? I'm wondering if the rewrite has helped any. |
|
@mscdex Yes, pardon my ignorance, but how do I use the latest off master? Tried cloning locally and then using |
|
@mscdex Sorry, ignore the previous log, I was confused. I installed the latest off master and am seeing the same behavior. |
|
Are you able to create a new and unused key of the same type that exhibits the same behavior that you could send/post? I can try to duplicate the issue on my end. |
|
Yes, I created a new keypair with Here is the new private key. Here is the log, but I think it's identical to above. |
|
In your package.json file, change the entry for ssh2 in the dependencies
list to use a git URL instead of a version number e.g.
"ssh2": "github:mscdex/ssh2"
See the npm man page for details on using git and github urls.
|
|
I have the same issue, switching to master did not help |
|
Something I just noticed @wcarhart is that with the OpenSSH client you're connecting to a different server because the server ident is different. With your OpenSSH client connection the server ident is "OpenSSH_8.2p1 Ubuntu-4ubuntu0.1" but with your |
|
Chiming in, I'm also on mac and having the same problem but then realized i was passing the wrong values from my .env after console logging the config just before trying to connect. |
|
Getting a similar issue, running latest both master of ssh2 and the latest release: When I pass username, privateKey, host, and port as config options. I'm able to ssh in with the same private key though using I see it show up in server logs but I'm not sure what's going wrong/why it's failing to connect using the same user/privatekey |
|
I just noticed: And it does look like Fedora did indeed deprecate this key type. But I'm confused because regular |
|
@eatonphil I probably should add key hash values to debug output like OpenSSH does to catch these issues more easily. |
|
No I believe it's that this library is "labeling" my key as ssh-rsa whereas the open ssh client is "labeling" it as rsa-sha2-512. Since fedora deprecated ssh-rsa I can't use this library to connect even though I can connect with the openssh client (that labels the same key differently). Does that make sense? |
|
It's the same key type, the only difference is the hashing algorithm. OpenSSH uses a custom/non-standard message type to indicate the supported key algorithms for authentication, which I guess we could add support for if OpenSSH is reported in the remote party's identification. That won't help any other server implementations though that happen to disable support for select algorithms. |
|
As ssh2-sftp-client is really just a simple wrapper around ssh2, it is
unlikely it has any impact in this area, but of course cannot be
eliminated and should be considered/verified.
In the ssh2-sftp-client repository, there is a 'validation' directory
which contains some very basic scripts which perform simple sftp
operations and which only use ssh2. These scripts are there for
precisely this reason i.e. to verify an issue can be reproduced using
just ssh2 and eliminate ssh2-sftp-client layer as a contributing factor.
If the issue does not occur using these scripts, then the issue should
probably be reported with the ssh2-sftp-client project.
|
|
I have the same issue when using the ssh2 library directly.
It sounds like I'm making a feature request then |
As I was working on adding support for this, I discovered that OpenSSH does not filter the list of signature algorithms according to the server's configured The RFCs mention that if the server doesn't send a signature algorithm list or doesn't support the extension negotiation mechanism at all, to possibly use trial and error, however as the RFC also notes, some server implementations can penalize you for such things. So unfortunately there's not really anything I can do right now. |
|
I'm having the same issue. This will happen when trying to connect to any server with a recent version of openssh (with default settings) and so it will become more and more urgent as it's not just a fedora deprecation but an openssh one. Arch Linux is also shipping this version of openssh. |
|
Same problem on my side with Arch Linux. I have been running unit tests on arch for years with nikita. The majority of the tests run with a local SSH connection. Lately, I trash all my docker images and couldn't run the tests which were using an Arch Linux image while the docker run -it --rm archlinux:latest /bin/bash
pacman --noconfirm -Syu
pacman --noconfirm -S openssh nodejs npm
ssh -V | grep 'OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021'
cd /root/
/usr/bin/ssh-keygen -A
ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys
/usr/sbin/sshd
ssh [email protected] whoami | grep root
mkdir test
npm init -y
npm install ssh2
cat <<JS >test.js
const { readFileSync } = require('fs');
const { Client } = require('ssh2');
const conn = new Client();
conn.on('ready', () => {
console.log('Client :: ready');
conn.shell((err, stream) => {
if (err) throw err;
stream.on('close', () => {
console.log('Stream :: close');
conn.end();
}).on('data', (data) => {
console.log('OUTPUT: ' + data);
});
stream.end('ls -l\nexit\n');
});
}).connect({
host: '127.0.0.1',
port: 22,
username: 'root',
privateKey: readFileSync('/root/.ssh/id_rsa'),
debug: (s) => {console.log(s)}
});
JS
node test.jsOutput is: Note, it works with an older version of Arch, eg |
|
@mscdex
So we'd need a configuration option similar to |
|
I guess this in relation to this: https://www.reddit.com/r/linuxquestions/comments/qgmnnh/ssh_key_no_mutual_signature_algorithm/ Meaning right now I'll have to tell affected users (using Arch) to use an ed25519 key or explicitly enable |
|
I also got bitten by this. |
|
I didn't go into the code in detail, I believe the issue is, in the beginning of the ssh session there is a handshake about the capabilities, and right now with this library they agree to not use rsa signatures. The funny thing with current/some openssh client is, they ignore the handshake and ask the server the rsa key signature anyway.. and then the server says, yes well actually it's fine.. while some newer versions respect the handshake and wont try it, unless you config them to. So what I believe needs fixing is the handshake. |
|
I have same problem with privateKey |
|
It works for me in the way: |
|
That doesn't work for me. I also have some python code connecting to the same devices using Paramiko, and I also needed to update it to the latest version to get it going. After some debugging there, it seems paramiko is effectively re-encrypting the public key using rsa-sha2-512 before sending it |
I our case, adding |
|
@axkibe : I had the issue using it the other way round: ssh2 as client, embedded linux device as server. |
|
I had some time to take a crack at this and decided to mostly go with how the OpenSSH client does things, with the exception being that the sha1-based RSA offer will be sent if the server does not send a For If anyone wants to give it a try, feel free to checkout the ext_info branch and let me know how it works for you. |
|
@mscdex This branch works for me. |
|
@mscdex a member on our team (@bryan-hunter) tried your branch and it solved our issue. Thanks! |
|
@mscdex THANKS SO MUCH FOR THIS (it works a treat) |
|
Doesn't seem to help in my case... |
|
Can also confirm that the ext_info branch works for me locally. |
- temporarily switch ssh2 version due to mscdex/ssh2#989
|
@jmichiel I'm not able to reproduce the issue using OpenSSH 8.8p1 for the server and the current Are you sure you're using the right branch? If so, is it possible you could share the OpenSSH 8.8p1 server config that causes the |
|
@mscdex Strange, I'll investigate further! EDIT: |
|
Seems like I'm still on the master branch, despite having |
|
npm can be b**.. when having git repositories as dependencies, rm -rf node_modules and package-lock.json and npm install again. |
|
It works ! Thank you |
|
@jmichiel That's basically the same server configuration I was testing with. Are you saying that it's working for you now after ensuring the correct branch was being pulled in? |
|
@mscdex : No, didn't get that far: after deleting package-lock.json I got into dependency hell and haven't solved it yet. Will be for monday... |
* google cloud driver - wip - temporarily switch ssh2 version due to mscdex/ssh2#989 * some fixes * more fixes - rsync permissions - wip - gce calls retry - async trace - remove redundant lines * even more fixes - run rsync with sudo to prevent permission errors from container-generated files - add wait flag to machine deletion - convert gce instance name to be dynamic to prevent collisions with machines being deleted - cap instance name length to google provided max * add google cloud storage profile storage * cosmetics, remove extractFirst * update docs * update package version. set ssh2 to a fixed revision * updated generated readme --------- Co-authored-by: Yshay Yaacobi <[email protected]>
|
So I finally got out of dependency hell and I can now confirm that the |
and others
I am try to connect to a DigitalOcean droplet with ssh2.
Here's my code:
ssh2 fails with the following log:
And here's what
ssh -vvv [email protected] echo helloshows me:Is there another argument in
connect()that I need to include?The text was updated successfully, but these errors were encountered: