Created Users on EC2 Instance, Now I Can't SSH There

[ttw...@gmail.com]

I've run a playbook that creates an EC2 instance. The AMI used to create the instance is using CentOS and installs an SSH key so that I can ssh in as username "centos" without a password. It works fine. But now I've created a subsequent playbook that configures the new server. One of the things it does is create two new users:

- name: Create Users

  user:

    name: '{{ item.name }}'

    home: /home/centos

    create_home: yes

    groups:

      - wheel

      - developer

    append: yes

    comment: "CastleBranch Developer Admin"

    state: present

  loop: "{{ ansible_server_users }}"

Notice that it's creating the new users with /home/centos as the home directory. I thought it would just set that as home directory for my new user, and that I would then be able to ssh in as that new user, using the same keys. However, after running this I am now unable to login as *anything*. Not the new users, and not "centos" either.

I can kill the instance and create it anew. That's not a problem. But anyone have any guesses as to what happened that I can't login now?

--

Todd

[Jonathan Lozada De La Matta]

Looks like you are creating the user but, not putting the public keys in their home dir.

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d9fa9364-a77e-45da-8fc0-3aac0f6801fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jonathan lozada de la matta

AUTOMATION CONSULTANT - AUTOMATION PRACTICE

Red Hat Consulting Services

jloz...@redhat.com   

 

[ttw...@gmail.com]

The public keys are already there, since it's re-using the /home/centos directory. But it's not using those keys when logging in as the new user, the keys that are (theoretically) in the new user's home directory.

--

Todd

[Kai Stian Olstad]

On 28.08.2018 15:49, ttw...@gmail.com wrote:
> The public keys are already there, since it's re-using the /home/centos
> directory. But it's not using those keys when logging in as the new
> user,
> the keys that are (theoretically) in the new user's home directory.

ssh is very strict on permission. ~/.ssh need to have mode 0600, and the
private key require mode 0400 or 0600.

So sharing the same home folder among several user to reuse .ssh wont
work since only one user can be the owner of a file/directory at any
given time.

--
Kai Stian Olstad

[ttw...@gmail.com]

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.

--

Todd

[Kai Stian Olstad]

On 28.08.2018 16:14, ttw...@gmail.com 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

[Karl Auer]

Which is the point of the permissions :-)

--
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 ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2b59bf6f115eabf09661d01b3f0d7939%40olstad.com.

For more options, visit https://groups.google.com/d/optout.

--

Karl Auer

Email  : ka...@2pisoftware.com
Website: http://2pisoftware.com

GPG/PGP : 958A 2647 6C44 D376 3D63 86A5 FFB2 20BC 0257 5816
Previous: F0AB 6C70 A49D 1927 6E05 81E7 AD95 268F 2AB6 40EA

[ttw...@gmail.com]

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