remote ssh login possible using well known password by default

[Piotr]

The CirrOS image is frequently used for testing in our Openstack based development datacenter. Unfortunately, users sometimes forgot to remove instances on their projects. When the instance is attached to public network, and security group allow remote SSH access, the instance became an open gateway for privilege escalation. (In this case gaining access to datacenter network.)

Perhaps it would be better when the random password is generated on boot, then it's printed on the console?

I've found another bug related to default password #1454144

So finally the random password should consist from capitals, letters and digits.

Usually, such remote system access bugs are classified as critical security issues. In other hand the Cirros is intended for testing and such access is configured intentionally. Anyway let's discuss to find a balance between security and usability.

[Dr. Jens Harbott (j-harbott)]

Having a fixed username/password combination in cirros is a feature that is used in various automated testing setups. Having a random password would make this much more complicated.

It is a bug to deploy cirros in an environment where public SSH access is possible.

[Scott Moser (smoser)]

By default I think it makes sense to have cirros have a well known user-name and password.
I'm not opposed to the suggestion of having it generate a random one or disable password auth entirely.

we'd just have to figure out how to do this.
The easiest way to do it would be to add a command that runs and does what we want, and then could either
a.) allow the user to invoke that command from user-data (this might expose a race condition unless we made sure it could happen before ssh daemon up).

b.) invoke the command based on some other input (kernel command line perhaps?) This wouldnt change the default behavior though.

[Scott Moser (smoser)]

Note that 'a' is probably possible right now via 'sed' editing of /etc/shadow.
Just adding an 'x' to the password field (2nd field) would do it, or deleting that field entirely or making it a '*'. Anything not a valid 'crypt()' is going to result in no long.