passwd and press ENTER, twice, then you have entered a valid password. If you don't do this you don't have a password. The difference is manifested when running sshd() on a system which doesn't have a password, you can't login, whereas you can do so using a blank password.pw usermod -n root -h 0 << 'EOT'
[ENTER]
EOT
This is completely pointless, and I assume you already guessed that?
pw usermod -n root -h 0 </dev/null. That isn't your issue, your issue is that pw(8) just refuses to set an empty password with this method. How to do that instead was already shown by CuatroTorres.
pw usermod -n myuser -h -pw usermod -n myuser -w nonepw mod user <user> -w none
pw()
printf()
printf "\r\n"
\r carriage return in if
Hi! How to check in script that $var equal '\r' symbol? tried if [ $var = $'\010' ] if [ $var = '-r' ] if [ "$var" = '\r' ] - nothing works. echo $var|hexdump is 000aforums.freebsd.org
pw mod user <user> -w none passwd ENTER ENTER. If you set pw to none it appears that password is not set at all, so you can't login. pw usermod -n root -w none If you just use ENTER as a password you do get a password prompt. Not sure if that counts as zero length... probably not.
No. A blank or empty password is still a password (of length zero), which is exactly what the
-w none option of pw(8) will set. No password at all means password authentication for that account isn't possible.Once again, a key is not a character and certainly can't be part of a password. passwd(1) implements a hidden prompt to interactively enter a password, using the ENTER key to finish input. Just hitting ENTER sets an empty password.
Definitively as this does not work as intended. Please open the PR as you found the bug.
It could be debatable. I just checked the passwd source, it doesn't even handle the password database but leaves it all to pam_unix(8) instead.
nullok to control whether these "null passwords" are accepted or not.Great! AFAIK a "null password" can be an exploitable security hole and should not be found anywhere.
password User password. This field should contain a plaintext string,
which will be encrypted before being placed in the user data-
base. If the password type is yes and this field is empty,
it is assumed the account will have an empty password. If
the password type is random and this field is not empty, its
contents will be used as a password. This field will be ig-
nored if the -w option is used with a no or none argument.
Be careful not to terminate this field with a closing `:' be-
cause it will be treated as part of the password.nullok option to control this, SSH (when accessing the passwd database directly) has its own option, etc ... unfortunately, it's possible to store an empty password in two different ways:nullok, it always relies on checking whether the password field in the database (where the hash goes) is empty, therefore all these checks would happily allow an empty password as soon as there is a hash (of the empty string) stored. Still, when setting an empty password using pam_unix(8), it does exactly that: hash that empty string and store the hash ?Whilst this is fine for a local login, it does not work for sshd(), even if you PermitEmptyPasswords.
#
# $FreeBSD$
#
# PAM configuration for the "sshd" service
#
# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass
# account
account required pam_nologin.so
#account required pam_krb5.so
account required pam_login_access.so
account required pam_unix.so
# session
#session optional pam_ssh.so want_agent
session required pam_permit.so
# password
#password sufficient pam_krb5.so no_warn try_first_pass
password required pam_unix.so no_warn try_first_pass--- sshd~ 2023-11-22 09:08:08.889676902 +0000
+++ sshd 2023-11-22 09:08:12.681743107 +0000
@@ -9,7 +9,7 @@
auth requisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
-auth required pam_unix.so no_warn try_first_pass
+auth required pam_unix.so no_warn try_first_pass nullok
# account
account required pam_nologin.sonullok applies to all accounts, not just the one you want passwordless. In particular for ssh(1) I recommend doing key-based authentication instead, see ssh-keygen(1). The key might be passwordless.
I already mentioned it earlier and I really want to emphasize it here again: THIS is most likely the sane solution for the specific scenario. And even passwordless keys can be somewhat risky (if you consider the possibility of leaking the private key), an alternative is to unlock your key only once per session using ssh-agent(1), then it can be used without re-entering the password every time. Another alternative, e.g. for automation where entering a password would be impossible, is to restrict what a key can do in ~/.ssh/authorized_keys, which is documented in sshd(8).
PasswordAuthentication yes and KbdInteractiveAuthentication no), PermitEmptyPasswords no prevents logins with empty passwords, no matter whether a hash is stored or the hash field is empty (good!), but PermitEmptyPasswords yes only works when there is a hash (of the empty string) stored → weird.PasswordAuthentication no and KbdInteractiveAuthentication yes), it's a bit more complicated...nullok only when PermitEmptyPasswords is set as well, in which case SSH doesn't even prompt for a password.What about talking to the upstream SSH people or is this FreeBSD specific?
Our SSH is OpenSSH, so upstream is OpenBSD, it's imported into our tree here: https://cgit.freebsd.org/src/tree/crypto/openssh
of course, the "portable" version of OpenSSH supports PAM, it's also used in (most?) Linux distributions for example.