This is the same error as closed bug 40261 from 20 years ago. Apparently a regression. Setting "PasswordAuthentication no" in /etc/ssh/sshd_config does not disable a password logins. To accomplish that, "KbdInteractiveAuthentication no" must be set ("yes" is the default). I note that "PasswordAuthentication no" is sufficient to disable password logins on DragonFlyBSD, which has the same default for KbdInteractiveAuthentication.
What FreeBSD version are you running? It is not reproducible neither on stable/13 nor on 14-CURRENT. SSH was updated to OpenSSH_8.8p1 in CURRENT and 1{2,3}-STABLE. Setting "KbdInteractiveAuthentication no" disables password authentication completely in all these branches.
Running 13.1 RC1. I saw the same thing with the 13 release. sshd_config says the default is no password authentication, but you can ssh/scp in with a password, running the stock sshd_config. I'm confused by your statement 'Setting "KbdInteractiveAuthentication no" disables password authentication completely in all these branches.'. That statement is true, but "PasswordAuthentication no" should be sufficient to disable password authentication (that's what it says!!) and that's not the case with 13 release or 13.1 RC1. But it is the case with DragonFlyBSD 6.2.1. DragonFly's default setup: # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #KbdInteractiveAuthentication yes does NOT allow password logins.
(In reply to donaldcallen from comment #2) So what's the real problem here? Can't you disable password authentication in 13.1-RC1? Please uncomment #KbdInteractiveAuthentication no as described in sshd_config file: # Set this to 'no' to disable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the KbdInteractiveAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via KbdInteractiveAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and KbdInteractiveAuthentication to 'no'. #UsePAM yes
(In reply to Marek Zarychta from comment #3) As I said in my original post, "Setting "PasswordAuthentication no" in /etc/ssh/sshd_config does not disable a password logins. To accomplish that, "KbdInteractiveAuthentication no" must be set ("yes" is the default).". So the answer to your question "Can't you disable password authentication in 13.1-RC1?" is yes, I can. The answer to your question "What's the real problem here?" is that "PasswordAuthentication" with a default setting of "no" says pretty explicitly that password authentication is off by default. Except it isn't. You also have to disable KbdInteractiveAuthentication. And, as I've also already pointed out, FreeBSD relative DragonFlyBSD does the sensible thing here -- "PasswordAuthentication no" means "PasswordAuthentication no".
(In reply to donaldcallen from comment #4) Their (DFly) defaults are: KbdInteractiveAuthentication no PasswordAuthentication yes UsePAM yes ours (FreeBSD): KbdInteractiveAuthentication yes PasswordAuthentication no UsePAM yes Either way, it's not a bug IMHO, so no worries, you can disable it for both of them by setting: KbdInteractiveAuthentication no PasswordAuthentication no
(In reply to Marek Zarychta from comment #5) It could well be the way I'm saying it, and therefore my fault, but you are not understanding my point. The bug is the way the defaults are set in FreeBSD. The default setting for PasswordAuthentication is 'no', which leads an unsuspecting reader who has the crazy idea that no means no to think that password authentication is disabled when it is not. In my opinion, in FreeBSD, if the desired default state is that password authentication is enabled, then PasswordAuthentication should be 'yes' by default, which would not change sshd's behavior but would make things clearer to the reader of the config file. It would also be nice if there were a comment in the config file that said something like "To turn off password authentication, both PasswordAuthentication *and* KbdInteractiveAuthentication must 'no".
(In reply to donaldcallen from comment #6) You might be right. In the meantime I have done some inquiries and I know that DFly has default setting "UsePAM no"
This (unfortunately) functions as expected, perhaps due to a poor choice of option names. PasswordAuthentication controls use of sshd's built-in password authentication code, not the ability to login with a password in general. KbdInteractiveAuthentication (formerly known as ChallengeResponseAuthentication) queries the user and collects their input (hence challenge & response) - this could involve a password, or it could be some other scheme. From ssh's perspective, with PasswordAuthentication no and KbdInteractiveAuthentication yes you are not using a password, you're using some interactive authentication that is opaque to sshd itself. The existing defaults are as desired, although it may be that sshd_config(5) and/or the comments in sshd_config itself need to be more clear. At least the man page description for PasswordAuthentication should be explicit about controlling sshd's built-in password support, not "password authentication". There is a hint about this in the UsePAM description in sshd_config(5) Because PAM keyboard-interactive authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or KbdInteractiveAuthentication.
Some more details: PasswordAuthentication is handled by auth2-passwd.c and auth-passwd.c, and auth-pam.c, which uses sshpam_auth_passwd() if UsePAM is true, else it uses crypt(3) and compares against the passwd entry. In effect, sshd requests a user name and a password, and then passes them to pam or checks the password itself. The PasswordAuthentication scheme is described in RFC 4252. KbdInteractiveAuthentication is handled by auth2-kbdint.c, auth2-chall.c, and auth-pam.c. In this case sshpam_thread() calls pam_authenticate(), and the authentication is driven by pam, not by sshd. This scheme is described in RFC 4256, Generic Message Exchange Authentication for the Secure Shell Protocol."
It is well documented in: 1. sshd_config(5) 2. Comments included in default version of /etc/ssh/sshd_config Users should read the documentation.
(In reply to Marek Zarychta from comment #10) And people commenting on bug reports should learn to read. Ah, the old RTFM trick. Well what if the FM doesn't provide the necessary information or is just plain wrong? "PasswordAuthentication no" in most languages, English included means no password authentication. As for another part of your snotty message, man 5 sshd_config says: " PasswordAuthentication Specifies whether password authentication is allowed. See also UsePAM. The default is no. " The first sentence of that is pretty definitive, implying that this setting determines whether password authentication is allowed. It doesn't. So let's look at UsePAM: " UsePAM Enables the Pluggable Authentication Module interface. If set to yes this will enable PAM authentication using KbdInteractiveAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. Because PAM keyboard-interactive authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or KbdInteractiveAuthentication. If UsePAM is enabled, you will not be able to run sshd(8) as a non-root user. The default is yes." If you think this is documentation understandable by anyone other than the person who wrote the code, then we have nothing else to talk about. We probably don't anyway. What I am wasting my time requesting here is a CLEAR INDICATION in the default sshd_config as to how to enable or disable password authentication. And I repeat -- Dragonfly gets this right. Matt and Co. have done the sensible thing here. And I would remind you that this is a security issue. But typically, trying to convince you people to make a small DOCUMENTATION change is like pulling teeth. I can only imagine what it would be like if I wanted you to change a line of code. This is a typical example of what gets me crazy about FreeBSD, despite the systems' many virtues. It always feels like dealing with a big, stupid committee that just can't make sensible decisions.
I've already said the documentation should be improved but this sort of rhetoric is not helpful and is rather de-motivational. Note that this is not a FreeBSD-specific issue, the documentation/comments for these options come directly from upstream OpenSSH, improvements will need to be coordinated with them and will likely involve some back-and-forth iteration.
Proposed patch in https://reviews.freebsd.org/D35272
I now see that this was submitted as a port bug, although it did not specify security/openssh-portable and I assumed it was a base system report when I found this PR. To the original submitter can you please clarify (although the report is applicable to both, in any case).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9f009e066f088e2c31442db31d2a85001040abfe commit 9f009e066f088e2c31442db31d2a85001040abfe Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2022-05-25 13:32:57 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-06-08 20:20:46 +0000 sshd_config: clarify password authentication options Passwords may be accepted by both the PasswordAuthentication and KbdInteractiveAuthentication authentication schemes. Add a reference to the latter in the description/comment for PasswordAuthentication, as it otherwise may seem that "PasswordAuthentication no" implies passwords will be disallowed. This situation should be clarified with more extensive documentation on the authentication schemes and configuration options, but that should be done in coordination with upstream OpenSSH. This is a minimal change that will hopefully clarify the situation without requiring an extensive local patch set. PR: 263045 Reviewed by: manu (earlier version) MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D35272 crypto/openssh/sshd_config | 1 + crypto/openssh/sshd_config.5 | 2 ++ 2 files changed, 3 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ce8133a5218b1f0e3ed17579029fcb12be93cf2d commit ce8133a5218b1f0e3ed17579029fcb12be93cf2d Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2022-05-25 13:32:57 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-06-16 12:50:23 +0000 sshd_config: clarify password authentication options Passwords may be accepted by both the PasswordAuthentication and KbdInteractiveAuthentication authentication schemes. Add a reference to the latter in the description/comment for PasswordAuthentication, as it otherwise may seem that "PasswordAuthentication no" implies passwords will be disallowed. This situation should be clarified with more extensive documentation on the authentication schemes and configuration options, but that should be done in coordination with upstream OpenSSH. This is a minimal change that will hopefully clarify the situation without requiring an extensive local patch set. PR: 263045 Reviewed by: manu (earlier version) MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D35272 (cherry picked from commit 9f009e066f088e2c31442db31d2a85001040abfe) crypto/openssh/sshd_config | 1 + crypto/openssh/sshd_config.5 | 2 ++ 2 files changed, 3 insertions(+)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a5e7c28b9b84b81bbb8a8242ae44cc073b0103dc commit a5e7c28b9b84b81bbb8a8242ae44cc073b0103dc Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2022-05-25 13:32:57 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-06-16 13:37:36 +0000 sshd_config: clarify password authentication options Passwords may be accepted by both the PasswordAuthentication and KbdInteractiveAuthentication authentication schemes. Add a reference to the latter in the description/comment for PasswordAuthentication, as it otherwise may seem that "PasswordAuthentication no" implies passwords will be disallowed. This situation should be clarified with more extensive documentation on the authentication schemes and configuration options, but that should be done in coordination with upstream OpenSSH. This is a minimal change that will hopefully clarify the situation without requiring an extensive local patch set. PR: 263045 Reviewed by: manu (earlier version) MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D35272 (cherry picked from commit 9f009e066f088e2c31442db31d2a85001040abfe) crypto/openssh/sshd_config | 1 + crypto/openssh/sshd_config.5 | 2 ++ 2 files changed, 3 insertions(+)
^Triage: assign to committer who made the change back in 2022.