Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: remove `rancher.password` - and replace with autologin, and make ssh keys simpler/more obvious #1563
#1537, and password hash cracking as a service, make it somewhat clear that setting a password is a very bad idea.
I'm proposing to make setting and using a password a path of last resourt, and to make more secure settings as easy as possible.
however, to cater for newer non-cloud-config users, who might boot from iso, and then type
Its worth using a variation of what @peterrus said : " it would be pretty dangerous to have rancher exposed to the internet with rancher:rancher. what I am doing now: after booting the iso; run 'passwd' press [enter] when asked for the current password, and set a new password." in the docs.
hopefully there is no cloud solution where you cannot set an ssh key :/
changed the title
remove `rancher.password` - and replace with autologin, and make ssh keys simpler/more obvious
Jan 31, 2017
Seems good! One, somewhat unrelated, question though:
I am a cloud-config user and I also boot from iso. After my first boot from iso I set the ssh password as described above and then scp my cloud-config file from my workstation into the rancheros instance. Then I run ros-install -c cloud-config-I-just-scpd.yml -d /dev/whatever.
So I personally would just need autologin in the iso, after installing rancheros I don't think anyone should use autologin as that would make your system a lot more insecure. (Then again, if it is really needed, one could use the rancher.password boot parameter)
My team [now] deploys devices with RancherOS that could be in the field for a very long time (longest is 2 years running an old Ubuntu).
My fear is that with this removed should a deployment device be re-provisioned, or we switch deployment services, etc etc... If SOMEHOW our ssh key is lost ---- then we're SOL without a password.
@killerspaz idk - I presume this password is a secure, non-memorable long string, which is different foreach server? - that you're only able to remember by putting it into some secrets store - in which you'd presumably also be able to keep the private ssh key.
Whereas on the server, we're talking about 2 entry-keys kept in the same persistence partition - the password helps if someone's deleted the key - or blasted over it (I've done this with a careless
That makes me wonder if ssh has a way to place authorized_keys somewhere in
Well, the assumption is we're talking about a single (or clustered) instance, and a handful of devices to maintain.
We're literally talking about a magnitude of 100's of thousands of deployments. And actually we use a memorable string for simplicity (although memorable, it's not a basic password).
Unique passwords (or ssh keys) for .5-1MM units will not be fun.
@killerspaz Do these devices have net access? How about creating a service that will check if the device's mac address exists over an api, if the mac shows up then it pulls a new key and puts it in the cloud config? (there are other methods of ensuring they're connected to your server and not mitm for this key you could also add for extra security)
It's similar to automated firmware updating that we've done.