Markos wrote: > Bob Proulx escreveu: > > passwd: files nis > > group: files nis > > shadow: files nis > > > > hosts: files dns > > That was the problem! Yay! > I simply did what you suggested and now I can log in clients with or > without the server. :^) Good. > > Note: The use of 'shadow' depends upon the setting of MERGE_PASSWD. > > Note: The hosts setting probably isn't the problem but can be if > > people set it to nis. > > I imagine that you're referring to the variable MERGE_PASSWD in /var/ > yp/Makefile at server. > > In my case it is set to "false" > MERGE_PASSWD=false > > I think it is better to leave it as is? Yes. That is the configuration I mentioned. What that does is to take the password field value from the shadow file and merge it back into the traditional location in the password file. In many ways it does not really matter whether you operate with MERGE_PASSWD to be either true or false. But if everything is working for you with it false then I would leave it false. It is really only needed if you have some obsolete nis/yp network client that does not understand about the /etc/shadow file. In the beginning hashed passwords were in the /etc/passwd file. But then crackers could take the passwd file away to a parallel cracking machine (now known as The Internet) and crack the passwords hashed values offline. To prevent this the passwords were removed from the password file and moved into a different file. They were moved into the /etc/shadow file. That shadow file was made unreadable to normal non-root processes. This prevented the hashed passwords from being known and prevented them from being cracked offline. All good. But then there is the problem of how to deal with NIS/yp which needs that information over the network. So the idea of keeping them private in an unreadable /etc/shadow does not work with nis/yp. Therefore with NIS the shadow file is made available. But it puts a small barrier in place that the source must be a root priviledge port below 1024. That will prevent students in a school's computer lab from being able to easily access the shadow.byname map since they won't have local root. But it is very easy to be root on your own device and then use a root priviledge port and get that data. Try: # ypcat shadow.byname # as root, data available $ ypcat shadow.byname # as non-root normal user, not available Therefore that barrier is almost nothing at all. It doesn't hurt. But it doesn't prevent the values from being known. This means that with NIS for passwords it is important to use a large hash value. The old standard 56 bit DES-based crypt(3) is way too short. The md5 would be fine on a local private testing network. But larger harder to crack values such as sha-256 or sha-512 would be recommended if there was any concern over password cracking. If there isn't then that is okay. The Takeaway: Be aware that NIS/yp exposes the hashed passwords to the local network. > > Because I think if you were to try to use root account info from > > the network then you would have a bootstrapping problem because > > the system would not be able to bootstrap itself going. See also > > the MINUID variable which scrapes the presence of the root and > > other system acounts out of the master copy of the file before > > giving it to clients. > > In /var/yp/Makefile > > MINUID=1000 Yes. That is the variable. It prevents local accounts less than 1000 in the /etc/passwd file from being used for NIS clients. NIS clients will have their own local copy of those anyway. > The network has only an educational purpose and is not continuously > connected to the Internet. Sounds good. Welcome! Learn away. (smile) > So I believe there is no need to keep copies of the passwd, group and > shadow in another location besides the /etc. > > This would generate an additional task for me to manage the network. > > But your tip was very important in my learning. Sounds good. Just making that information available so that you would be aware of the possibility. > In the beginning I was lost with so much information. Sorry. (frown) > I think the answers of other more experienced users in a thread not only > serve to provide technical information but also, and especially, offer a > sense of confidence and safety for the newbies to feel that they are not > alone. Yes! (smile) > And being able to, calmly, connect information and build a global > vision. > > Thanks again for your contribution. Happy to help! Bob
Attachment:
signature.asc
Description: Digital signature