ubuntuusers.de

Anwendung wie ddclient für Server ohne FQDN

Status: Ungelöst | Ubuntu-Version: Ubuntu 12.04 (Precise Pangolin)
Antworten |

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6492

Na, das sieht doch nicht schlecht aus, wenn auch hier und da etwas umständlich. (nicht schlecht = höchstes schwäbisches Lob) Wenn wir das noch überarbeiten, könnte das möglicherweise als Ergänzung für DynDNS-Clients dienen.

Ich frag grad mal an...

duesentriebchen

(Themenstarter)
Avatar von duesentriebchen

Anmeldungsdatum:
10. Februar 2012

Beiträge: 713

Wohnort: Im Inntal

😀

Entschuldige meine Schussligkeit... Ich beschäftige mich mit IT bzw GNU/Linux erst seit Februar.

So ungefähr hatt ich das auch im Sinn ☺

Schon eine Antwort vom Support 😉

Wenn ich mich endlich dazu bequemen würde, meine Website zu schreiben kommt das mit Sicherheit in die How To's!

Wie nennen wir das Ding?

"DiyDNSclient"

Ps: Interessant wäre noch das Ganze via HTTPS...

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6492

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6492

duesentriebchen schrieb:

😀

Entschuldige meine Schussligkeit...

Was meinst Du damit? Kam bei mir nicht an. Ich finde, Du hast Dich wacker geschlagen.

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6492

So ungefähr hatt ich das auch im Sinn ☺

Ok. Dann machen wir das gemeinsam? Wer fängt an?

duesentriebchen

(Themenstarter)
Avatar von duesentriebchen

Anmeldungsdatum:
10. Februar 2012

Beiträge: 713

Wohnort: Im Inntal

Bin zu jeder Schandtat bereit 😬

BillMaier schrieb:

duesentriebchen schrieb:

😀

Entschuldige meine Schussligkeit...

Was meinst Du damit? Kam bei mir nicht an. Ich finde, Du hast Dich wacker geschlagen.

War mit leichtem Sarkassmus verbunden 😉

BillMaier schrieb:

So ungefähr hatt ich das auch im Sinn ☺

Ok. Dann machen wir das gemeinsam? Wer fängt an?

Frage die sich mir hier stellt,

A: Wer unterstützt diesen "Service" → Provider

B: Wer wendet diesen "Service" an

C: Wie benennen wir das

D: Wo legen wir das ab → Wikieintrag, Forum, Homepage...

Ich hab das Gefühl, dass du hier mehr Erfahrung hast 💡

EDIT: Mir ist fürs allgemeine Konzept was eingefallen BillMaier 😬

Du brauchst einen Server, quasi C&C(control&command) der die IP's anderer VERTRAUTER(ssh PublicKey) Rechner sammelt und diese wiederrum an andere VERTRAUTE auf Anfrage (ssh PublicKey) ausliefert.

Du brauchst somit, wie in meinem Fall, einen C&C Server mit FQDN oder staticIP.

Somit ist dieser Server quasi der "Provider" und somit auch der Service 😀

Was hälst du davon?

Somit bräuchte man ein C&C Script, ein Server Script und ein Client Script.

Das wird viel Arbeit 🤓

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6492

kann im Moment leider nicht folgen. Ich schau mir das in Ruhe mal an.

Ich hätte spontan damit begonnen, unsere bisherige Vorgehensweise mal sauber zu dokumentieren. Ist ja dann ausbaufähig für viele weitere Ideen und Ansätze. Laut Diskussion zum Artikel DynDNS (Link s.o.) wäre es am besten, einen eigenen Wiki-Artikel zum Thema zu schreiben. Den Titel können wir uns ja noch überlegen und mit einem Arbeitstitel beginnen.

Gruß und bis bald.

Gute Nacht.

duesentriebchen

(Themenstarter)
Avatar von duesentriebchen

Anmeldungsdatum:
10. Februar 2012

Beiträge: 713

Wohnort: Im Inntal

Ja mach das ☺

Ok, ist ein Anfang. Die Doku zur PublicKeyAuthentication wie sie hier benötigt wird steuer ich dann bei.

Für den Arbeitstitel / Titel hab ich auch noch keine Idee 😉

Den DynDNS Link hab ich gelesen 🤓

Schick mir dann den Link der Wiki-Baustelle.

Ich wünsch dir eine gute Nacht.

Beste Grüße, Bernhard

duesentriebchen

(Themenstarter)
Avatar von duesentriebchen

Anmeldungsdatum:
10. Februar 2012

Beiträge: 713

Wohnort: Im Inntal

Guten Morgen BillMaier 😀

WICHTIG!!!

Ich hab das ssh Problem mit einem verschlüsselten Home Verzeichnis gelöst!

Die bisherige Doku und Einstellung funktioniert nur mit einem angemeldeten USER! Da in der Regel Server so gut wie nie mit einem angemeldeten User laufen, muss root das Ganze erledigen. Voraussetzung, das der Zugriff auf Internet für ALLE Benutzer möglich ist!!!

Untenstehend findest du die Vorgehensweise, so dass es root möglich ist die ip zu versenden!duesentriebchen

1.) AN Server(HOST_1)

cd /etc
:/etc$ sudo mkdir hostidentify
[sudo] password for USER: 
:/etc$ cd hostidentify
:/etc/hostidentify$ sudo nano ip -> speichern und schliessen
:/etc/hostidentify$ sudo nano getandsendip -> untenstehenden Text eingefügt Punkt 1.1.)

1.1.) Holen der eigenen IP; Übertrag des Datum's mit Uhrzeit; Versenden der Datei. Date ist ein Versuchseintrag um zu bestimmen ob die Daten auch aktuell sind. Bei einwandfreier Funktion kann das weggelassen werden.

#!/bin/bash
wget -q -O - http://showip.spamt.net/ > /etc/hostidentify/ip 
date >> /etc/hostidentify/ip 
scp /etc/hostidentify/ip USER@Server(HOST_2).net:/home/USER/ip

1.2.) Datei ausführbar gemacht:

:/etc/hostidentify$ sudo chmod a+x getandsendip

1.3.) Berechtigungen auf USER und root

:/etc/hostidentify$ sudo chown USER:root -R /etc/hostidentify
cd

1.4.) /etc/crontab editiert

:cd /etc
:/etc$ sudo nano crontab

1.5.) Markierte Zeile eingefügt → Alle 6 minuten also 6, 12, 18, 24, usw

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
*/6 *   * * *   root    /etc/hostidentify/getandsendip
#
cd

1.6.) Erstellen eines Schlüsselpaares ohne Passwort. Wechsel ins Home Verzeichnis des Users, erstellen der .ssh Directory falls nicht vorhanden und erstellen des Schlüsselpaares.

mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa -b 4096 -> Bei Abfrage für das Passwort "Passphrase" LEER lassen und Enter drücken, ebenso bei der Bestätigung!

1.7.) Prüfen ob Schlüssel vorhanden sind. Sollte so aussehen.

:~$ ls -la /home/USER/.ssh
insgesamt 76
drwx------  2 USER USER  4096 2012-11-16 13:36 .
drwx------ 39 USER USER 12288 2012-11-18 10:18 ..
-rw-r--r--  1 USER USER   143 2012-08-22 18:36 config
-rw-r--r--  1 USER USER   143 2012-11-15 20:55 config.backup
-rw-------  1 USER USER  3243 2012-11-16 13:36 id_rsa
-rw-r--r--  1 USER USER   735 2012-11-16 13:37 id_rsa.pub
-rw-r--r--  1 USER USER   884 2012-08-22 18:14 known_hosts

1.8.) Der Schlüssel id_rsa.pub ist der öffentliche Schlüssel. Der Inhalt dieser Datei muss am Server(HOST_2) in der Datei /etc/ssh/authorized_keys abgelegt werden. Idealerweise verwendet man diese Datei nicht, da auch hier der Schlüssel des Users in home liegt. Um dies zu umgehen erzeugt man eine Datei ausserhalb des home Verzeichnisses an Server(HOST_2). Mehr dazu in Abschnitt 2.) Server(HOST_2).

1.9.) Nun erzeugt man für root die Datei .ssh und kopiert den soeben erzeugten PRIVATEN Schlüssel in dieses Verzeichnis. Diesen Schlüssel geheim halten und nie öffentlich machen.

:~# sudo -i
:~# cd /root
:~# mkdir .ssh
:~# cp /home/USER/.ssh/id_rsa /root/.ssh

Prüfen ob datei auch vorhanden ist. Sollte so aussehen.

:~# ls -la /root/.ssh
insgesamt 16
drwxr-xr-x  2 root root 4096 2012-11-18 10:47 .
drwx------ 14 root root 4096 2012-11-18 10:06 ..
-rw-------  1 root root 3243 2012-11-18 10:47 id_rsa

1.10.) Nun muss man einmal einen "manuellen" Verbindungsversuch herstellen, damit root die knownhosts datei anlegen kann. Sollte so aussehen.

:~# logout -> Der Normale User sollte aktiv sein
:~$ sudo /etc/hostidentify/getandsendip
The authenticity of host 'meinedomain.net (XXX.XXX.XXX.XXX)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes -> VOLLSTÄNDIG EINGEBEN UND ENTER
Warning: Permanently added 'meinedomain.net,XXX.XXX.XXX.XXX' (RSA) to the list of known hosts.
ip                                                                                         100%   44 0.0KB/s
00:00    
:~$

1.11.) Nun sollte root eine "know_hosts" Datei besitzen. In Zukunft läuft dies erfolgreich im Hintergrund.

:~$ sudo ls -la /root/.ssh
insgesamt 16
drwxr-xr-x  2 root root 4096 2012-11-18 10:57 .
drwx------ 14 root root 4096 2012-11-18 10:06 ..
-rw-------  1 root root 3243 2012-11-18 10:47 id_rsa
-rw-r--r--  1 root root  884 2012-11-18 10:57 known_hosts

1.12.) Cron neu gestartet (Wusste nicht ob notwendig, hab's trotzdem gemacht 😀 )

sudo service cron restart

1.13.) Überprüfen ob das mit dem "normalen" Systemuser funtzt. Kommt keine Fehlermeldung = OK / Bei Fehlermeldung = Fehler korrigieren

/etc/hostidentify/getandsendip

2.) AN Server(HOST_2)

cd
sudo nano ip -> speichern und schliessen
sudo chown USER:USER /home/USER/ip 

2.1.) Wie in Punkt 1.8.) angesprochen, hier die Lösung für das "encrypted home directory" unter Punkt "TROUBLESHOOTING"

https://help.ubuntu.com/community/SSH/OpenSSH/Keys

2.2.) Prüfen ob alles an Server(HOST_2) ankommt → sollte so aussehen

:~$ cat ip
46.XXX.XX.XXX
Sat Nov 17 09:24:03 CET 2012

FERTIG ist die Maus 😬

EDIT: Während ich das schreibe, kommt mir den Einfall, dass auf Server(HOST_2) die Daten ebenso nicht im Homeverzeichnis abgelegt werden sollten, sondern eher unter z.B. /etc/hostidentify/identifiedhost_1.

Ich editier das später...

duesentriebchen

(Themenstarter)
Avatar von duesentriebchen

Anmeldungsdatum:
10. Februar 2012

Beiträge: 713

Wohnort: Im Inntal

Hallo Ihr 😬

Hier der NEUE Teil → letzter STAND!

Die ip wird auf dem C&C Server, Server(HOST_2) in der Datei /etc/hostidentify/idhost.1 abgelegt. Die Datei idhost.* ist chronologisch erweiterbar.

Anbei die geänderte und vorerst letzte Version 👍

WICHTIG!!!

Ich hab das ssh Problem mit einem verschlüsselten Home Verzeichnis gelöst!

Die bisherige Doku und Einstellung funktioniert nur mit einem angemeldeten USER! Da in der Regel Server so gut wie nie mit einem angemeldeten User laufen, muss root das Ganze erledigen. Voraussetzung, das der Zugriff auf Internet für ALLE Benutzer möglich ist!!!

Untenstehend findest du die Vorgehensweise, so dass es root möglich ist die ip zu versenden!duesentriebchen

1.) AN Server(HOST_1)

cd /etc
:/etc$ sudo mkdir hostidentify
[sudo] password for USER: 
:/etc$ cd hostidentify
:/etc/hostidentify$ sudo nano ip -> speichern und schliessen
:/etc/hostidentify$ sudo nano getandsendip -> untenstehenden Text eingefügt Punkt 1.1.)

1.1.) Holen der eigenen IP; Übertrag des Datum's mit Uhrzeit; Versenden der Datei. Date ist ein Versuchseintrag um zu bestimmen ob die Daten auch aktuell sind. Bei einwandfreier Funktion kann das weggelassen werden.

#!/bin/bash
wget -q -O - http://showip.spamt.net/ > /etc/hostidentify/ip 
date >> /etc/hostidentify/ip 
scp /etc/hostidentify/ip USER@Server(HOST_2).net:/etc/hostidentify/idhost.1

1.2.) Datei ausführbar gemacht:

:/etc/hostidentify$ sudo chmod a+x getandsendip

1.3.) Berechtigungen auf USER und root

:/etc/hostidentify$ sudo chown -R USER:root /etc/hostidentify
cd

1.4.) /etc/crontab editiert

:cd /etc
:/etc$ sudo nano crontab

1.5.) Markierte Zeile eingefügt → Alle 6 minuten also 6, 12, 18, 24, usw

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
*/6 *   * * *   root    /etc/hostidentify/getandsendip
#
cd

1.6.) Erstellen eines Schlüsselpaares ohne Passwort. Wechsel ins Home Verzeichnis des Users, erstellen der .ssh Directory falls nicht vorhanden und erstellen des Schlüsselpaares.

mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa -b 4096 -> Bei Abfrage für das Passwort "Passphrase" LEER lassen und Enter drücken, ebenso bei der Bestätigung!

1.7.) Prüfen ob Schlüssel vorhanden sind. Sollte so aussehen.

:~$ ls -la /home/USER/.ssh
insgesamt 76
drwx------  2 USER USER  4096 2012-11-16 13:36 .
drwx------ 39 USER USER 12288 2012-11-18 10:18 ..
-rw-r--r--  1 USER USER   143 2012-08-22 18:36 config
-rw-r--r--  1 USER USER   143 2012-11-15 20:55 config.backup
-rw-------  1 USER USER  3243 2012-11-16 13:36 id_rsa
-rw-r--r--  1 USER USER   735 2012-11-16 13:37 id_rsa.pub
-rw-r--r--  1 USER USER   884 2012-08-22 18:14 known_hosts

1.8.) Der Schlüssel id_rsa.pub ist der öffentliche Schlüssel. Der Inhalt dieser Datei muss am Server(HOST_2) in der Datei /etc/ssh/authorized_keys abgelegt werden. Idealerweise verwendet man diese Datei nicht, da auch hier der Schlüssel des Users in home liegt. Um dies zu umgehen erzeugt man eine Datei ausserhalb des home Verzeichnisses an Server(HOST_2). Mehr dazu in Abschnitt 2.) Server(HOST_2).

1.9.) Nun erzeugt man für root die Datei .ssh und kopiert den soeben erzeugten PRIVATEN Schlüssel in dieses Verzeichnis. Diesen Schlüssel geheim halten und nie öffentlich machen.

:~# sudo -i
:~# cd /root
:~# mkdir .ssh
:~# cp /home/USER/.ssh/id_rsa /root/.ssh

Prüfen ob datei auch vorhanden ist. Sollte so aussehen.

:~# ls -la /root/.ssh
insgesamt 16
drwxr-xr-x  2 root root 4096 2012-11-18 10:47 .
drwx------ 14 root root 4096 2012-11-18 10:06 ..
-rw-------  1 root root 3243 2012-11-18 10:47 id_rsa

1.10.) Nun muss man einmal einen "manuellen" Verbindungsversuch herstellen, damit root die knownhosts datei anlegen kann. Sollte so aussehen.

:~# logout -> Der Normale User sollte aktiv sein
:~$ sudo /etc/hostidentify/getandsendip
The authenticity of host 'meinedomain.net (XXX.XXX.XXX.XXX)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes -> VOLLSTÄNDIG EINGEBEN UND ENTER
Warning: Permanently added 'meinedomain.net,XXX.XXX.XXX.XXX' (RSA) to the list of known hosts.
ip                                                                                         100%   44 0.0KB/s
00:00    
:~$

1.11.) Nun sollte root eine "know_hosts" Datei besitzen. In Zukunft läuft dies erfolgreich im Hintergrund.

:~$ sudo ls -la /root/.ssh
insgesamt 16
drwxr-xr-x  2 root root 4096 2012-11-18 10:57 .
drwx------ 14 root root 4096 2012-11-18 10:06 ..
-rw-------  1 root root 3243 2012-11-18 10:47 id_rsa
-rw-r--r--  1 root root  884 2012-11-18 10:57 known_hosts

1.12.) Cron neu gestartet (Wusste nicht ob notwendig, hab's trotzdem gemacht 😀 )

sudo service cron restart

1.13.) Überprüfen ob das mit dem "normalen" Systemuser funtzt. Kommt keine Fehlermeldung = OK / Bei Fehlermeldung = Fehler korrigieren

/etc/hostidentify/getandsendip

2.) AN Server(HOST_2)

cd
cd /etc
sudo mkdir hostidentify
cd hostidentify
sudo nano idhost.1 -> speichern und schliessen
sudo chown -R USER:root /etc/hostidentify 

2.1.) Wie in Punkt 1.8.) angesprochen, hier die Lösung für das "encrypted home directory" unter Punkt "TROUBLESHOOTING"

https://help.ubuntu.com/community/SSH/OpenSSH/Keys

2.2.) Prüfen ob alles an Server(HOST_2) ankommt → sollte so aussehen

:~$ cat /etc/hostidentify/idhost.1
46.XXX.XX.XXX
Sat Nov 17 09:24:03 CET 2012

FERTIG ist die Maus 😬

Antworten |