DietPi-DDNS | Manage domains for your dynamic IP #4229
Conversation
|
Ay, before you invest too much time into the software install part of this, I'm working on a DietPi-DDNS script with generic DDNS provider support for those which can be updated via simple request, including support to enter a custom provider update URL. Similarly to DietPi-VPN, there is not much point in having this as a software install option as the script will be always present. I'll incorporate/merge it with our DuckDNS specific work, especially the "OK" return code to check for success is a good idea. |
|
I restored the branch, and re-opened PR to compare/incorporate the work. |
|
It's ready for you, @MichaIng. |
+ DietPi-DDNS | Use separate update script which holds the cURL call with credentials and has strict read-only permissions. This assures that credentials are never shown as part of Cron journalctl logs. + DietPi-DDNS | Use password box for password/token input. While it makes the input harder, it enhances security by assuring that those are never visible on screen.
|
Question: what happen with user who have NoIP installed as of today. Are they able to continue to mange their NoIP account? Or do they need to re-setup thinks using |
|
AFAIK What we should add is an interactive prompt to inform and encourage users with No-IP installed to setup No-IP DDNS via our new script, which is lighter and uses up-to-date protocols etc and have the old client automatically removed as very last step of the setup. Most importantly it cannot happen that the client is removed but no Cron job installed. |
|
That should make it clear: 5c83d4e |
|
Yeah that should be fine 😉 |
+ DietPi-DDNS | Do not use sudo to run DDNS update test, to avoid plain text passwords/tokens in journal sudo log. The chance that the unprivileged user causes an issue is pretty low. That would require a strict custom setup/firewall to permit network access only for specific users, which would break various other common implementations as well. So it's okay to count on every user being able to perform network requests.
| if [[ $PROVIDER == 'DuckDNS' ]] | ||
| then | ||
| url="https://www.duckdns.org/update?domains=$DOMAINS&token=$PASSWORD" | ||
| unset -v USERNAME PASSWORD |
There was a problem hiding this comment.
unset -v USERNAME PASSWORD
Any reason for this line? Just asking because it makes the 'Token' field disappear.
There was a problem hiding this comment.
Ah, I didn't think about the values shown in the menu afterwards. Currently this is required to not have HTTP authentication used.
But then we need to a separate variable for this:
local http_auth=1
...
if [[ $PROVIDER == 'DuckDNS' ]]
then
unset -v http_auth
...
...${http_auth:+ -u '$USERNAME:$PASSWORD'}...
Will implement this now.
Status: Review
References:
ToDo:
*)? Enhances security but especially with for those long tokens it's a comfort downside. ... Ah, it's the very same with UNIX passwords, let's be consequent here. Via SSH copy&paste is always possible anyway.