Right so the first problem is that just like you need to use the -i flag to point to the identity file when you use the ssh command, you ALSO have to do the same with the ssh-copy-id command, otherwise it is trying to find the key inside the docker container.
root@v-hass:/config# ssh-copy-id -i /config/.ssh/id_rsa [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/config/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
When I try to login to the RPi, it asks me to enter a password.
(gotta go now, will check back later)
Just an FYI you’re commenting on a guide that essentially explains the issues you’re facing, did you read it? For example:
Since you told the command to generate the key file inan unusual location (/config/.ssh) then you need to tell it where it is for all future ssh commands with -i. That includes ssh-copy-id as Andrew noted.
In addition I notice on your commands you don’t seem to be specifying -o UserKnownHostsFile or -o StrictHostKeyChecking=no on your command. Which means your command will work for now but break next time you update since the known_hosts file is in /root. Would recommend reading the section called “Handling the known_hosts file” for why that’s an issue and the options to fix it.
Don’t do this.
It doesn’t do what you think it does. There’s a user with the id “all”. You pinged them.
If it did do what you thought it did (pinged everyone) a moderator would certainly be here warning you to never do that again.
Replying on a post notifies everyone that follows that post, you don’t have to @ anyone for that. Just for future reference.
Hi @CentralCommand, thanks for stepping in and rubbing my nose in it!
I started over, but still not working.
This is what I did:
generated the key, stored in /config/.ssh/id_rsa with no password
copied the key with ‘ssh-copy-id -i /config/.ssh/id_rsa [email protected]’
If I understand it correctly: the -i /config/.ssh/id_rsa in the above command searches in that spot for the key.
What about the remote directory, is that of any importance?
Tested with ‘ssh -i /config/.ssh/id_rsa [email protected]’ which let’s me connect without asking a password.
When I try the command form HA shell:
root@v-hass:~# "ssh -i /config/.ssh/id_rsa [email protected] echo 1 | tee /sys/class/backlight/rpi_backlight/bl_power"
-bash: ssh -i /config/.ssh/id_rsa [email protected] echo 1 | tee /sys/class/backlight/rpi_backlight/bl_power: No such file or directory
and
root@v-hass:~# ssh -i /config/.ssh/id_rsa [email protected] echo 1 | tee /sys/class/backlight/rpi_backlight/bl_power
tee: /sys/class/backlight/rpi_backlight/bl_power: No such file or directory
1
OK, but that is a response from the Pi though, so the login is at least working. Permission denied is coming from the Pi saying that you can’t do that.
Try removing the entire command so you are just doing:
OK a few things, you don’t need to use sudo to echo, so you can happily remove sudo from the echo commands, you only need the sudo to write (tee) to the /sys/ tree.
Because Home Assistant (python) is trying to execute the command in bash, but needs to be told the " must be present in the command, so we use \" to tell whatever language we are coding with - that they must be escaped so that they pass through to the command line properly.
I’ve left the sudo there on the echo for now, until we verify we can get the command working as is.
I can push the lighting icons, the right one (on) turns blue briefly and switches back after a few seconds.
ATM the RPi screen is on, so even the icon doesn’t not represent the right state.
I mean HA runs in a container so its a different user no matter what even if they have the same name. Either way you’re ssh’ing as part of the command so you specify the user to use as part of that.
What does the log say? Did you set log level to debug for the integration? Should be components.command_line.switch I believe. Then it’ll log stdout and stderr to the log.
So what you copied there is from the warnings UI at the top of the log page. Which is really helpful usually but not in this case. The problem is what that UI does is highlight recent logs of error or warning level so you can easily see them, see how often they’re happening and get any additional info HA can provide about them.
But in this case we’re looking for a debug level log. That’s what will contain stdout and stderr when the command runs. To find that you have to look at the whole log file (or at the bottom of the log page) and fine the debug level line from when your sensor ran.
@CentralCommand Mike I’ve been successfully controlling a Raspberry Pi following the instructions in the OP.
Today that Rpi developed an issue that forced me to reinstall everything from scratch.
I then attempted to regenerate the ID file, and reconnect the Rpi with HA.
Here are the steps:
Created the keys pair
ssh-keygen -t rsa
Was asked where to save the file:
/config/.ssh/id_rsa
Did NOT add a passphrase. Then tried to copy the public key to the Rpi:
That is normal behavior. ssh warns you that the public key of the host you are trying to connect to has changed. Since you reinstalled the host, and in the process generated new keys, it should be safe to assume there is no man-in-the-middle attack and just do
Thank you @ondras12345
I executed the command, then started the whole process from scratch.
Unfortunately I was getting the same error.
It turns out that I needed to delete the key manuall by using:
nano /config/.ssh/known_hosts
Then I started the process again and it all works great now.
Thank you for your guidance, problem sorted!