[sshd] keeps asking for a password

Difficult to pinpoint without a server log also.

https://www.experts-exchange.com/questions/29170540/Cannot-login-ssh-as-any-user-other-than-root.html provides how I do this.

Clearing all firewall rules, at both ends, then running a verbose log of client + server together, usually turns up the problem quickly.

Well... not always... just usually...

Here is the answer from the server: https://x0.at/r2UA.txt

That's not the server log - that's the client side log. However, the fact that it skips past the pubkey auth step so quickly probably means the server couldn't find a matching key on your side or the permissions on the .ssh folder (on the server side) or its contents are wrong.

This is really common because so many people over-enable permissions when debugging or manually create the files via an editor and their default permissions on new files allows group and/or world permissions.

The sshd service requires that the user's .ssh folder (again, on the server side) is owned by that user and is set to 700 permissions so ONLY that user can access it. It also requires that the contents inside that folder are owned by the user and set to 600 permissions (again, no permissions for group or world - only for the owner user). If those permissions are not properly restricted, the sshd service will skip over those files and not check for a matching key.

The permissions are ok but the server keeps asking for a password. Where are the log on the server side, there's nothing like /var/ssh on my disk?
If I remember well, I tried to install sssd or openldap at some point. Maybe it shuffled the authentication orders

Typically it's a file inside /var/log/ somewhere, but the name could vary depending your sshd config and Linux distro. You can always just do a grep -ril "sshd" /var/log/* and that would likely indicate the logs you're looking for.

I don't know about sssd but openldap wouldn't do that. Given that sshd is such a crucial part of system admin, it would be extremely unusual for a legitimate application to intentionally screw with the sshd config.

One other thing to check is to make sure that the authorized_keys file does not have any typos. A long time ago, I appended a new key to that file but missed the line break.

Here is the last log attempt from /var/log/audit.log: https://x0.at/-9Bx.txt

The keys have been copied with ssh-copy-id so it should be ok

Hmmm that's probably not the right file. I should amend my previous suggestion - when you do that grep, make sure you do it with sudo (sudo grep -ril ...).

What are the values for the SyslogFacility and LogLevel directives in your sshd config?

> The keys have been copied with ssh-copy-id so it should be ok

Doesn't hurt to double-check and make sure the file is there, has the right ownership, permissions, and has the correct public key in it.

The authorized_keys seem ok: https://x0.at/iu1Q.txt

and the complete sshd config file: https://x0.at/-Out.txt

Looks like you're including other conf files:

/etc/ssh/sshd_config.d/*.confDo any of those set those two logging directives?

Also, while duplicate keys in authorized_keys aren't a technical problem, it's bad practice. You have about 4 duplicates in there - just edit the file and delete the dupes.

There is one include only: https://x0.at/5KaE.txt
The duplicates are deleted, it was several ssh-copy-id in sequel

It says SyslogFacility AUTHPRIV, it could be the problem?

That probably logs to /var/log/auth.log, then, but you'll likely need to access the file with sudo (temp root permissions). There is one more include at the top of that file you showed. If it doesn't define loglevel, then I would uncomment the LogLevel line in the initial config and set it to VERBOSE and then restart sshd and check out that file.

Important: anytime you're working on sshd config, make sure you have a way into the server if sshd fails to restart for any reason.

The last include: https://x0.at/ye4L.txt
No file /var/log/auth.log but the PC is on my desk so no worries (actually, I'm making installation tests). The LogLevel option is set to VERBOSE and sshd has restarted.
Last ssh login from journalctl -ef: https://x0.at/VanZ.txt

Okay that last conf file gave me a lead and I went back and looked at your initial log and I see this:

debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa_hp2 - corresponding algo not in PubkeyAcceptedAlgorithms

So you have PubkeyAcceptedKeyTypes defined but not PubkeyAcceptedAlgorithms, and you're trying to pass a ssh-dss key but that's not in the default list of accepted algorithms so you'll need to specify that directive and make sure it includes ssh-dss:

PubkeyAcceptedKeyTypes=+ssh-dss

Yeah a little research shows that ssh-dss was excluded as a default valid key type as of openssh 7.0 so you'd need to include it per my previous comment or else use a key with a newer authority.

In my client config, I have set:

Host my7
    Hostname 172.168.1.7
    User user
    IdentityFile ~/.ssh/id_dsa_hp2
    PubkeyAcceptedKeyTypes +ssh-dss
    HostKeyAlgorithms=+ssh-dss

Select allOpen in new window

but the server still asks for the password. Does the server need a similar line in the sshd_config file?
Or maybe the simpler is to generate a key which will be accepted by the server?

Yes. The remote server is OpenSSH 8.4:

debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4

Select allOpen in new window

...so it needs the same line.