7 Nov
2018
7 Nov
'18
6:40 a.m.
On 11/06/2018 03:29 PM, Dan Cross wrote:
It wouldn't do it, but I guess it depends on how
much you trust your
environment and your users etc.
That's not quite what I had expected, but it is an answer to the
question that I asked.
If you're intent on using a network directory
service, I'd bite the
bullet and invest in setting up Kerberos and LDAP. The thing with pairing
Kerberos (for authentication) with NIS is that while you'll have decent
authentication security, nothing prevents a malicious third party from
modifying the answer from `ypserv` for some user to set the UID to 0,
thus making that user root.
ACK
If authentication is happening by users typing
passwords into SSH clients,
which then get sent to SSH servers to be validated against the KDC on
machines that have been so cracked, an attacker can steal passwords by
subverting the SSH server processes.
What would the user be typing their password into? The SSH client to
authenticate to the SSH daemon? Or kinit (et al) on the remote system?
I would have thought that the ideal situation would be for the user to
kinit on their client, then authenticate to ssh using Kerberos.
I'm guessing they would need to do something to extend their Kerberos
tickets therefrom. I don't know if they would need to kinit on the
remote system, or if there's something like agent forwarding for Kerberos.
However, if you trust your users not to do that and
you're on a
relatively small, self-contained and decently secured network, then it
may be fine.
ACK
From what you described earlier I think generating
text files and
distributing them around (possibly with rdist or rsync) and pairing that
with kerberos would be less work and more robust.
Possibly.
Though I don't consider that to be a central directory server. Instead
I consider it to be replicating information locally. I'm sure it has
it's pros and cons.
--
Grant. . . .
unix || die