How does an administrator reset the password of a user that cannot remember her password?
I used to just manually edit master.passwd when I (frequently) had to do this. This no longer works, and I don't like doing it that way anyway.
If (as root) I passwd user I am prompted for the current password. Since I don't know it, I cannot set a new password.
Two things sound strange. Passwords are not written verbatim in master.passwd,
so changing it there should never work. Second, as root you should be able to change any password, without being asked for the old one.
Passwords are never deciphered. They are written in ciphered form, and user password
when entered is also ciphered before comparison to stored password. Also, user password is not the only one which could work (give correct ciphered form),
but such sequences are reasonably rare, and it is not easy to get one from ciphered form, but ciphered forms should't be exposed anyway.
I don't know when this started; but as root, I do always get asked for the old password, which doesn't make sense to me.
I ended up reverting to editing master.passwd, and copying the hash from an account with a known password, to the account with the unknown password. Then I was able to enter the "old password" (the one from the other account) so I could set a new temporary password.
This is NetBSD 10.0, I should've mentioned that earlier. GENERIC amd64. I have not built my own kernel since upgrading to 10.0, so it is still genuinely the "GENERIC" (GENERIC64?) one.
Once upon a time, I could use pwhash to give me an encoded string to put in master.passwd. I don't know how long ago I could do that, but I cannot anymore. I don't recognise the output of pwhash anymore. $argon2id$v et cetera.
Did you edit passwd with # vipw ?
“Only the paranoid survive.”
― Harold Finch
NetBSD VPS , NetBSD , OS108
kc9udx chpass should also allow to change password of user from root
“Only the paranoid survive.”
― Harold Finch
NetBSD VPS , NetBSD , OS108
kc9udx it is similar to visudo. You can edit passwd file with that.
“Only the paranoid survive.”
― Harold Finch
NetBSD VPS , NetBSD , OS108
“Only the paranoid survive.”
― Harold Finch
NetBSD VPS , NetBSD , OS108
Jay so aside from the semaphoring, pwd_mkdb being run is the difference. I don't know why, but I've never needed that: any changes I make seem immediate. Perhaps cd /var/yp && make causes this also?
Mind you, for a long time, I normally use usermod except to brute-force change passwords as above.
kc9udx If (as root) I
passwd userI am prompted for the current password.
Hmm. The only way I can see this happening is if your password database is messed up: there's more than one root user with other UIDs, for instance.
What does this command when run as root show?
idWhat I would suggest is:
rm -v /etc/pwd.db /etc/spwd.dbvipw That'll rebuild a clean database.
# id
uid=0(root) gid=0(wheel) groups=0(wheel),2(kmem),3(sys),4(tty),5(operator),20(staff),31(guest),34(nvmm)
Well, I'll do that, and try again.
No dice. I still get prompted for "Old Password".
Post the output of these commands:
ls -l /etc/master.passwd /etc/passwd /etc/group /etc/pwd.db /etc/spwd.db
ls -l /usr/bin/passwd
cat /etc/nsswitch.conf
find /usr/lib -name *nss_*so*Can you check your /etc/master.passwd against this one. See if you have the same no. of fields with the same values (not the passwords or full names, obviously)
Compare your /etc/master.passwd against /etc/passwd and /etc/group. Make sure that passwd and master.passwd match up.
Run this command as root. Don't enter any password--press ENTER--let the command exit. Compress and post the ktrace.out file.
ktrace -di -f /tmp/ktrace.out passwdrvp
l.
# ls -l /etc/master.passwd /etc/passwd /etc/group /etc/pwd.db /etc/spwd.db
-rw-r--r-- 1 root wheel 821 Mar 6 2024 /etc/group
-rw------- 1 root wheel 3516 Oct 23 15:50 /etc/master.passwd
-rw-r--r-- 1 root wheel 2661 Oct 23 15:50 /etc/passwd
-rw-r--r-- 1 root wheel 40960 Oct 23 15:50 /etc/pwd.db
-rw------- 1 root wheel 40960 Oct 23 15:50 /etc/spwd.db
# ls -l /usr/bin/passwd
-r-sr-xr-x 2 root wheel 38224 Mar 28 2024 /usr/bin/passwd
# cat /etc/nsswitch.conf
# $NetBSD: nsswitch.conf,v 1.6 2009/10/25 00:17:06 tsarna Exp $
#
# nsswitch.conf(5) -
# name service switch configuration file
#
# These are the defaults in libc
#
#group: compat
#group_compat: nis
group: files
hosts: files dns
netgroup: files [notfound=return]
networks: files
#passwd: compat
#passwd_compat: nis
passwd: files
shells: files
# List of supported sources for each database
#
# group: compat, dns, files, nis
# group_compat: dns, nis
# hosts: dns, files, nis, mdnsd, multicast_dns
# netgroup: files, nis
# networks: dns, files, nis
# passwd: compat, dns, files, nis
# passwd_compat: dns, nis
# shells: dns, files, nis
# find /usr/lib -name *nss_*so*
/usr/lib/nss_mdnsd.so.0
/usr/lib/nss_multicast_dns.so.0 As far as I can tell.
I'm not sure what to check in /etc/group but it looks sane; passwd vs master.passwd checked out, but I have now gone as far as renaming passwd and letting vipw create it.
domainname= set in /etc/rc.conf? (yes, I think)Are 2. and 3. needed?
kc9udx 1. I don't think so; since this is a NIS server; wouldn't the way it is now be correct for that?
Ah, OK, but the default file should also work fine, I think, with programs then just connecting to localhost.
kc9udx 3. This is the NIS master server for this LAN.
OK. I don't know much about NIS (except that it stands for Yellow Pee--seriously: see HISTORY), but, it seems to me that root should be asked for their current password when changing any password on the local system via NIS; and that this should not be allowed at all when root is on a client system (because, I believe, passwords are sent en clair in NIS).
However, I'll have to look at the code and learn something more of NIS first.
But, if root wants to change passwords on a system running NIS, then it can be done directly (ie. w/o going through the NIS server). pam_unix(8) says that adding a passwd_db=files like this in /etc/pam.d/system should work:
password required pam_unix.so no_warn try_first_pass passwd_db=filesrvp I don't know who came up with "yellow pee". I've never heard that, and it wouldn't make sense like "yellow pages" does, which is the only explanation I've ever heard. In the olden days here, if you wanted to look up a phone number or address, you'd look in the Yellow Pages. (White Pages for residential, but there were iconic TV ads for the Yellow Pages, so that's why it's significant.)
Well anyway, the PAM system change did the trick. I never took the time to understand PAM, so I would've never found that without your help. Thank you!
Also; what NIS sends for passwords looks exactly like master.passwd
In the past, the passwords would be decoded and sent as plaintext, that was a cheap way to find out everyone's password.
Now, I'm guessing PAM is behind the fact that I cannot telnet to this server from a NetBSD machine, since upgrading to 10.0.
kc9udx I don't know who came up with "yellow pee".
OpenBSD joke, methinks.
kc9udx In the past, the passwords would be decoded and sent as plaintext,
Oh I doubt that: passwords were always the result of a one-way hash function; there being no way to get back the plaintext except by brute-forcing or hash-matching against a pre-built dictionary. But, typed-in old passwords are still sent in the clear, I see, from reading the source. I think I can see why: unless the implementations are the same, the machines could be using different hashing schemes: DES on an old server and MD5 on the client, say.
BTW, can you see this on the wire now? Might need an old-fashioned hub instead of a switch...
kc9udx Now, I'm guessing PAM is behind the fact that I cannot telnet to this server from a NetBSD machine, since upgrading to 10.0.
Could be. What's the error when run with -D ...
EDIT: telnet from a 9.4_STABLE client (in QEMU) to a -HEAD server worked w/o any config. Just uncommented the server lines in /etc/inetd.conf
rvp I haven't got to the bottom of it at all. I can telnet from there (or any other machine, NetBSD, Amiga, windows, Linux) to the other machines I have running NetBSD 10.0. And any machine not running NetBSD (ie not using SRA) to that one, but not from any machine running NetBSD.
BTW I forgot to write: -D doesn't give any indication of a problem. The client sees
Password:valid password
[ SRA accepts you ]
NetBSD/amd64 (hostname.domainname) (pts/1)
Connection closed by foreign host.
$