Bug 1063518

Steps taken:

1) engine-image-uploader upload --export-domain DefaultExport /usr/share/rhel-guest-image-6/rhel-guest-image-6-6.5-20140116.1-1/

2) Imported template from export domain.

3) Created a VM based on the template.

4) Selected run once for the VM

5) Enabled cloud-init options.

6) Set:
   - Password for root
   - SSH public key
   - Timezone

7) Booted VM

When accessing the console I noted that:

- I was prompted to immediately change the root password (after entering the current one set via cloud-init).

- The time zone was set correctly.

- There is no cloud-user account.

- /root/.ssh/authorized_keys looks like this (truncated):

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"root\" rather than the user \"root\".';echo;sleep10" ssh-dss AAAAB3NzaC1....

OK, so with Joey Boggs I have ascertained that the problem here is that cloud images (including our own) typically explicitly discourage the use of the "root" user.

Usually this is handled by instead creating a user (e.g. "cloud-user") and injecting the SSH key(s) into that account.

I think what could/should be happening here is that when the user specifies an SSH key in the UI RHEV should be taking that as a cue to create the "cloud-user" account and inject the SSH key there, not just inject it into root.

the current behavior is indeed to use the root user. Scott, what do you think about comment #2?

Does the creation of a static user called "cloud-user" make sense in the context of RHEV where cloud-init is used?  Would it be possible to enable the user to specify a user account that may or may not exist within the packaged template?  if it doesn't exist, create it, if it does exist, modify it?  I assume the use of root has security/best practice implications?

(In reply to Scott Herold from comment #4)
> Does the creation of a static user called "cloud-user" make sense in the
> context of RHEV where cloud-init is used?  Would it be possible to enable
> the user to specify a user account that may or may not exist within the
> packaged template?  if it doesn't exist, create it, if it does exist, modify
> it?  I assume the use of root has security/best practice implications?

Personally I think the security consideration is kind of moot given that typically the "normal" user is given sudo access to any command in these types of deployments but the reality is that most commonly available cloud images with cloud-init baked in including our own expect the use of a non-root account and lock down root.

Unfortunately which "normal" user account they use varies widely (examples include "cloud-user", "ec2-user", "fedora"). I think the best option is probably to inject the key into both root *and* one of the "known" user accounts if it exists. I'm not sure if there is an easy way to determine before boot whether the image includes a user account and which one it is (possibly on the OpenStack side a case could be made for adding this to image metadata in glance if it's not already there).

The only problem with using root is the expectations from cloud-init and default lock down of the account. 
If we make the user optional in UI we still should allow root if someone prefers that, but we have to disable the lock down.

I'd suggest to address the lock down issue in 3.3.z - it renders the feature unusable really.
And optional user account in 3.4/3.5

(In reply to Michal Skrivanek from comment #6)
> The only problem with using root is the expectations from cloud-init and
> default lock down of the account. 
> If we make the user optional in UI we still should allow root if someone
> prefers that, but we have to disable the lock down.

Next problem there is that I'm willing to bet different images implement the lock down in different ways :(. I think it's better to allow root as an option and if the user selects that assume they know their image supports it, I don't think we can reliably remove the lock down.

> I'd suggest to address the lock down issue in 3.3.z - it renders the feature
> unusable really.
> And optional user account in 3.4/3.5

Agree, if you know what you are doing you can pretty easily inject to the correct account via a custom cloud-config script but if you are coming from a data center virt background and not already familiar with cloud-init this is going to be pretty confusing/unusable.

The fix will present:
1. root will be able to login via ssh public key and password without the "user root" message
2. root will not have to change password the first time it login

Shahar, doesn't it miss backport to 3.4?

pending backport to 3.4 and 3.3 of the fix for root user, and open a follow-up bug for the optional user name field to use cloud-user instead of root

opened follow up bug 1076917

All referenced patches have been merged, shouldn't this be on modified?

Verified in rhevm-3.4.0-0.15.beta3.el6ev.noarch (av7).

Verified with Linux-based guest (Fedora 19) with installed cloud-init-0.7.2-7.fc19.noarch.

Verified according to comment #8:

> 1. root will be able to login via ssh public key and password without the
> "user root" message

Verified. SSH public key authentication works fine now.

In GUI, I put the client's (mine) public SSH key to the run once dialog, checked "Regenerate SSH Keys" and started the guest.
When the guest was up, I logged in via SSH:
-~-
$ ssh root.30.40
The authenticity of host '10.20.30.40 (10.20.30.40)' can't be established.
ECDSA key fingerprint is e3:1c:94:34:8e:26:0d:cc:28:e7:1b:03:cf:8f:dd:74.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.20.30.40' (ECDSA) to the list of known hosts.
Last login: Wed Apr 30 14:00:41 2014
[root@f19 ~]#
-~-

> 2. root will not have to change password the first time it login

Verified. Now there is no message which forces the root user to change the password (no matter how simple the password is).

In GUI, I set the root password in the run once dialog and then started the guest.
When the guest was up, I logged in via SSH:
-~-
$ ssh root.60.78
root.60.78's password: 
Last login: Wed Apr 30 14:15:00 2014
[root@f19 ~]# 
-~-

Closing as part of 3.4.0