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

admin container ignores password set in user-data #65

Open
mchaker opened this issue Jul 30, 2022 · 3 comments
Open

admin container ignores password set in user-data #65

mchaker opened this issue Jul 30, 2022 · 3 comments

Comments

@mchaker
Copy link

mchaker commented Jul 30, 2022

Image I'm using:

metal-dev

Issue or Feature Request:

When setting a password in user-data.toml (via base64'd user-data as described in the docs), logging in to the local console (tty0) fails.

user-data pre-base64:

{
	"user": "bottlerocket",
	"password-hash": "(generated with mkpasswd -m yescrypt -R 11 password-goes-here)",
	"ssh": {
		"authorized-keys": [
			"ssh-ed25519 REDACTED my-key"
		]
	}
}

Once the admin container starts, it takes over tty0 (understandable) and attempting to log in with root (no password) fails.
However, the user specified in user-data (bottlerocket) and the password specified by password-hash in user-data do not work -- login always fails.

However, SSHing into the host/admin container using the provided ssh.authorized-keys works. Inspecting the user-data shows that the user data was successfully applied (base64 value matches what is expected).

@bcressey
Copy link
Contributor

Can you check /etc/shadow to see if the hash was applied?

The login failure can happen if you hash the password with an algorithm that glibc in AL2 does not support.

@mchaker
Copy link
Author

mchaker commented Jul 30, 2022

Interestingly enough, the hash in /etc/shadow is not the same as the hash I placed in user-data. 🤔

I followed the steps outlined in the following page: https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container

specifically, "Where the password-hash can be generated from:"

mkpasswd -m yescrypt -R 11 <desired password>

@bcressey
Copy link
Contributor

Interestingly enough, the hash in /etc/shadow is not the same as the hash I placed in user-data. 🤔

I'd first try using base64 -w0 on the input to ensure it's not getting a newline encoded partway through, though I don't know if that would manifest as this error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants