I am running HA in Docker on Windows 10, using Linux containers. I also have Portainer running as a seperate container so I have root access to my HA container via Exec Console. I use docker-compose to run my containers and in my docker-compose file I have my HA config directory mapped to a local windows directory.
What I want to Do:
ssh to a pi zero w on my LAN, without having to enter a password, and then execute a python script on said pi, from inside home assistant using a shell command.
How I Am Doing It:
Via Portainer, I launch a bash shell as root and create my ssh keys.
I save the private key to my HA config folder.
I copy the contents of the public key to my raspberry pi using the command
nano /home/pi/.ssh/authorized_keys
What Actually Happens:
When I run:
ssh -i id_rsa -o 'StrictHostKeyChecking=no' [email protected]./switchbot-cmd.py xx:99:xx:xx:xx:xx on
I get the following error:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0755 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_rsa": bad permissions
I tried to chmod 600 id_rsa inside the bash shell but the change didn’t take.
Similarly I performed chmod 600 id_rsa inside Cywgin64. Weirdly in Cywgin64 it shows the correct (600) permissions but in Portainer it just shows the original incorrect permissions.
I have tried everything that I can think of at this point. Can anyone help me fix this?
This may be due to the different way windows and linux handle file permissions. You have a file on a windows system which is mapped into a linux docker container - I suspect that this situatin will be described somewhere in the docker docs
I read this is related to sshd strictmodes.
Disabling this may prevent error but i don’t know security implications
StrictModes Specifies whether sshd(8) should check file modes and ownership of the user’s files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is yes . Note that this does not apply to ChrootDirectory , whose permissions and ownership are checked unconditionally.
And yes, probably cannot change permissions because linux docker in windows host but could change sshd config if desired
I saw this too and I think that’s why all my ssh nodes begin -o StrickHostChecking=no. Include that right after the ssh and see what happens.
Also, I also run core in docker with portainer and used the same method to enter the container shell and generate and share keys with a remote computer.
In my case, my key is named ssh-node-red. I preshared this key from the container shell with all the hosts I planned to ssh into. Note I do not have it in quotes, so maybe try that? Edit: try adding the “/data/” in the keypath. Here’s where mine are stored given my keypath above:
Edit edit: I’m just running Docker on Ubuntu 20.04, not windows.
After a couple more days of investigation I finally just bit the bullet and got rid of Windows and I am now running docker on Ubuntu. I can now successfully execute my shell commands. Happy days!