Solved Can't configure SSH server to use key-based authentication

Х

Харбин Хэйлунцзян

On my Windows notebook I've generated an RSA key pair and put the public key on the FreeBSD computer in

/home/sergei/.ssh/authorized_keys

In sshd_config uncommented

PubkeyAuthentication yes

Reloaded the service. Still when I connect from the notebook it demands the password for sergei@s15.

In sshd_config uncommented

PasswordAuthentication no

Reloaded the service. And again it requests the password.

Restarted FreeBSD. The same thing.
 
If you're using the ssh cli client on windows, try 'ssh -v' (or -vv for more detail) to get some debug trace on the conversation with the server. If you're using putty I imagine there is a similar way to get trace of the conversation between client and server.
 
blackbird9 said:
try 'ssh -v'
Click to expand...

Quite a screed, but I guess the gist is at the end:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\s2047/.ssh/id_rsa RSA SHA256:Zv7zm/xzb3FhPPQxNLwTpdb87Nl/UEUnh9InD+0hdXo
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_ecdsa_sk
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_ed25519_sk
debug1: Trying private key: C:\\Users\\s2047/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
(sergei@192.168.1.15) Password for sergei@s15:
 
Do you have any other pubkeys for your user on the sesrver that work or is this the only one?
On my FreeBSD and Linux systems there is a utility named ssh-copy-id that is typically used to copy the key from one system to another:
ssh-copy-id -i ~/.ssh/id_rsa.pub username@remotehost

As for ownership of the authorized_keys file it should be:
-rw------- for the user:group on the remote system (FreeBSD in this case I think)

And you've verified on the server side it will accept/is configured for SHA256?
 
Харбин Хэйлунцзян said:
I thought it was a directory. Created it and put the copy of the public key file into it. :)

Ok. Now it accepts the key. Still it shouldn't suggest the password authentication when configured not to.

Thanks to everyone who responded.
Click to expand...
Well done, we've all been there, one way or another! :)

I usually do a sequence something like this:-

On the client:-
ssh-keygen -t rsa
scp ./.ssh/id_rsa.pub user@remotehost: # using password auth
ssh user@remotehost # using password auth
cat id-rsa.pub >> .ssh/authorised_keys

Or use the 'ssh-copy-id' program that mer mentioned above.

Then enable pubkey authentication and disable password authentication in sshd_config, restart sshd, and test ssh to the server from the client again. For bonus points use ssh -v to confirm that it used pubkey authentication (not usually necessary).

Of course authorised_keys can be manually edited with your favourite editor to remove old stale keys, etc.
 
blackbird9 said:
Well done, we've all been there, one way or another!
Click to expand...
Yes we have :) The thing that usually bites everyone is the actual permissions on the files. By design, they are tight. Basically only owner permissions.
The ssh-copy-id program does a lot of checks for you which is why I tend to use it. I'm not sure if it's available for Windows clients (I do almost nothing in Windows), if not your method of scp works fine.
 
SSH server is configured by default. It is important that .ssh folder is owned by the same user which will connect and chmod privileges are 700. File authorized_keys is the same with 600 access. You can use PuTTY keygen (puttygen.exe) to generate key pair. When finished, copy the key from window (starting with "ssh-rsa ") and paste 1 line in authorized_keys file.
 
OK, now to your second question OP. You said that password authentication still works, even after setting
PasswordAuthentication no
PermitEmptyPasswords no
... in /etc/ssh/sshd_config on the ssh server, and restarting sshd.

To test if that is still happening, you can temporarily disable the (now working) public key authentication by doing the following on the client.
$ cd .ssh
$ mv id_rsa id_rsa.bak

Now when you try to ssh from client to server, the client will have no private key to use, and pubkey authentication will fail. What you SHOULD see if you have correctly disabled password authentication on the server is output like this:-

$ ssh user@remotehost
user@client: Permission denied (publickey).

Meaning that pub key authentication has failed, no more auth methods are available and permission to make the connection has been denied.

However if the ssh client is still asking you for a password at that point, then you need to double check that you have disabled password authentication on the server, and restarted sshd there.

Of course after doing this experiment you will want to change the name of id_rsa.bak back to id_rsa so that pubkey authentication starts working again!
 
Ehm, the commented settings in /etc/ssh/sshd_config are the defaults. Removing the # doesn't change anything.

PasswordAuthentication no is the default:
Code: 
     PasswordAuthentication
             Specifies whether password authentication is allowed.  Note that
             passwords may also be accepted via KbdInteractiveAuthentication.
             See also UsePAM.  The default is no.

Same for PermitEmptyPasswords no
Code: 
     PermitEmptyPasswords
             When password authentication is allowed, it specifies whether the
             server allows login to accounts with empty password strings.  The
             default is no.
sshd_config(5)
 
Hmm something at the back of my mind made me do a double take. I checked the manpage on my debian 12 box.

man sshd_config ....

PasswordAuthentication
Specifies whether password authentication is allowed. The default is yes.

Now, that's just mean!

Checked the web to verify

Which is the opposite of the freebsd default.

sshd_config(5)

man.freebsd.org man.freebsd.org

How interesting. I've been in the habit for many years of explicitly setting it to 'no' on all machines, regardless of operating system, rather than using the default, and forgotton why. Perhaps I've just re-discovered why.

So yes, as SirDice said earlier:-
"You don't need to change anything in sshd_config, the default configuration already accepts keys."
 
I think RSA at this point specifies an algorithm to use, I also think it's been around long enough that any patents have expired. I've got an OReilly book on my shelf about PGP copyright 1995, so at this point almost 30 years old. The book talks about RSA as an algorithm. Why is this important? Typical lifetime of a patent in the US is around 17 years I think.

So just because one generates a key on their local system using an RSA algorithm, does not connect them to RSA "the company".

Now is it possible that some US three letter agency has undisclosed backdoors into RSA algorithms? Sure. But one could argue that for just about every other algorithm out there. Disproving it would be difficult.
 
Ed25519 keys are very short and easier for use. I am interested whether there is difference in the amount of received and sent bytes for handshake (compared to RSA).
 
Fair enough, that's another option. I just use rsa from habit. If you believe some of the advantages listed here, ed25519 might be a better choice, too.

How To Generate ed25519 SSH Key

Unix/Linux tutorials for beginners: how-tos and troubleshooting techniques, latest news and technical projects.
www.unixtutorial.org

There is a more advanced discussion here:-
security.stackexchange.com

SSH Key: Ed25519 vs RSA

A lot of people recommend using Ed25519 instead of RSA keys for SSH. The introduction page of Ed25519 (http://ed25519.cr.yp.to/) says: [..] breaking it has similar difficulty to breaking [..] RSA ...
security.stackexchange.com security.stackexchange.com
 
You must log in or register to reply here.
Back
Top