Okay, I get that. I actually hadn't thought about that aspect of it. But there's still a couple of things that don't make sense to me. One is that the authorized keys file is still read-writable by the "developer" group, which the existing user *and* the new users are in. And that's the only one that really matters, right? I have the private key here on my laptop. SSH verifies that public key entry against my private key, and so should be good. Also, why would the existing user, "centos", who could log in before, no longer be able to?
Ooooh.... wait..... after my 'user' play I ran a play that recursively changed permissions on /home/centos to 2775. I bet that caused this. *facepalm* -- Todd On Tuesday, August 28, 2018 at 10:30:08 AM UTC-4, Kai Stian Olstad wrote: > > On 28.08.2018 16:14, [email protected] <javascript:> wrote: > > Interesting. I know that SSH is strict about the permissions applied, > > but > > I've never heard of it checking the owner/group of the files. > > ssh is enforcing that the owner is the only one that with access, by > checking the mode, it don't care about the owner id or group id. But the > filesystem will, it wont let user1 use user2 files/directory if they > have 0400/0600/0700. > > -- > Kai Stian Olstad > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/38832eff-74a4-4964-805f-11e4f3e9cdc4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
