Ansible erstellte Benutzer unter Windows, bekommt ".EC2AMAZ-ELNOCH3" an den Benutzernamen angehängt

Ansible erstellte Benutzer unter Windows, bekommt ".EC2AMAZ-ELNOCH3" an den Benutzernamen angehängt

Ich habe ein Windows Server 2019 AMI mit Packer und Ansible als Provisioner erstellt.

Ich habe einen Benutzer hinzugefügt jenkinsund SSH-Dateien (öffentlicher/privater Schlüssel, bekannte Hosts, autorisierte Schlüssel) nach kopiert C:\Users\jenkins\.ssh.

Dies ist der relevante Teil meines Ansible-Playbooks:

    - 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

Ich starte eine EC2-Instanz von diesem AMI aus.

Ich logge mich per ssh ein:

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

Mit dem SSH-Schlüssel bin ich nicht angemeldet, kann mich aber mit dem Passwort anmelden.

Dies ist das SSH-Debugprotokoll:

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:

Anschließend werde ich von Windows folgendermaßen begrüßt:

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

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

jenkinsIch bin also nicht als Benutzer , sondern als Benutzer angemeldet jenkins.EC2AMAZ-ELNOCH3.

Außerdem existiert noch ein Benutzer jenkins:

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

und es enthält die SSH-Dateien, die ich mit Ansible kopiert habe:

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

Wenn ich versuche, eine SSH-Verbindung herzustellen und dies .EC2AMAZ-ELNOCH3an den Benutzernamen anhänge, kann ich mich nicht mit einem Kennwort anmelden:

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:

Wenn ich als Benutzer angemeldet bin jenkins.EC2AMAZ-ELNOCH3, kopiere ich die Dateien von C:\Users\jenkins\.ssh\nach C:\Users\jenkins.EC2AMAZ-ELNOCH3\.ssh\und trenne die Verbindung. Beim nächsten Anmelden mit SSH funktioniert die passwortlose Anmeldung, was beweist, dass meine SSH-Schlüssel zwar korrekt sind, sich aber im falschen Verzeichnis befinden.

Ich möchte nicht, dass dieser Benutzer jenkins.EC2AMAZ-ELNOCH3existiert. Wie kann ich sicherstellen, dass nur dieser Benutzer jenkinsexistiert?

Zu Ihrer Information: Ich bin nur mit Linux vertraut. Wenn Ihre Antwort also fortgeschrittene Windows-Terminologie enthält, erläutern Sie diese bitte. Die letzte Windows-Version, die ich verwendet habe, war Windows 3.11. Dies ist auch das erste Mal, dass ich etwas mit Ansible mache, aber ich bin ziemlich zuversichtlich, dass ich das Wesentliche verstehe.

Antwort1

jenkins@EC2AMAZ-ELNOCH3bedeutet, dass Sie als Benutzer jenkinsauf demMaschine EC2AMAZ-ELNOCH3.
C:\Users\jenkins.EC2AMAZ-ELNOCH3bedeutet, dass Windows beim Anmelden festgestellt hat, dass der Ordner C:\Users\jenkinsbereits vorhanden war, es sich jedoch nicht um den richtigen für den Benutzer handelte jenkins. Daher musste Windows einen neuen Benutzerprofilordner erstellen.

barWenn Sie sich bei einem Computer mit dem Namen mit einem lokalen Benutzerkonto namens anmelden foo, ist Ihr Standard-Benutzerprofilordner C:\Users\foo. Falls dieser Ordner jedoch bereits vorhanden ist und Windows ihn (aus welchen Gründen auch immer) nicht dem tatsächlichen Benutzerkonto zuordnen kann, wird ein neuer Ordner erstellt. Um den doppelten Ordnernamen zu umgehen, hängt Windows den Computernamen daran an, sodass der neue Benutzerprofilordner heißt C:\users\foo.bar.

Dies hat nichts mit dem Benutzernamen zu tun, der immer noch definitiv ist foo.


Ich habe keine Ahnung, warum das passiert ist. Aber das ist das Standardverhalten von Windows bei doppelten Benutzerprofilordnern.

Antwort2

Verwenden voncommunity.windows.win_user_profile– Verwaltet die Windows-Benutzerprofile. Legen Sie das Home-Verzeichnis direkt nach der Benutzererstellung an und kopieren Sie erst dann die Dateien.

So geht's in 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

verwandte Informationen