Search results

So glad you are not offended anymore! The dangers of text communication. I did totally miss the persistence section (if my own defense, it was not in the post, but in the attachment. Still no excuse). However, shouldn't we also have them save and restore the knownhosts file? Reason is, the...

Oh no! I totally meant that as a compliment. It was clear and step by step! You even had feedback that it worked for someone. Sorry if I didn't say that properly.

Excellent job! - particularly isolating exactly where the megacorps scraped our user's valuable advice and injested it blindly into their stolen data blobs. However, since your instructions are so detailed and clear, you may consider augmenting them again to add save and restore steps of the...

Does that explain why ssh didn't work? Would a reboot regain that access?

I think the keygen step creates both the private and public files. At least it did when I tried it last.

Yes, lots of ways to skin that cat. However, sometimes AI skins the furniture and confidently claims it was a cat. Saw that extra step to create the public key file and got confused. Sorry again!

So true. Random thought just this morning: LLMs need to have significantly more shame programmed into them. Humans wouldn't create long drawn out detailed instructions with figures and tables that were 100% wrong. AI: oops, you caught me.

I am assuming you tried this and it worked for you? Edit: sorry, grumpy today. Looks like it does!

Looks like it does want the private key as id_dropbear though. So need this too: cp ~/.ssh/id_rsa ~/.ssh/id_dropbear

Sorry, I can't find reference right now - I created them a while back. But from memory it was something like: dropbearkey -t rsa -f ~/.ssh/id_rsa -s 3072 Note you have to save and restore the ~/.ssh directory after reboot since the home directory is in tmp.

Note passwordless ssh login of the nodes is possible but it takes some extra steps such as creating a ssh key pair and then putting the public key in the "Authorized Keys" field in the UI. This info is then distributed to the nodes.

Correct. Knock uses firewall logging to execute pre-planned commands like reboot. No ssh needed.

The router could have a ssh issue only. He mentioned access to the local Pi. I would think the router would really have to be in trouble if the firewall logging is down too (what knock.sh is monitoring). Note the email function and tailmon is still working on the router. One would think...

Yes, here: knock v1.2 - router commands for non-admin users Let me know if you have any questions or issues trying it out!

Shameless plug for knock.sh. If you had a reboot command set up, you could potentially send a reboot command to the router from the local network (eg. from Pi?). knock v1.2 - router commands for non-admin users

Do you have another way to ssh into the problem router (eg. VPN server). If so, you could try the following reset technique: tailmon -screen c t e CTRL-a+d This will stop the Tailscale service and Tailmon will restart it automatically. I have had this issue from time to time with my setup...

I'm kind of curious why this is an issue either way. I thought the purpose of the kill switch is to ensure none of the destinations the clients are connecting ever learn the wan ip address. In this case no matter where the DNS requests go, whether it's to the pihole or to the vpn dns, the...

@bibikalka Do you mind posting the output of:iptables -v -L FORWARD | grep KILLMON and iptables -v -L KILLMON This could be a lan vs wan issue.

This is exactly what the above script does except you can do that automatically at boot.

Did you try resetting the node(s) (unpair/re-pair). It always seems to be required for my setup on recent versions.