Problems with rsa keys auth with ssh. Please help

blind0ne

blind0ne

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
 

Attachments

  • config.txt
    3.4 KB · Views: 163
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
 
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
Click to expand...
Alredy 777 on .ssh directory and files. Dntknw what to do next. Please help
 
ssh -v will give debug info.
I first setup password authentication then key authentication and then i disable password authentication in sshd_config
 
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).
Click to expand...
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:
Code: 
[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):
Code: 
[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.
 
  • Like
Reactions: mer
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
 
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.
Click to expand...
The last part of the public key is just commentary, it can contain anything you want. It's not used to check anything.

Code: 
<keytype> <hash of pubkey> <commentary>
 
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.
 
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.
Click to expand...
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.
 
gpw928 said:
I think of my ssh keys as being mine, rather than belonging to a particular host.
Click to expand...

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...
 
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...
 
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).
 
You must log in or register to reply here.
Back
Top