[erledigt] ssh-Schlüssel, ping (abgetrennt aus „ssh mehrere Server nacheinander abfragen“)

[GregorS]

habe das Thema aus „ssh mehrere Server nacheinander abfragen“ abgetrennt und füge hier noch ein Zitat des Posts ein, auf den GregorS geantwortet hat, damit die folgenden Beiträge nicht so in der Luft hängen

Du könntest mit ping prüfen ob eine IP-Adresse erreichbar ist

Code: Alles auswählen

ping -c1 -w3 IP-Adresse

versucht einmal die IP-Adresse anzupingen, wartet maximal 3 Sekunden auf eine Antwort und liefert einen Rückgabewert ≠0, falls sie nicht erreichbar ist.

Ich mache etwas ähnliches mit ssh selbst, weil ssh auch prüft ob der Server der ist, für den man ihn hält bzw. für den er sich ausgibt. Das ist aber nur bei Authentifizierung mittels Schlüssel praktikabel, weil man sonst im Laufe des Skripts eventuell 3 Mal das ssh-Passwort eingeben muss.
Für den Rückgabewert von ssh gilt im wesentlichen dasselbe, wenn man ssh nur true ausführen lässt:

Code: Alles auswählen

ssh IP-Adresse true

(Wenn man sich direkt erfolgreich interaktiv anmeldet, wird von ssh der Rückgabewert der Shell zurückgegeben und dadurch fehlt eine verlässliche Information ob die Verbindung über ssh funktioniert hat.)

Auf den Rückgabewert kann man mit if wie gewünscht reagieren

Code: Alles auswählen

if ssh IP-Adresse true ; then
	ssh IP-Adresse
	exit 0
fi

würde zum Beispiel prüfen ob ssh sich mit der IP-Adresse verbinden kann, falls ja das tun und sich danach beenden.
Das ganze ließe sich auch kürzer schreibe und je nach Zweck auch eleganter, aber vielleicht ist das einmal ein gut verständlicher Anfang?

und ab hier jetzt GregorS' unveränderter Beitrag:

Du könntest ...

Könntest Du das konkret ausführen? Ich habe es probiert, bin aber an der Tatsache gescheitert, dass ich nicht weiß, wie ich die Rückgabe von ping auswerten soll. Echt saudämlich und irgendwie symptomatisch für den Niedergang von Linux ist, dass ping trotz „-q“ (qiet) eine Textausgabe bringt.

... Das ist aber nur bei Authentifizierung mittels Schlüssel praktikabel, ...

Könntest Du auch sagen, wie das geht? Die Vorgehensweise ist mir nicht klar, und egal, wie ich ssh-add u.Co. einsetze, es will einfach nicht funktionieren.

Gruß

Gregor

[DeletedUserReAsG]

... Das ist aber nur bei Authentifizierung mittels Schlüssel praktikabel, ...

Könntest Du auch sagen, wie das geht? Die Vorgehensweise ist mir nicht klar, und egal, wie ich ssh-add u.Co. einsetze, es will einfach nicht funktionieren.

Die wohl einfachste Variante ist: mittels ssh-keygen ein Schlüsselpaar erzeugen, und den Public Key dieses Paares auf der Zielmaschine in einer eigenen Zeile in die ~/.ssh/authorized_keys schreiben. Wenn man den privaten Teil des Schlüssels etwa unter ~/.ssh/id_rsa speichert, wird der von ssh automatisch versucht. Ansonsten kann man die Datei mit der Option -i direkt angeben.

Voraussetzung zum Funktionieren ist selbstredend, dass der sshd auf der Zielmaschine auch konfiguriert ist, den Login via Key anzubieten.

[GregorS]

... Das ist aber nur bei Authentifizierung mittels Schlüssel praktikabel, ...

Könntest Du auch sagen, wie das geht? Die Vorgehensweise ist mir nicht klar, und egal, wie ich ssh-add u.Co. einsetze, es will einfach nicht funktionieren.

...
Voraussetzung zum Funktionieren ist selbstredend, dass der sshd auf der Zielmaschine auch konfiguriert ist, den Login via Key anzubieten.

Genau das scheint das Problem zu sein. Weißt Du zufällig aus dem stegreif, welche Option in /etc/ssh/sshd_config das ist?

Die Manpage zu sshd_config ist zwar schon ausgedruckt, aber noch nicht gelesen. Den Public-Key einfach per cat an .ssh/known_hosts anzuhängen, genügt jedenfalls nicht mehr.

Gruß

Gregor

[DeletedUserReAsG]

Weißt Du zufällig aus dem stegreif, welche Option in /etc/ssh/sshd_config das ist?

PubkeyAuthentication yes
Ist aber Default.

Den Public-Key einfach per cat an .ssh/known_hosts anzuhängen, genügt jedenfalls nicht mehr.

Hat noch nie genügt. Er gehört, wie geschrieben, in eine eigene Zeile in die authorized_keys.

[GregorS]

Weißt Du zufällig aus dem stegreif, welche Option in /etc/ssh/sshd_config das ist?

PubkeyAuthentication yes
Ist aber Default.

Danke, diese Einstellung hatte ich schon auf's Geratewohl aktiviert - die ist seit einiger Zeit standardmäßig auskommentiert. Es funktioniert leidet trotzdem nicht.

Den Public-Key einfach per cat an .ssh/known_hosts anzuhängen, genügt jedenfalls nicht mehr.

Hat noch nie genügt. Er gehört, wie geschrieben, in eine eigene Zeile in die authorized_keys.

Meiner Erinnerung nach hat es immer genügt, die öffentlichen Schlüssel auszutauschen und den jeweils fremden mit „cat ... >>“ an die eigene known_hosts anzuhängen. Das ist allerdings schon sehr lange her (>15 Jahre).

Gruß

Gregor

[DeletedUserReAsG]

diese Einstellung hatte ich schon auf's Geratewohl aktiviert - die ist seit einiger Zeit standardmäßig auskommentiert.

Sie ist auskommentiert, weil yes der Defaultwert für die Option ist.

Es funktioniert leidet trotzdem nicht.

„Funktioniert nicht“ ist keine Fehlerbeschreibung, mit der man arbeiten kann. Wenn du das Problem beheben möchtest, schlage ich Folgendes vor: du eröffnest einen eigenen Thread (Edit: hab die Moderation gebeten, diesen OT-Teil in einen eigenen Thread abzutrennen) – in diesem ging es um ein ganz anderes Thema, und der TE hat noch nicht geschrieben, dass es für ihn gelöst wäre. Dort schreibst du detailliert rein, was du genau gemacht hast: wie das Schlüsselpaar erstellt, wie und wo den Public Key an die authorized_keys gehängt, die komplette Ein- und Ausgabe von ssh -vv [restliche Optionen]. Dann kann man mal schauen, ob was zu erkennen ist.

Der private Teil des Schlüssels darf auch nur für den Besitzer lesbar sein – sonst wird ssh den nicht verwenden (darauf würde es aber deutlich hinweisen).

Meiner Erinnerung nach hat es immer genügt, die öffentlichen Schlüssel auszutauschen und den jeweils fremden mit „cat ... >>“ an die eigene known_hosts anzuhängen.

Deine Erinnerung trügt. In der known_host waren schon immer™ nur die Fingerprints der bekannten Hosts, anhand derer ssh prüft, ob sich beim Zielrechner was geändert hat, und vielleicht jemand zwischen dir und dem Zielrechner sitzt. Auch hat diese Datei nur für den Client Bedeutung, während der Pubkey für den Server von Belang ist. Tatsächlich könntest du diesen Schlüssel auf deiner Seite löschen, nachdem du ihn an die authorized_keys auf dem Server gehängt hast, und es würde trotzdem funktionieren.

[GregorS]

... schlage ich Folgendes vor: du eröffnest einen eigenen Thread – in diesem ging es um ein ganz anderes Thema, und der TE hat noch nicht geschrieben, dass es für ihn gelöst wäre. ...

Uh, shit, stimmt ja - es war nicht meine Absicht, diesen Thread zu kapern. Ich werde die Moderation bitten, alles ab meinem ersten Post in diesem Thread zu löschen.

Gruß

Gregor

[DeletedUserReAsG]

Siehe Edit, ich hab um Abtrennung gebeten. Wenn’s ein eigener Thread geworden ist, kann’s ja gerne zur Lösung geführt werden.

[smutbert]

Könntest Du das konkret ausführen? Ich habe es probiert, bin aber an der Tatsache gescheitert, dass ich nicht weiß, wie ich die Rückgabe von ping auswerten soll. Echt saudämlich und irgendwie symptomatisch für den Niedergang von Linux ist, dass ping trotz „-q“ (qiet) eine Textausgabe bringt.

Wenn die Ausgabe stört, einfach nach »/dev/null« umleiten, z. B. in der bash

Code: Alles auswählen

if ping -c1 -w1 debianforum.de &> /dev/null ; then
	echo "Debianforum erreichbar."
else
	echo "Debianforum nicht erreichbar."
fi

[chrbr]

Die Vorgehensweise ist mir nicht klar, und egal, wie ich ssh-add u.Co. einsetze, es will einfach nicht funktionieren.

Der Thread ist zwar schon abgeschlossen, die Frage oben ist aber nicht beantwortet. Ich beschreibe mal meine Prozedur. Hier verwende ich DHCP. Jedoch sind die IP Adressen per MAC Adressen für die wesentlichen Rechner fest. Die Zuordung NAME / IP ADRESSE habe ich in /etc/hosts eingetragen. Ich habe überall den Account chris. Nun die Vorgehensweise.

• Ich erzeuge ein Paar Secret Key und Public Key. Man kann auch das selbe Paar für mehrere Rechner verwenden.

• Ich connecte den entfernten Rechner mit

  Code: Alles auswählen

  ssh chris@ENTFERNTER-RECHNER
  

  Der entfernte Rechner frage darauf hin auf der Konsole an, ob man dem Rechner trauen kann. Mit "yes" aktualisiert er die Datei PFAD-ZU/.ssh/known_hosts.

• Den Public Key kopiere ich mit ssh-copy-id auf den entfernten Rechner. Beispiel:

  Code: Alles auswählen

  ssh-copy-id -i PFAD-ZU/.ssh/LOKALER_RECHNER_rsa.pub chris@ENTFERNTER-RECHNER
  

  Damit wird per Public Key in PFAD-ZU/.ssh/authorized_keys eingetragen.

• Auf dem lokalen Rechner erzeuge ich - falls noch nicht vorhanden - eine Datei "config" Dort kann man für jeden entfernten Rechner Parameter zum Verbindungsaufbau eintragen. LOKALER_RECHNER_rsa stammt aus dem ersten Schritt. Beispiel:

  Code: Alles auswählen

  Host ENTFRENTER-RECHNER
  	Hostname 192.168.0.59  <<-- Vielleicht geht hier auch der Name.
  	Port 22
  	User chris
  	IdentityFile ~/.ssh/LOKALER_RECHNER_rsa
  

Nun kann ich mich mittels

Code: Alles auswählen

ssh chris@EMTFERNER-RECHNER

ohne jede Bestätigung einloggen, mit scp oder rsync Daten kopieren usw.
Das ist nun doch länglich geworden. Die Vorgehensweise ist aus dem Gedächnis geschrieben. Ich bitte um Info falls etwas nicht passt. Abgesehen davon führen immer verschiedene Wege nach Rom.

EDIT: Da war noch ein Fehler: Schitt 2 und 3 vertausche und die richtigen Dateien eingetragen.

Viele Grüße,
Christoph

[GregorS]

...

Vielen Dank für Deine Ergänzungen.

Das mit dem Schlüsseltausch hatte bei mir nicht geklappt, weil ich Dateien verwechselt hatte (known_hosts vs. authorized_keys). Und das mit dem Ping habe ich vereinfacht so gelöst:

Code: Alles auswählen

#!/bin/sh

HOST=mimi

if ping -c 1 -w 1 $HOST > /dev/null ; then
  echo "$HOST erreichbar"
else
  echo "$HOST nicht erreichbar"
fi

#eof

Gruß

Gregor