sshd problem "RSA key is not allowed"

sremick

sremick

Ok, it's been a while since I set this up successfully in the past. I should've kept better notes, or something has changed since.

I'm trying to connect via SSH to a FreeBSD system (13.0-REL) from PuTTY on Windows. I've created the public and private key pair using PuTTYgen. I've added the public key to ~/.ssh/authorized_keys2 and have the private key loaded in the session config on PuTTY.

On the PuTTY end, I get:
Code: 
Using username "username".
Server refused our key
And then in a popup window "No supported authentication methods available (server sent: publickey)"

In lieu of working SSH, my window into the server is frustratingly limited, but in running sshd with -ddd I think the relevant log entry is:
Code: 
debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed

In /etc/ssh/sshd_config, I have "AuthenticationMethods" set to "publickey", "RSAAuthentication" to "yes", and "PubKeyAuthentication" to "yes".

What else am I missing?
 
covacat said:
use ~/.ssh/authorized_keys
and make sure it is mode 0400 or 0600
Click to expand...

I started with ~/.ssh/authorized_keys but that didn't work, and when I checked the debug logs sshd was complaining there was no authorized_keys2 so I copied the file, now both exist and that error is gone.

And they are both chmod 0600
 
Show us what's in ~/.ssh/authorized_keys.

Hint: it should be one line per host, commencing "ssh-rsa ".

Edit: also show us any changes you have made to /etc/ssh/sshd_config.
 
Unfortunately my only window into my server (until I get SSH working) is a web-based console that doesn't allow copy or paste for some annoying reason (DigitalOcean). But ~/.ssh/authorized_keys (and authorized_keys2 as they are identical copies) do indeed just have lines beginning with "ssh-rsa", then a space, then the long public key on a single line. The key I'm trying to use at the moment is the last one.

Likewise, I can't give you a copy-paste from sshd_config, but here are the lines I've uncommented:


Apache config: 
AuthenticationMethods publickey
LogLevel DEBUG
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
 
RSAAuthentication is no longer documented in sshd_config(5) and does not appear in FreeBSD 13.0 /etc/ssh/sshd_config.
If you want to permit ssh-based login only with ssh keys, append the following to the original /etc/ssh/sshd_config:
Code: 
# We want login via ssh with keys only...
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
If you want to permit ssh root login, with ssh key only (I use this to pull backups), append this:
Code: 
# We need to allow root login for rsnapshot backup server
PermitRootLogin prohibit-password
If you really want password authentication, read the docs, before you change "PasswordAuthentication". I don't use passwords, except on the console, so I don't have any considered advice.
Make sure that ~/.ssh is mode 700.
Restart sshd.
The original sshd_config from FreeBSD 13 is attached.
 

Attachments

sremick said:
Unfortunately my only window into my server (until I get SSH working) is a web-based console that doesn't allow copy or paste for some annoying reason (DigitalOcean)
Click to expand...

If you use the DO-provided FreeBSD image (which IMHO needs some cleanup after creation), you can simply provide the SSH-key at droplet creation (IIRC this is even mandatory).
If you went some other route, to transfer your pubkey just create a normal user account, add it to group 'wheel' and temporarily allow password-based logins. Then simply transfer the key via "ssh-copy-id" (or the putty-equivalent command) from your client to the server.

I'd highly recommend NOT allowing root login at all (even with 'prohibit-password') and instead use doas(8) to switch from the normal user account to root if needed.
Even on a privately used server that's just good practice and you can simply let sshguard add any IP that tries to login as 'root' to the blacklist. On any DO prefix you'll get hammered with login attempts almost from the first minute of creating a droplet, so this is a very effective way to suppress the noise.
 
sko said:
I'd highly recommend NOT allowing root login at all (even with 'prohibit-password') and instead use doas(8) to switch from the normal user account to root
Click to expand...
And I'd highly recommend that you consider the option to implement off-site backups, at least for any data on the virtual machine that can't be re-imaged.
If those backups are managed by the backup server needing root access (and they frequently are) you may need to allow a highly secure root login method.
Since the backup server is likely to originate form a well known IP address, permitting root login by secure key does not preclude blacklisting other IP addresses.
I did not, and never would, suggest that "PermitRootLogin prohibit-password" be used as an alternative to doas(1) or sudo(8).
 
Agreed re: not allowing root login. Not keen on that. The account I'm trying to log in as over ssh is a member of wheel.

My DO droplet originally was FreeBSD 12.2 (the provided image) but has gone through some upgrades. At one point the default networking that DO provided got messed up but working with them I got that straightened out. For the most part now it's a manually-created environment, with running software. So we're past the point of stuff to be done at droplet creation.

I think I got it straightened out, with the help of your insight. The main two issues were:

1) the presence of the line "AuthenticationMethods publickey"
2) The fact that while I thought I could paste into the DO console web window, pasting the whole public key at once was too fast and it got corrupted, so there were missing characters in the resulting authorized_keys file.

I was able to get password-based ssh working, then pasted the public key through that PuTTY session, then was able to turn off password-based authentication and use my original keys to connect fine. Yay!

Thanks, everyone
 
The DO networking is pretty straightforward - at least if you don't use their (heavily bloated) scripts that drag in python, bash and all sorts of crap. At least this was the case back when I tried their images, so I wrote cleanup-scripts for "short-term" droplets and manually reinstalled droplets that I was planning to use long-term.
In both cases: just manually configure networking via /etc/rc.conf.local as you would with any other machine.

There was a time when their "snapshot-backups" occasionally messed up ZFS. There's a good chance they fixed this when they started to offer ZFS as an image option, but I never trusted those snapshots after I once lost 3 custom droplet images due to a fault at their end (the images were nothing critical, yet it was still annoying). I still use the included single-snapshot-slot, but for proper backups I solely rely on my own infrastructure, meaning I take ZFS snapshots and replicate them twice per day to the storageserver at my home.

As for the original problem:
Instead of any ssh-specific mechanism there's also always the McGuyver-way of transferring ASCII text via netcat...
 
You must log in or register to reply here.
Back
Top