![Ansible erstellte Benutzer unter Windows, bekommt ".EC2AMAZ-ELNOCH3" an den Benutzernamen angehängt](https://rvso.com/image/760989/Ansible%20erstellte%20Benutzer%20unter%20Windows%2C%20bekommt%20%22.EC2AMAZ-ELNOCH3%22%20an%20den%20Benutzernamen%20angeh%C3%A4ngt.png)
Ich habe ein Windows Server 2019 AMI mit Packer und Ansible als Provisioner erstellt.
Ich habe einen Benutzer hinzugefügt jenkins
und 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>
jenkins
Ich 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-ELNOCH3
an 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-ELNOCH3
existiert. Wie kann ich sicherstellen, dass nur dieser Benutzer jenkins
existiert?
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-ELNOCH3
bedeutet, dass Sie als Benutzer jenkins
auf demMaschine EC2AMAZ-ELNOCH3
.
C:\Users\jenkins.EC2AMAZ-ELNOCH3
bedeutet, dass Windows beim Anmelden festgestellt hat, dass der Ordner C:\Users\jenkins
bereits vorhanden war, es sich jedoch nicht um den richtigen für den Benutzer handelte jenkins
. Daher musste Windows einen neuen Benutzerprofilordner erstellen.
bar
Wenn 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