unable to login as kitchen user
it seems that in the latest version of kitchen-docker the password has been removed from the kitchen user. this is a problem because unlocking(https://github.com/test-kitchen/kitchen-docker/commit/ed387b2b4a1237b04d7c753ef2a7ad038078ab67) the user doesn't actually seem to work. everytime time I try to log in i get authentication failure.
is there a work around for this to add a password back?
What base image are you using that the unlock doesn't work?
I am using the official centos base image(https://hub.docker.com/r/_/centos/) tag:7.1.1503
Hmm, does it work with just centos-7 as the platform? That's what the automated tests use so I'm relatively confident that it works :)
Could be related to #228
i believe the problem is that this command https://github.com/test-kitchen/kitchen-docker/blob/master/lib/kitchen/driver/docker.rb#L259 does not create a password less user. it creates a user that cannot log in with a password and only with a key. I am able to log in with a key just fine(on my mac). I am not able to use a password to log in though.
this would not be a problem, however on windows laptops(using kitchen-docker in a vagrant box) the auto generated ssh keys are generated with incorrect permissions so they are ignored. it would be great to have the password option for this situation, or have the user truly created without a password
@warroyo That is intentional, the driver also sets up a key automatically and tells kitchen to use it. A user with no password is locked and so can't be used even with a key (which is the bug I was fixing in the commit you mentioned). Are you saying you see the file permissions set here https://github.com/test-kitchen/kitchen-docker/blob/master/lib/kitchen/driver/docker.rb#L268 not working?
Maybe it's a line endings issue, that has bitten me a few times before. I would bet sshd won't accept windows line ending just to be difficult :)
@coderanger i think the key not working on windows is more of a vagrant issue, the line mentioned above is working correctly. the file .kitchen/docker_id_rsa that is auto generated is the one being created with bad permissions which causes the below error when running kitchen login. this is a standard linux error when trying to use a private key with to open of permissions. the problem is that when a directory is shared with vagrant on windows the permissions are unable to be changed.
the real solution is to probably found out what is causing the vagrant file sharing permissions issue on windows and fix the permission on the key, however it would be nice to be able to set a password on the kitchen user to be able to work around this vagrant file sharing issue.
Permissions 0777 for '/projects/cookbooks/chefdk/.kitchen/docker_id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
edit:
it looks like this is the line that seems to be ignored when running on windows in vagrant
https://github.com/test-kitchen/kitchen-docker/blob/master/lib/kitchen/driver/docker.rb#L173
it looks like adding this to the driver config will be a fairly easy work around.
provision_command: "echo 'kitchen:kitchen'|chpasswd"
How exactly are you running this? You've mentioned that Windows, Vagrant, and Docker are involved, but in what configuration? It sounds like you're running kitchen inside Vagrant, which isn't needed. Just set up Docker's remote API (or use something like docker-machine) and run Kitchen on your actual workstation. VirtualBox's sharedfolders FS driver does have issues with file permissions, but the best solution is definitely a "don't do that". All Chef dev tools should run fine on Windows :)
As for adding back passwords, the reason I removed it is that having a single, static password for all kitchen-created containers is a security risk. This is the same reason Vagrant removed it's "one SSH key to rule them all". People sometimes leave these containers on the internet, and they could be picked up by automated scanners. If I added it back, it would have to be a randomized password, which would be pretty annoying to use since passwords never worked for automatic kitchen login in the first place (you had to type them in manually).
And yeah, you can do this locally as long as you understand the security issues I mentioned. Maybe make the password something other than kitchen to buy yourself just a bit of obscurity?
I have a pre-built vagrant box with all of the necessary things installed for developing cookbooks etc. so that a new team member can just pull this down and be ready to start testing and writing cookbooks. so the stack is windows/mac, running vagrant(virtual box) then docker inside of the vagrant box for kitchen-docker. As for running on my actual workstation I know this is possible, but it has been faster for onboarding.
That makes sense for removing the passwords for security reasons. I think i will just stick to the workaround for now since these container are not internet exposed at all.
Fair, I don't think there is much I could do to make this situation any smoother. You could also set your Vagrant images up so they bind-mount a "real" file system over the kitchen folders.
On Mac OS X, don't know if related, permissions are not set correctly for .kitchen/docker_id_rsa, getting 644. So kitchen login to docker fails with WARNING: UNPROTECTED PRIVATE KEY FILE!
On Windows 10 w/ Hyper-V, I had issues with kitchen login because Windows 10 installed a broken ssh client. Both kitchen and vagrant were trying to use that as it was picked up earlier in the path. Once removed, vagrant worked, but kitchen failed. Vagrant was using their own embedded ssh, while Kitchen seem to try to find it in the path.