Skip to main content
added 1328 characters in body
Source Link
Torxed
  • 3.7k
  • 7
  • 33
  • 49

Most likely this is because your startup script will run in a root environment by default. Assuming that you're using ~/.ssh/id_rsa.pub as your mode of authentication (You never mentioned that you're using a password and using such a thing while automate is often a bad idea anyway, so i'll assume key authentication).

Then I'll go ahead and assume even further that you haven't allowed the (or even have a) root key generated that is trusted on your laptop?

You have two options in this case.

  1. run ssh-keygen as root, and copy the content of /root/.ssh/id_rsa.pub to your /home/<user>/.ssh/authorized_keys file.

or

  1. change your command to /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0"

The second is neater since it uses your users certificate that you already know works.

debian startup order and network connectivity issue

Most likely (after reading your comments) this is a script startup order issue, meaning that your script is run betwork network.d has had a chance to DHCP your interface and bring it up.

even rc.local is run after network.target but that's not the same as network-online.target sorry to say.

You have again a few options here, one is to simply add this to your crontab line:

@reboot sleep 60 && /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0" 

Which will sleep your command for 60 seconds before executing the SSH command.
It's not the most pretty thing in the world, but if you don't care about real time "notifications" go with it, it's quick and it works.

If you want a more reliable options tho, i'd suggest you create a init.d script with a target requirement for network-online.target which won't trigger your init script until the network is online. This is the most fastest and reliable option to go with.

I use systemd so I can't write or verify a proper init.d script atm, try following this guide and see if it works: https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian

Most likely this is because your startup script will run in a root environment by default. Assuming that you're using ~/.ssh/id_rsa.pub as your mode of authentication (You never mentioned that you're using a password and using such a thing while automate is often a bad idea anyway, so i'll assume key authentication).

Then I'll go ahead and assume even further that you haven't allowed the (or even have a) root key generated that is trusted on your laptop?

You have two options in this case.

  1. run ssh-keygen as root, and copy the content of /root/.ssh/id_rsa.pub to your /home/<user>/.ssh/authorized_keys file.

or

  1. change your command to /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0"

The second is neater since it uses your users certificate that you already know works.

Most likely this is because your startup script will run in a root environment by default. Assuming that you're using ~/.ssh/id_rsa.pub as your mode of authentication (You never mentioned that you're using a password and using such a thing while automate is often a bad idea anyway, so i'll assume key authentication).

Then I'll go ahead and assume even further that you haven't allowed the (or even have a) root key generated that is trusted on your laptop?

You have two options in this case.

  1. run ssh-keygen as root, and copy the content of /root/.ssh/id_rsa.pub to your /home/<user>/.ssh/authorized_keys file.

or

  1. change your command to /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0"

The second is neater since it uses your users certificate that you already know works.

debian startup order and network connectivity issue

Most likely (after reading your comments) this is a script startup order issue, meaning that your script is run betwork network.d has had a chance to DHCP your interface and bring it up.

even rc.local is run after network.target but that's not the same as network-online.target sorry to say.

You have again a few options here, one is to simply add this to your crontab line:

@reboot sleep 60 && /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0" 

Which will sleep your command for 60 seconds before executing the SSH command.
It's not the most pretty thing in the world, but if you don't care about real time "notifications" go with it, it's quick and it works.

If you want a more reliable options tho, i'd suggest you create a init.d script with a target requirement for network-online.target which won't trigger your init script until the network is online. This is the most fastest and reliable option to go with.

I use systemd so I can't write or verify a proper init.d script atm, try following this guide and see if it works: https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian

Source Link
Torxed
  • 3.7k
  • 7
  • 33
  • 49

Most likely this is because your startup script will run in a root environment by default. Assuming that you're using ~/.ssh/id_rsa.pub as your mode of authentication (You never mentioned that you're using a password and using such a thing while automate is often a bad idea anyway, so i'll assume key authentication).

Then I'll go ahead and assume even further that you haven't allowed the (or even have a) root key generated that is trusted on your laptop?

You have two options in this case.

  1. run ssh-keygen as root, and copy the content of /root/.ssh/id_rsa.pub to your /home/<user>/.ssh/authorized_keys file.

or

  1. change your command to /usr/bin/ssh -i /home/<user>/.ssh/id_rsa.pub 'laptop_user'@'laptop_ip' "echo '### RaspberryPi 2 online ###' | /usr/bin/write 'laptop_user' pts/0"

The second is neater since it uses your users certificate that you already know works.