# sshd problem "RSA key is not allowed"



## sremick (Feb 23, 2022)

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:

```
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:

```
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 (Feb 23, 2022)

use ~/.ssh/authorized_keys
and make sure it is mode 0400 or 0600


----------



## sremick (Feb 23, 2022)

covacat said:


> use ~/.ssh/authorized_keys
> and make sure it is mode 0400 or 0600



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


----------



## gpw928 (Feb 23, 2022)

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.


----------



## sremick (Feb 23, 2022)

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:



```
AuthenticationMethods publickey
LogLevel DEBUG
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
```


----------



## gpw928 (Feb 23, 2022)

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:
	
	



```
# 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:
	
	



```
# 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.


----------



## sko (Feb 23, 2022)

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)



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.


----------



## gpw928 (Feb 23, 2022)

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


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).


----------



## sremick (Feb 23, 2022)

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


----------



## suntzu00 (Feb 23, 2022)

or you can use certificates (check the ssh-keygen manual). that way you no longer need to move your pub key around.


----------



## sko (Feb 24, 2022)

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...


----------

