Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: remove `rancher.password` - and replace with autologin, and make ssh keys simpler/more obvious #1563

Closed
SvenDowideit opened this issue Jan 30, 2017 · 9 comments

Comments

@SvenDowideit
Copy link
Contributor

commented Jan 30, 2017

#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 ros install -d /dev/sda - I think we should also default to autologin on all physical consoles. (and then once you're using a cloud-config, we invert the default)

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 :/

NOTE: this is a proposal - and I'm hoping that if there are use cases that cannot be done without passwords, that they will be brought up here.

@SvenDowideit SvenDowideit added this to the v0.9.0 milestone Jan 30, 2017

@SvenDowideit SvenDowideit changed the title remove `rancher.password` - and replace with autologin, and make ssh keys simpler/more obvious RFC: remove `rancher.password` - and replace with autologin, and make ssh keys simpler/more obvious Jan 31, 2017

@peterrus

This comment has been minimized.

Copy link

commented Feb 6, 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)

@killerspaz

This comment has been minimized.

Copy link

commented Feb 9, 2017

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.

@SvenDowideit

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2017

@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 scp -r .ssh rancher@remote:~/ too.

That makes me wonder if ssh has a way to place authorized_keys somewhere in /etc for a backup path - would that satisfy the use case you're worried about?

@killerspaz

This comment has been minimized.

Copy link

commented Feb 10, 2017

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.

@SvenDowideit

This comment has been minimized.

Copy link
Contributor Author

commented Feb 11, 2017

A single password for thousands of deployments, some of which are kept for years? Are you sure a backup ssh key stored separately from the rancher user's one wouldn't serve you better?

@killerspaz

This comment has been minimized.

Copy link

commented Feb 11, 2017

If it comes to it, we'll have to figure something out; we love RancherOS and won't be going anywhere anytime soon. Just have to appease the team(s), you know?

I think they don't trust themselves, which has landed the practice of a known strong password.

@SvenDowideit SvenDowideit modified the milestones: v0.10.0, v0.9.0 Mar 13, 2017

@themotu

This comment has been minimized.

Copy link

commented Mar 31, 2017

@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.

@killerspaz

This comment has been minimized.

Copy link

commented Mar 31, 2017

The devices will have internet, but they're expected to have around 85% airgap. So, we try to act as if Internet isn't a thing, as it cannot be reliable.

@SvenDowideit

This comment has been minimized.

Copy link
Contributor Author

commented Sep 18, 2017

RancherOS adds a syslinux menu from which you can select auto-login, but rancher.password still exists.

@niusmallnan niusmallnan modified the milestones: v1.3.0, unscheduled Feb 13, 2018

@niusmallnan niusmallnan removed this from the unscheduled milestone Dec 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.