☰

Usuário criado pelo Ansible no Windows, obtém ".EC2AMAZ-ELNOCH3" anexado ao nome de usuário

tag-icon • tag-icon windows ssh amazon-web-services ansible
Usuário criado pelo Ansible no Windows, obtém ".EC2AMAZ-ELNOCH3" anexado ao nome de usuário

Criei uma AMI do Windows Server 2019 usando Packer e Ansible como provisionador.

Adicionei um usuário jenkinse copiei arquivos SSH (chave pública/privada, conhecidos_hosts, chaves_autorizadas) para C:\Users\jenkins\.ssh.

Esta é a parte relevante do meu manual Ansible:

    - name: Ensure user jenkins is present
      ansible.windows.win_user:
        name: jenkins
        password: ***REDACTED***
        state: present
        groups:
          - Users

    - name: Create directory structure
      ansible.windows.win_file:
        path: C:\Temp\
        state: directory

    - name: Allow write and execute access to User jenkins
      ansible.windows.win_acl:
        user: jenkins
        path: C:\Temp
        type: allow
        rights: ExecuteFile,Write

    - name: Copy SSH keys
      ansible.windows.win_copy:
        src: ./files/.ssh
        dest: C:\Users\jenkins
      vars:
        ansible_become_user: jenkins
        ansible_become_password: ***REDACTED***
        # The tmp dir must be set when using win_copy as another user
        # This ensures the become user will have permissions for the operation
        # Make sure to specify a folder both the ansible_user and the become_user have access to (i.e not %TEMP% which is user specific and requires Admin)
        ansible_remote_tmp: C:\Temp

Eu inicio uma instância do EC2 a partir desta AMI.

Eu faço login com ssh:

ssh -i ~/.ssh/***REDACTED***.pem jenkins@ec2-***REDACTED***.compute.amazonaws.com -vvv

Não estou logado com a chave SSH, mas consigo fazer login com a senha.

Este é o log de depuração SSH:

debug3: load_hostkeys: loaded 1 keys from ***REDACTED***
debug1: Host 'ec2-***REDACTED***.compute.amazonaws.com' is known and matches the ECDSA host key.
debug1: Found key in /home/amedee/.ssh/known_hosts:161
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/amedee/.ssh/***REDACTED***.pem  explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/amedee/.ssh/***REDACTED***.pem
debug3: sign_and_send_pubkey: RSA SHA256:3OWWXRDheAUWZ9kxRiSJPvwFy1/Nh3//CdbLirDuFSM
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:3OWWXRDheAUWZ9kxRiSJPvwFy1/Nh3//CdbLirDuFSM
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: 
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
jenkins@***REDACTED***.compute.amazonaws.com's password:

Sou então saudado pelo Windows desta forma:

Microsoft Windows [Version 10.0.17763.1637]
(c) 2018 Microsoft Corporation. All rights reserved.

jenkins@EC2AMAZ-ELNOCH3 C:\Users\jenkins.EC2AMAZ-ELNOCH3>

Portanto, não estou logado como usuário, jenkinsmas como usuário jenkins.EC2AMAZ-ELNOCH3.

jenkinsTambém existe um usuário :

jenkins@EC2AMAZ-ELNOCH3 C:\Users\jenkins.EC2AMAZ-ELNOCH3>dir .. 
 Volume in drive C has no label.
 Volume Serial Number is E43B-9F7E

 Directory of C:\Users

12/11/2020  02:19 PM    <DIR>          .
12/11/2020  02:19 PM    <DIR>          ..
12/11/2020  01:51 PM    <DIR>          Administrator
12/11/2020  02:02 PM    <DIR>          jenkins
12/11/2020  02:22 PM    <DIR>          jenkins.EC2AMAZ-ELNOCH3 
12/12/2018  07:45 AM    <DIR>          Public
               0 File(s)              0 bytes
               6 Dir(s)  12,552,163,328 bytes free

e contém os arquivos SSH que copiei usando Ansible:

jenkins@EC2AMAZ-ELNOCH3 C:\Users\jenkins.EC2AMAZ-ELNOCH3>dir ..\jenkins\.ssh
 Volume in drive C has no label.
 Volume Serial Number is E43B-9F7E

 Directory of C:\Users\jenkins\.ssh

12/11/2020  02:02 PM    <DIR>          .
12/11/2020  02:02 PM    <DIR>          ..
11/13/2020  10:57 AM             1,221 authorized_keys    
11/13/2020  10:57 AM             1,675 id_rsa
11/13/2020  10:57 AM               401 id_rsa.pub
11/13/2020  10:57 AM             7,962 known_hosts        
               4 File(s)         11,259 bytes
               2 Dir(s)  12,552,081,408 bytes free

Quando tento uma conexão SSH com isso .EC2AMAZ-ELNOCH3anexado ao nome de usuário, não consigo fazer login com uma senha:

ssh -i ~/.ssh/***REDACTED***.pem jenkins.EC2AMAZ-ELNOCH3@ec2-***REDACTED***.compute.amazonaws.com -vvv
.
.
.
debug1: Next authentication method: password
jenkins.EC2AMAZ-ELNOCH3@ec2-***REDACTED***.compute.amazonaws.com's password: 
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
jenkins.EC2AMAZ-ELNOCH3@ec2-***REDACTED***.compute.amazonaws.com's password:

Quando estou logado como usuário jenkins.EC2AMAZ-ELNOCH3, copio os arquivos de C:\Users\jenkins\.ssh\para C:\Users\jenkins.EC2AMAZ-ELNOCH3\.ssh\e interrompo a conexão. Da próxima vez que eu fizer login com SSH, o login sem senha funcionará, o que prova que minhas chaves SSH estão corretas, mas estão no diretório errado.

Não quero que esse usuário jenkins.EC2AMAZ-ELNOCH3exista. Como posso ter certeza de que apenas o usuário jenkinsexiste?

Para sua informação, estou familiarizado apenas com Linux, portanto, se sua resposta contém terminologia avançada do Windows, explique. A última versão do Windows que usei foi o Windows 3.11. Esta também é a primeira vez que faço algo com o Ansible, mas sinto-me bastante confiante de que entendi a essência disso.

Responder1

jenkins@EC2AMAZ-ELNOCH3significa que você está logado como usuário jenkinsnomáquina EC2AMAZ-ELNOCH3.
C:\Users\jenkins.EC2AMAZ-ELNOCH3significa que o Windows descobriu que ao fazer login a pasta C:\Users\jenkinsjá existia, mas não era a correta para o usuário jenkins; portanto, o Windows teve que criar uma nova pasta de perfil de usuário.

Se você fizer login em uma máquina chamada barcom uma conta de usuário local chamada foo, sua pasta de perfil de usuário padrão será C:\Users\foo; mas se esta pasta já existir e o Windows não conseguir mapeá-la para a conta de usuário real (por qualquer motivo), ela criará uma nova; para contornar o nome da pasta duplicada, o Windows anexará o nome da máquina a ela, para que a nova pasta de perfil do usuário seja chamada C:\users\foo.bar.

Isso não tem nada a ver com o nome de usuário, que ainda é definitivamente foo.

Quanto ao motivo pelo qual isso aconteceu, não tenho ideia. Mas este é o comportamento padrão do Windows com pastas de perfis de usuário duplicadas.

Responder2

Usandocomunidade.windows.win_user_profile– Gerencia os perfis de usuário do Windows. Crie o diretório inicial logo após a criação do usuário e só então copie os arquivos.

É assim que se faz no Ansible:

    - name: Ensure user jenkins is present
      ansible.windows.win_user:
        name: jenkins
        password: ***REDACTED***
        state: present
        groups:
          - Users

    - name: Create a profile for user jenkins at C:\Users\jenkins
      community.windows.win_user_profile:
        username: jenkins
        name: jenkins
        state: present

    - name: Create directory structure
      ansible.windows.win_file:
        path: C:\Temp\
        state: directory

    - name: Allow write and execute access to User jenkins
      ansible.windows.win_acl:
        user: jenkins
        path: C:\Temp
        type: allow
        rights: ExecuteFile,Write

    - name: Copy SSH keys
      ansible.windows.win_copy:
        src: ./files/.ssh
        dest: C:\Users\jenkins
      vars:
        ansible_become_user: jenkins
        ansible_become_password: ***REDACTED***
        # The tmp dir must be set when using win_copy as another user
        # This ensures the become user will have permissions for the operation
        # Make sure to specify a folder both the ansible_user and the become_user have access to (i.e not %TEMP% which is user specific and requires Admin)
        ansible_remote_tmp: C:\Temp

informação relacionada