Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication exception when connecting to Fedora using private keys #834

Closed
david-haim-sentinelone opened this issue Jun 7, 2021 · 12 comments
Milestone

Comments

@david-haim-sentinelone
Copy link

Hi there
In my company we're using this library for our SSH communication with C#.
We found out that when trying to connect to fedora using private keys, a Renci.SshNet.Common.SshAuthenticationException is thrown.

To reproduce: set up a fedora machine with SSH enabled with a private key, for example, by following the tutorial here, make sure that everything was set up correctly by connecting using your terminal/power shell.

using this example code :

var key = "private key goes here";
var ms = new MemoryStream(Encoding.UTF8.GetBytes(key));

var connectionInfo = new ConnectionInfo(
	"ip goes here",
	"username goes here",
	new PrivateKeyAuthenticationMethod("username goes here", new PrivateKeyFile(ms)));
	
var sshClient = new SshClient(connectionInfo);
sshClient.Connect();

A Renci.SshNet.Common.SshAuthenticationException: Permission denied (publickey) exception is thrown.
From our small research, this doesn't happen with other unix-os (like ubuntu and cent-os) and doesn't happen when using a standalone implementation. like open-ssh. It happens only when the remote os is fedora and when trying to connect with a private key. Trying to connect to Fedora with a password also seem to work fine.

Thanks.

@semenenkov
Copy link

@david-haim-sentinelone I can't tell from the point of SSH.NET but recently I was fighting the same error in OpenSSH in Windows, and it was not the fault of SSH.NET.
I'd recomment you to check two things

  1. try to connect with any other SSH client, there is a big chance it will not work as well, and if so
  2. enable the most detailed logging on SSH server (on Windows OpenSSH it was DEBUG3) and check logs

@NN---
Copy link

NN--- commented Jun 13, 2021

Seems like it happens due to OpenSSH 8.5 change.
https://www.openssh.com/txt/release-8.5

Note that the deactivation of "ssh-rsa" signatures does not necessarily
require cessation of use for RSA keys. In the SSH protocol, keys may be
capable of signing using multiple algorithms. In particular, "ssh-rsa"
keys are capable of signing using "rsa-sha2-256" (RSA/SHA256),
"rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1). Only the last of
these is being turned off by default.

I do not see in the library code any mentioning to "rsa-sha2-512" or "rsa-sha2-256.

@NN---
Copy link

NN--- commented Jun 13, 2021

ssh -o HostKeyAlgorithms=ssh-rsa -o FingerprintHash=md5 -i id_rsa user@10.20.30.40
Unable to negotiate with 10.20.30.40 port 22: no matching host key type found. Their offer: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

@NN---
Copy link

NN--- commented Jul 7, 2021

#825

@hhyyrylainen
Copy link

hhyyrylainen commented Aug 15, 2021

I found that by creating an ed25519 key I can connect using this library to a Fedora 34 server.
(other possible key types don't seem to be loadable by SSH.NET: #728 (comment))
That's the only keytype that fedora seems to accept by default and is supported by this library.

@darinkes
Copy link
Collaborator

I found that by creating an ed25519 key I can connect using this library to a Fedora 34 server.
(other possible key types don't seem to be loadable by SSH.NET: #728 (comment))
That's the only keytype that fedora seems to accept by default and is supported by this library.

As mentioned over there (why spread assumptions everywhere?) your issue looks like unsupported usage of Mono instead of .NET. And has nothing todo with Fedora.

@hhyyrylainen
Copy link

hhyyrylainen commented Aug 16, 2021

This has to do with Fedora, I didn't include links before. But it seems like due to security concerns Fedora doesn't support ssh-rsa keys anymore, in the default configuration.
I found some links regarding that, but when I tried to get my server to accept ssh-rsa keys, I could not make it do so. That's why I commented to save other people's time that the easiest thing to do is to move to a key type that is supported by default on Fedora:

For me adding ssh-rsa to /etc/crypto-policies/back-ends/opensshserver.config didn't work. So I had to find a key type that is accepted by default.

@darinkes
Copy link
Collaborator

That's the only keytype that fedora seems to accept by default and is supported by this library.

Cause this statement is false, ECDsa should also work.
So let us figure out why your runtime throws NotImplementedException, before spreading over multiple issues. Ok?
Gets super confusing pretty fast and ppl will read your comments and think they have to use ed25519.

@hhyyrylainen
Copy link

Okay so it seems like Rider C# interactive doesn't use the same runtime as the project. So that's the problem I got there.
Seems like it is configurable, but on my system it has picked up a mono installation. It seems kind of hard to install dotnet interactive (instead of the mono version), so I'll skip that for now.
But I can report that when running with the net5.0 runtime loading a key made with:

$ ssh-keygen -t ecdsa -b 521 -m pem -f testkey

does in fact load (needs to be pem format, default format doesn't load).

@darinkes
Copy link
Collaborator

Ok, than I havent gone crazy. Thanks for the confirmitation!
Keeping track of all the Crypto-APIs and their state in various versions and runtimes is a tough subject.

Aye, PEM is required in the currently released nuget, but my #614 got merged.
So support for OpenSSH Keys with ECDSA 256/384/521 and RSA should come soon to nuget I think.

@WojciechNagorski
Copy link
Collaborator

Fixed by #1177 and #1180

@WojciechNagorski
Copy link
Collaborator

Version 2023.0.0 has been published https://www.nuget.org/packages/SSH.NET/2023.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants