07-13-2021, 01:40 AM
(This post was last modified: 07-13-2021, 01:44 AM by Gribouille.)
(07-12-2021, 06:06 PM)KC9UDX Wrote: I checked the domainname and they all agree.
I tried 'su - test' on the client which *worked* to my surprise.
I edited /etc/resolv.conf and changed test.net to the correct domain; NetworkManager apparently put this in there and probably will again; I'll have to investigate NetworkManager.
But since changing that, I restarted nis and rpcbind and now /var/log/auth.log gives more information:
Jul 12 19:15:44 client login[14820]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/pts/1 ruser= rhost=localhost user=test
Jul 12 19:15:47 client login[14820]: FAILED LOGIN (1) on '/dev/pts/1' from 'localhost' FOR 'test', Authentication failure Hello,
You have to use an other account than 'root' to make 'su - test', because the password is not asked.
An other test, use an other local account, as 'root' and make 'su - <the other account>', and after 'su - test'. If you haven't restricted the root's rights, this a good way to check the password.
The network domain name and the network NIS domain name are two different things without link. We can suppose that if your hosts are in different network domains, depending of their configuration, it could be more tricky to access to the hosts.
As you can access by 'SSH' to the host and with the extract of your logs, the NetworkManger seems innocent for me.
A classic trap : the fonts ! Have you check that when your are physically on the host and when you type the password, in place of the login per example, the display is good ? It could be good in a graphical session but not in console mode. The console mode is the mode used when you make a 'SSH'.
I always add the following packages : - console-data
- console-common
- unicode-data
With Debian : 'dpkg-reconfigure locales'.
I can't SSH with a NIS user account. I'll have to check the locale, but I'm pretty sure they're all US Englisch. I would expect other things I type to be incorrect if the settings were incorrect. But I'll double-check this.
07-13-2021, 04:00 PM
(This post was last modified: 07-13-2021, 04:07 PM by KC9UDX.)
If I log in to a Debian client, via ssh as a valid user, 'validuser' uid 1007, and execute `su - test`, this results in the client's /var/log/auth.log:
Code: Jul 13 16:28:30 client login[15622]: pam_unix(login:session): session opened for user validuser by (uid=0)
Jul 13 16:28:30 client systemd-logind[335]: New session 436 of user validuser.
Jul 13 16:28:31 client systemd: pam_unix(systemd-user:session): session opened for user validuser by (uid=0)
Jul 13 16:28:51 client su: pam_unix(su-l:auth): authentication failure; logname=validuser uid=1007 euid=0 tty=pts/0 ruser=validuser rhost= user=test
Jul 13 16:28:53 client su: FAILED SU (to test) validuser on pts/0
Also, on the client,
Code: $ env | grep LANG
LANG=en_US.UTF-8
Thank you for your time with this. We are at the point I ended the last time I tried to determine this problem, at least a year ago (probably more).
I don't know how NIS works on a low level. I can't help but think that for some reason the Linux computers are using the wrong cipher when sending the password to the NIS server. In one of those rare moments of actually finding something useful with a web search, I discovered this today;tThis is on the NIS server:
Code: # $NetBSD: passwd.conf,v 1.3 2010/12/03 21:40:04 jmmv Exp $
#
# passwd.conf(5) -
# password configuration file
#
default:
localcipher = sha1
ypcipher = old
The more familiar I get with NetBSD, the more things I discover that I didn't know. I had no idea there was an /etc/passwd.conf.
I suspect 'ypcipher = old' is not what Linux is expecting. I'm not sure what to change it to. I'll probably start by trying 'sha1' and seeing what happens.
That is not the answer. At least, 'ypcipher = sha1' doesn't net success.
(07-13-2021, 04:00 PM)KC9UDX Wrote: Code: # $NetBSD: passwd.conf,v 1.3 2010/12/03 21:40:04 jmmv Exp $
#
# passwd.conf(5) -
# password configuration file
#
default:
localcipher = sha1
ypcipher = old
The more familiar I get with NetBSD, the more things I discover that I didn't know. I had no idea there was an /etc/passwd.conf.
I suspect 'ypcipher = old' is not what Linux is expecting. I'm not sure what to change it to. I'll probably start by trying 'sha1' and seeing what happens.
That is not the answer. At least, 'ypcipher = sha1' doesn't net success.
Where you find your 'passwd.conf' ? I have not this file on my NIS server ...
A NIS server use a Makefile, could you copy/send it, if nothing is confidential ?
You know that with this method, the support is not easy, so if something goes wrong between NetBSD and Linux, maybe it's a silly problem. I haven't check the links, but it could be an idea in your situation. So I propose to check the fundamentals things :
My link for the search : https://duckduckgo.com/?q=linux+passwd+c...=h_&ia=web
passwd.conf is in /etc/
I would say that the reason I didn't know about it, and the reason you don't have it is because it's new. But 2010 isn't new anymore.
I will not have access to the server to try anything for about a week. Frankly, I should not play around with that server anymore; it is very fragile. I lost my /usr hard drive a while ago and the entire system is unstable since. The hardware doesn't always boot anymore, and when it does boot I have to hotplug/unplug some hard drives (so that they exist during boot but not before, as to not boot). The "funny" thing is that I have to run a great and difficult distance back and forth several times from the serial console to the CPU hardware during that process. I took my slave NIS / DNS /etc server offline to build a new one, to resolve these problems. But I have not had an opportunity to work on that. So I will probably leave this Linux issue until I get the new server running. I should also rebuild the old slave NIS etc server so that I can bifurcate server responsibilities so that I do not take out DNS and NFS in the process of working out NIS. Losing DNS, and NFS, (and also NIS to a lesser degree) proves to be very disruptive.
I see that in the default Makefile.yp for NetBSD, there exists this comment:
# In addition, by adding shadow to the list of rules we support
# linux and solaris type shadow maps.
This is either something new, or more likely, something I've forgotten (along with most everything else I used to know about setting up this NIS server) because I did have Solaris clients in the past with no issue. In any case, this is likely the key to my issue, assuming that I don't have that configured correctly.
When I ran Solaris servers, I had a lot of books that explained these things in great detail. I should still have those books, somewhere. I should consult them, as NIS hasn't changed much in twenty years, and at least I might be able to refresh some knowledge.
Thank you for the links. I will take a look at them. I did do the same search in DuckDuckGo last night and didn't find anything that I thought was useful, but perhaps you spotted something that I did not.
08-04-2021, 03:20 PM
(This post was last modified: 08-04-2021, 03:21 PM by KC9UDX.)
I finally got time to deal with this again. I don't know how I missed the following in the default Makefile.yp:
Code: # Password maps in standard YP are insecure, because the pw_passwd
# field is accessible by any user. FreeBSD, NetBSD and OpenBSD have
# a common solution: a secure map (generated with makedbm -s) can
# only be accessed by a client bound to a privileged port.
#
# Uncomment out the following if you need compatibility with
# sites that don't support this feature.
#
#INSECURE?= yes
So this turned out to be very simple. I built a new NIS master (not because I needed to for this problem, but because I am decommissioning the old one) with the line
and suddenly I am able to log into my linux NIS clients as NIS users.
So probably the best solution would be to replace my two remaning linux clients with NetBSD. Unfortunately the one is restricted to using an old NVIDIA graphiccard which does not work in NetBSD, and the other needs to run Shotcut which I don't have time to see if I can get running in NetBSD. Fortunately at least for the foreseeable future, everyone but myself using the Linux machines is oblivious to NIS and ypcat.
I'm not one to "facepalm" much but this is a time where there probably isn't a better response. Systemd strikes again. LXDE will not work properly with NIS users, because it uses systemd to get some kind of variables from the user, which systemd can only find as a local user.
Code: dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument
This might be trivial to work around, but unfortunately it is a can of worms that I don't have time to deal with. So it's back to duplicating some NIS users locally.
(08-06-2021, 02:48 PM)KC9UDX Wrote: I'm not one to "facepalm" much but this is a time where there probably isn't a better response. Systemd strikes again. LXDE will not work properly with NIS users, because it uses systemd to get some kind of variables from the user, which systemd can only find as a local user.
Code: dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument
Hello,
I don't know if this the case here, but Ubuntu and Lightdm are not some good friends. It must be added « nscd ».
[quote pid="98956" dateline="1629281449"]
Hello,
I don't know if this the case here, but Ubuntu and Lightdm are not some good friends. It must be added « nscd ».
[/quote]
Debian (Raspberry Pi OS) but the situation may be the same (I'm not sure). So I'll look into that. Thank you.
Amazing! Took a lot of starting, restarting, and rebooting to get it to work, but it works!
|
Linux vs NetBSD NIS passwords
