# Problems with rsa keys auth with ssh. Please help



## blind0ne (Aug 26, 2021)

Greetings, please, help me. I've attached my /etc/ssh/sshd_config. I've tried to generate key pair with ssh-keygen on linux host and puttygen, and then copy pub_key_string to /root/.ssh/authorized_keys file on my FreeBSD with this config, but for both ssh on linux and putty with generated keys I got such an error: Permission denied (publickey). 

Thx


----------



## covacat (Aug 26, 2021)

restart sshd if you didn't (after setting permitrootlogin)
check if authorized_keys file is mode 600 or 400 and owned by root and .ssh is 700


----------



## blind0ne (Aug 26, 2021)

covacat said:


> restart sshd if you didn't (after setting permitrootlogin)
> check if authorized_keys file is mode 600 or 400 and owned by root and .ssh is 700


Alredy 777 on .ssh directory and files. Dntknw what to do next. Please help


----------



## covacat (Aug 26, 2021)

blind0ne said:


> Alredy 777 on .ssh directory and files. Dntknw what to do next. Please help


777 is wrong. make them usable only by root
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys


----------



## Alain De Vos (Aug 28, 2021)

ssh -v will give debug info.
I first setup password authentication then key authentication and then i disable password authentication in sshd_config


----------



## gpw928 (Aug 28, 2021)

blind0ne said:


> Greetings, please, help me. I've attached my /etc/ssh/sshd_config. I've tried to generate key pair with ssh-keygen on linux host and puttygen, and then copy pub_key_string to /root/.ssh/authorized_keys file on my FreeBSD with this config, but for both ssh on linux and putty with generated keys I got such an error: Permission denied (publickey).


It appears to me that you are trying to login as root using authorized_keys.  That's not going to be permitted by the default configurations.

You should not do it unless you have a really good reason -- other users OK, but not root.  Assuming you have a good reason (I do, my backup server needs to get in as root)...

On the target host you need to check the prermissions on ~root directory and ~root/.ssh.  They should look like this:
	
	



```
[ritz.129] # cd ~root
[ritz.130] # ls -lad .
drwxr-xr-x  9 root  wheel  21 Aug 27 09:18 .
[ritz.131] # ls -la .ssh
total 39
drwx------  2 root  wheel     6 Aug 15  2019 .
drwxr-xr-x  9 root  wheel    21 Aug 27 09:18 ..
-rw-r--r--  1 root  wheel  1435 Jul 31  2019 authorized_keys
-rw-------  1 root  wheel  6505 Jul 31  2019 id_rsa
-rw-r--r--  1 root  wheel  1432 Jul 31  2019 id_rsa.pub
-rw-r--r--  1 root  wheel  1278 Apr 19 09:52 known_hosts
```
Note that any permissions or modes other than shown above may prevent authentication.  In particular mode 777 on ~root/.ssh is utterly wrong.

The authorized_keys file should contain the public key  occupying one line per authorised user.  If there is more than one line per user, stop and verify you are using the correct key format.

You need to modify /etc/ssh/sshd_config to allow root logins using ssh key (but not ordinary login):
	
	



```
[ritz.134] # diff sshd_config.dist sshd_config
2c2
< #    $FreeBSD: releng/11.3/crypto/openssh/sshd_config 323136 2017-09-02 23:39:51Z des $
---
> #    $FreeBSD: releng/11.4/crypto/openssh/sshd_config 323136 2017-09-02 23:39:51Z des $
122a123,130
> 
> # We need to allow root login for rsnapshot backup server
> PermitRootLogin prohibit-password
> # We want login via ssh with keys only...
> PasswordAuthentication no
> ChallengeResponseAuthentication no
> PubkeyAcceptedKeyTypes=+ssh-dss
```
Note that I allow ssh-dss keys for backwards compatibility.  You probably don't want this.

Don't forget to `service sshd restart` after the changes.


----------



## blind0ne (Sep 10, 2021)

Thx, i've realized that key is generated on client host and pub part beeign isnserted on server. So the next question is - how to backup keys. If my host is changed for example. How to bring key from on pc to another device, if there is a @pc-name in the key part. 

Thnx


----------



## SirDice (Sep 10, 2021)

blind0ne said:


> Thx, i've realized that key is generated on client host and pub part beeign isnserted on server. So the next question is - how to backup keys. If my host is changed for example. How to bring key from on pc to another device, if there is a @pc-name in the key part.


The last part of the public key is just commentary, it can contain anything you want. It's not used to check anything.


```
<keytype> <hash of pubkey> <commentary>
```


----------



## sko (Sep 10, 2021)

you can also just use ssh-copy-id(1) and login with password once to submit the key to the remote authorized_keys file and disable password-authentication in sshd_config afterwards.


----------



## gpw928 (Sep 10, 2021)

blind0ne said:


> Thx, i've realized that key is generated on client host and pub part beeign isnserted on server. So the next question is - how to backup keys. If my host is changed for example. How to bring key from on pc to another device, if there is a @pc-name in the key part.


I think of my ssh keys as being mine, rather than belonging to a particular host.

The public key is just that, public.  Anyone can see it.  And, it's the one that you place into the ~/.ssh/authorized_keys file to get ssh login access to a host.  As suggested by sko above, ssh-copy-id(1) will do this with a single command.

My private key is installed in ~/.ssh on all the hosts from which I am likely to originate an ssh connection.  It's pass-phrase protected, and kept very private.  Modes and ownership matter.  See my post above.

To avoid having to constantly unlock the private key every time I use `ssh`, I unlock it once when I login and keep it, unlocked, on a key chain.  That's a more advanced topic.


----------



## sko (Sep 11, 2021)

gpw928 said:


> I think of my ssh keys as being mine, rather than belonging to a particular host.



That's why I'm using gpg-agent with 'enable-ssh-support' and the GPG-keys on my yubikey for SSH-authentication; this way I always have my keys with me and don't have to bother syncing them between all my systems...


----------



## dd_ff_bb (Sep 11, 2021)

While we are on the topic just a reminder:


			Important note for future FreeBSD base system OpenSSH update


----------



## sko (Sep 13, 2021)

This is quite serious... A quick check on some of our networking gear revealed that a lot of it would be inaccessible via SSH after this change. I.e. almost all of our cisco switches that are still under support (i.e. not EOL!!) are affected, where IOS 15.2 is the latest and probably last available release. To make it clear: such gear is only accessible via isolated vlans/networks anyways...
According to the debate on the mailing list it seems there won't be any config or build option to keep rsa-sha1 compatibility around - which will mean you either have to keep an old OS around or access such gear via telnet (which both really increases security, congratulations!) or spend probably tens of thousands of whatever currency you're using to replace perfectly working gear that is running in isolated networks anyways... This decision seems to be very short-sighted IMHO and it's alarming that all the plausible and valid objections are just ignored and dismissed.


After reading some more on that topic, it seems e.g. OpenBSD will still allow using PubkeyAcceptedAlgorithms to re-enable rsa-sha via ssh config (https://marc.info/?l=openbsd-cvs&m=163028120502416&w=2)
That's in sync with the upstream commit against OpenSSH: https://github.com/openssh/openssh-portable/commit/2344750250247111a6c3c6a4fe84ed583a61cc11
So I really hope FreeBSD will also keep this possible override and won't blindly remove the ability to use rsa-sha like the initial post to the mailing list seems to indicate...


----------



## gpw928 (Sep 13, 2021)

The keepers of ssh at OpenBSD have always favoured the very high horse.

Disabling the null cipher (`ssh -c none`) is a case in point.  It crippled the speed of rsync(1) (where no encryption was needed on a completely private network).


----------



## jb_fvwm2 (Sep 14, 2021)

`pkg update` is failing here.  Is this due to the changes mentioned in this thread, I wonder?


----------



## tingo (Sep 14, 2021)

jb_fvwm2 said:


> `pkg update` is failing here.  Is this due to the changes mentioned in this thread, I wonder?


No, totally unrelated.


----------

