Does Fedora Server 39 refuses ssh remote connection with a password by default?

Ask Fedora
, ,
1

I have a new installed Fedora server 39 on my raspberry pi 4. I cannot do any remote login from my laptop. After entering my username it refuses my password with this error:

debug1: Authentications that can continue: publickey,password
Permission denied, please try again.

I’m really sure that username and password are correct. They work fine directly used on the server in a localhost ssh-connection (ssh user@localhost). Port 22 is open on the server and sshd is enabled.
Is it possible that Fedora server 39 prohibits remote ssh connections with password authentification by default? How/where can I change this?

2

I think password login is allowed by default.

What options did you use with arm-image-installer?
The --add-key and --norootpass would be the interesting ones.

Of course if you use --add-key then you would not need a password to login to the RPi4.

The settings for sshd are in /etc/sshd_config and /etc/sshd_config.d/*.

Also have a look in the journal logs for sshd on the RPi4 and see if there are clues there.

sudo journalctl -b 0 -u sshd
3

What options did you use with arm-image-installer?
The --add-key and --norootpass would be the interesting ones.

I did not use any options. I built the image with the Rasberry Pi Imager on a Mac.
If I activate verbose mode while ssh login I can see that the server should accept publickey and password. But it does not.

Also have a look in the journal logs for sshd on the RPi4 and see if there are clues there.

Nothing useful there, I’m afraid.
I now installed a Debian based image on my raspberry and everything is working as expected. I had some issues while booting into a black screen with Fedora, too. Perhaps Fedora server 39 for raspberry needs some more development cycles? I’ll give it a try again, later.

4

The default on Fedora is to accept key based authentication. To change this, you need to edit /etc/ssh/sshd_config. Edit the line PasswordAuthentication no to PasswordAuthentication yes. Afterwards you can restart the ssh service systemctl restart sshd.service

5

Note that Fedora provides customization with sshd_config.d which helps avoid modifying the default configuration.

6

You can also use ssh -o PasswordAuthentication=yes <your server address> to make it use password for the login, then set up your key stuff to make it work by default.

1 Like
7

I use the ssh-copy-id to set up the key with minimum effort.

1 Like
8

Doesn’t ssh-copy-id require you to authenticate to the target server? If the key isn’t set up yet, it’ll ask for a password which will fail if password authentication is disallowed.

9

If “PasswordAuthentication” is set to “no” in the sshd_config, it will reject your attempts to use this option.

“PasswordAuthentication” needs to be enabled first before you can do this, because it will require you to log in while pushing your key to the remote server.

10

Obviously…

11

I have yet to see any Fedora system where password were not accepted by default when you try to connect with ssh. Empty passwords are usually not accepted and neithe is logging in as root.

12

Yes, but I don’t think the issue here is that PasswordAuthentication is set to “no”. In @portgselvadi’s original post, they post the message:

So I think password is allowed, just that ssh is preferring publickey but then denies the connection instead of prompting for a password. On a new Fedora install (clean install VM), this is what happens when I try to log into it:

$ ssh test@192.168.122.44                              
test@192.168.122.44: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

$ ssh -o PasswordAuthentication=yes test@192.168.122.44
test@192.168.122.44's password: 
Last login: Tue Nov 21 09:08:45 2023 from 192.168.122.1

[test@fedora ~]$
[test@fedora ~]$ sudo grep PasswordAuthentication /etc/ssh/ssh_config
#   PasswordAuthentication yes
1 Like
13

ssh -o PasswordAuthentication=yes

I now had the time to try the ideas you all have proposed. To add the PasswordAuthentication option into the ssh command has turned out to be the solution for my problem !!
Further, I had to enable PasswordAuthentication in ssh_config - as user Alys had proposed in an earlier post.
Thank you all for your invaluable help!

3 Likes
14

Instead of having to use that every time you connect, you can add it to your ${HOME}/.ssh/config like so:

Host myserver
    HostName <hostname or IP aaddress>
    PasswordAuthentication yes
15

The man page for sshd_config states that PasswordAuthentication defaults to yes and is not overriden in /etc/ssh/sshd_config.

Also the /etc/ssh/ssh_config does not override the default either.

It is not necessary to do anything to allow password access on the server or the client end for Fedora systems.

But if you have hardened the security by editing the ssh/sshd config files then password can stop working.

Also if ~/.ssh/config has set it to NO then that will stop it working.

16

Actually, all I wanted was to copy my pubkey onto my freshly installed server (as I always do). To do so, I had to enter my password once. To my surprise that was not accepted. At this point, I hadn’t changed anything of the server’s configuration!
For me, the easiest solution was to add the PasswordAuthentication=yes option to my ssh command. I wasn’t aware of this option, before. I also changed the sshd_config but that’s not necessary, because I will authenticate solely by pubkey in the future.
I have learned that the image of Fedora server is behaving different in this subject by default than the workstation’s - at least the ARM image…

17

It is not necessary to do anything to allow password access on the server or the client end for Fedora systems.

That’s not quite right. At least with the server image of Fedora 39 one has to know how to override the password authentication setting. Default behaviour is to decline passwords. That was the core of my problem. But the solution proved to be simple as this discussion shows.

1 Like
18

It is not the server that has a problem its your client.

Either your .ssh/config blocks password or you have changed /etc/ssh/ssh_config from the defaults to block password.

1 Like
19

It is not the server that has a problem its your client.

Ah, ok. I had tried with two different clients (mac and fedora) - both of them showed the same problem. That’s why I suspected the problem was on the server. I never have changed ssh_config on my clients, and I do not have any .ssh/config on them, neither. I think I’ll do another fresh installation and try to reproduce the problem. Thank you for your help!

20

I disagree.
I have several hosts using Workstation running fedora 39 and these have been upgraded through many releases.

In all the hosts my ~/.ssh/config contains only this line. # These are internet facing hosts
With all I have only had to start the sshd daemon and was able to use ssh to connect between them using passwords. The Workstation edition allows passwords with ssh, AFAICT the Server edition does not by default.

I believe that the issue is that the server is configured to block password connections via ssh and that configuring the server locally to allow connections with a password, or to install the key config in the users ~/.ssh folder would fix the issue. Attempting to do the config via ssh remotely seems a very much uphill battle, but doing so locally would be very simple.

My suggestion would be for @portgselvadi to log into the RPi (fedora server) then do the config locally.
I would assume his laptop is also running sshd and that he has created the keys on the laptop so simply using rsync -av portgselvadi@laptop:~/.ssh . would copy in all the config needed. Then he should be able to return to the laptop and ssh into the RPi as his user and the key would be used and accepted.