I then untick and tick “SSH Access” to restart the SSH daemon.
I think I should be able to open a new PuTTY terminal session and login without a password. Instead I get an error message that starts with: No supported authentication methods available. (Server sent: public key).
To debug this, I have added LogLevel DEBUG2 to the sshd_config file.
I have run tail -f /var/log/messages | grep ssh in a terminal to watch for useful messages.
I am seeing failure on pre-auth.
You need to check which key type putty generated for you. If it was an rsa (sha1) key then this is no longer accepted by openssh since version 8.8p1. Here is the statement from the release notes for that version:-
This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol.
If you want to use rsa then it needs to be using the sha2 hash protocol and I am not sure if putty is doing that or not. I believe it has rsa only with sha1 hash.
Alternatively you could use ECDSA or Ed25519 key types, both of which are accepted by IPFire and are available in puttygen as well.
Hi
I hadn’t spotted that. For the last year or so I have been recovering from injuries received in a bicycle crash. I am just starting to get back into computing. I would never have gone looking at OpenSSH release notes to solve a problem using PuTTY with ipFire.
PuTTY Key Gen offers a number of key types. The default is “rsa” but it doesn’t say what flavour on the GUI.
This affects me a lot because I use ssh tunnels to remotely connect to Raspberry Pi’s over noisy, unreliable and intermittent channels. I terminate the tunnels within the firewall to a special user. The main tunnel then has to authenticate with ipFire, and not the computer on the Green network.
Is this something that could be noted in the ipFire Wiki so future users don’t get caught like me?
I turned up the sshd debug level to LogLevel DEBUG3 but all I got was:
May 8 16:21:22 ipfire sshd[7144]: Connection closed by authenticating user root xxx.yyy.21.73 port 123456 [preauth]
When I turn on logging within PuTTY, I get nothing useful.
In the past, I have setup public key login between PuTTY and a Linux machine many times. It just isn’t working for me this time. To fail on preauth, something is definitely wrong.
Hi
After some more testing, here is the contents of the logs for ipFire:
############ ipFire: /var/log/messages
May 8 20:49:57 ipfire sshd[24342]: Connection from xxx.yyy.21.73 port 58911 on xxx.yyy.21.1 port 22 rdomain “”
May 8 20:49:58 ipfire sshd[24342]: Failed publickey for root from 172.30.21.73 port 58911 ssh2: ECDSA SHA256:xxxxyyyyzzzz1234567890
May 8 20:50:06 ipfire sshd[24342]: Connection closed by authenticating user root xxx.yyy.21.73 port 58911 [preauth]
and PuTTY
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.05.08 20:49:54 =~=~=~=~=~=~=~=~=~=~=~=
Using username “root”.
Server refused our key
so not much to go on. This is with: LogLevel DEBUG3
I have checked that the authorized_keys file is: 600
I have tried ECDSA keys
I have tried SHA2 RSA keys
I have also tried copying the authorized_keys file from /etc/ssh/ to /root/
That made no difference to the logs or the outcome.
It looks like the type of key is being rejected. No indication of actually trying to process the keys.
Puzzling that it doesn’t work with any key that you have created.
I presume that you have checked that the pub key in the ipfire authorized_keys file is the same as the original on your client.
Check the /etc/sshd_config file to ensure that you have
PubkeyAuthentication yes
PasswordAuthentication no
and that the port is set to 22
As you are using putty I am presuming that the client being used is a windows machine.
Do you have a linux machine somewhere where you could create a new key on the command line and test that out with your ipfire. If it has the same problem it will be easier to increase the logging level by just adding -v, -vv or -vvv to the ssh command. You should get masses of detail with -vvv set.
Yes, the default location of the authorized_keys file is in the .ssh directory in the users home directory. For root that means it needs to be in /root/.ssh/authorized_keys as indicated by @tphz
As @tphz indicates you can adjust the location of the authorized_keys file in the sshd_config file but this will only stay in place until the next time you press save on the ssh WUI page. So if you change it you must not change anything further on the WUI page.
You will also likely have to redo the change after a Core Update has occurred as it is likely that the sshd_config file will be refreshed based on your WUI page settings.
Hi
OK so simply copying the file authorized_keys into a new directory /root/.ssh/ fixed the problem
That is all that needed to be done. PuTTY now completes a log-in without a password.
