137001
21.08.2018, aktualisiert um 11:32:38 Uhr
1668
11
0
Bash - ssh liefert in bash-Script manchmal keinen Output
Moin moin,
kurz und knackig: folgendes Problem.
Ich habe mir ein Bash-Script, was vereinfacht folgendes tut:
nun liefert er mir ab und an einen Hostname und ab und an kommt diese Ausgabe ohne Hostname zurück, was mir sehr merkwürdig anmutet.
noch andere Informationen:
OS: SLES 11 SP4
User: root
das Script wird über die crontab ausgeführt
irgendwer ne Idee? ich probiere schon 2 Wochen rum und finde keine Lösung.
#Edit: Parameter im SSH-Kommando
kurz und knackig: folgendes Problem.
Ich habe mir ein Bash-Script, was vereinfacht folgendes tut:
#!/bin/bash
HOSTNAME=$(ssh SERVERNAME -o StrictHostKeyChecking=no 'hostname')
echo $HOSTNAME
exit 0nun liefert er mir ab und an einen Hostname und ab und an kommt diese Ausgabe ohne Hostname zurück, was mir sehr merkwürdig anmutet.
noch andere Informationen:
OS: SLES 11 SP4
User: root
das Script wird über die crontab ausgeführt
irgendwer ne Idee? ich probiere schon 2 Wochen rum und finde keine Lösung.
#Edit: Parameter im SSH-Kommando
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 383987
Url: https://administrator.de/contentid/383987
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
11 Kommentare
Neuester Kommentar
Guten Morgen,
dann kann vermutlich gelegentlich keine SSH Verbindung hergestellt werden.
Aktiviere bei SSH den Debugging Modus und lass die Debugging Ausgabe in eine Datei schreiben.
Viele Grüße,
Exception
dann kann vermutlich gelegentlich keine SSH Verbindung hergestellt werden.
Aktiviere bei SSH den Debugging Modus und lass die Debugging Ausgabe in eine Datei schreiben.
HOSTNAME=$(ssh -v SERVERNAME 'hostname') 2>/tmp/debug.txt Viele Grüße,
Exception
Zitat von @129580:
HOSTNAME=$(ssh -v SERVERNAME 'hostname') 2>/tmp/debug.txt Ich glaube das funktioniert so nicht, da dies eine Variablenzuweisung ist und dabei der Teil in den Klamern ausgeführt wird. Dabei müsste die Ausgabeumleitung ebenfalls in den Klammern stehen.
Vgl:
dev@001019:~$ HOSTNAME=$(ssh blah 'hostname') 2>/dev/null
ssh: Could not resolve hostname blah: Temporary failure in name resolution
dev@001019:~$ HOSTNAME=$(ssh blah 'hostname' 2>/dev/null)
dev@001019:~$ Korrekt müsste es also lauten:
HOSTNAME=$(ssh -v SERVERNAME 'hostname' 2>/tmp/debug.txt) ABER:
Eigentlich ist das gar nicht nötig. Normalerweise loggt der Cron die fehlerhafte Ausführung eh ins syslog. Also schau doch mal in
/var/log/cron.log oder /var/log/syslog oder /var/log/messages (je nachdem wie der syslog Daemon eingestellt ist)Viel Erfolg.
Hi,
im debug-Log ist leider nichts zu sehen außer folgende Meldung:
die Verbindung kommt trotzdem zustande, da ich den Parameter '-o StrictHostKeyChecking=no' bei ssh mitgebe, sorry den hatte ich vorhin vergessen zu erwähnen. Ich editiere nochmal oben den Beitrag, dass das auch klar wird.
Grüße
Dominik
im debug-Log ist leider nichts zu sehen außer folgende Meldung:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for nbfscluster1_benutzer_server has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R nbfscluster1_benutzer_server -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.die Verbindung kommt trotzdem zustande, da ich den Parameter '-o StrictHostKeyChecking=no' bei ssh mitgebe, sorry den hatte ich vorhin vergessen zu erwähnen. Ich editiere nochmal oben den Beitrag, dass das auch klar wird.
Grüße
Dominik
Für welchen Benutzer läuft die crontab? Als root?
Kann es sein daß sich root nicht am Zielhost einloggen darf?
->
Kann es sein daß sich root nicht am Zielhost einloggen darf?
->
PermitRootLogin=no in der sshd_conf?
Hi,
@Evil2000
Hast Recht. Hab nicht aufgepasst. Lustigerweise funktioniert das trotzdem auf mein MacOS.
@137001
Kam der Effekt wieder? Und im Debug Log steht nichts außer den Fingerprint Warnungen?
Dann erhöhe mal das Debugging Level: -vvv
Viele Grüße,
Exception
@Evil2000
Hast Recht. Hab nicht aufgepasst. Lustigerweise funktioniert das trotzdem auf mein MacOS.
@137001
Kam der Effekt wieder? Und im Debug Log steht nichts außer den Fingerprint Warnungen?
Dann erhöhe mal das Debugging Level: -vvv
Viele Grüße,
Exception
Hi ihr beiden,
Gute Idee mit Debugging, ich teste mal und melde mich wieder.
@evil
der User darf passwortlos auf die Maschine, ssh_keys sind ausgetauscht.
Grüße
Dominik
Zitat von @129580:
@137001
Kam der Effekt wieder? Und im Debug Log steht nichts außer den Fingerprint Warnungen?
Dann erhöhe mal das Debugging Level: -vvv
jup der Fehler tritt wieder auf. Nichts außer diesen Warnungen im Log.@137001
Kam der Effekt wieder? Und im Debug Log steht nichts außer den Fingerprint Warnungen?
Dann erhöhe mal das Debugging Level: -vvv
Gute Idee mit Debugging, ich teste mal und melde mich wieder.
@evil
der User darf passwortlos auf die Maschine, ssh_keys sind ausgetauscht.
Grüße
Dominik
Hi,
also Logging erhöht und der output ändert sich nicht.
Es sieht so aus als käme das OS gar nicht zum SSH-Client
zur Erklärung nochmal vorweg: ich habe als Workaround eine Schleife gebaut, die 100 mal versucht zu connecten, in diesem Beispiel ging der 3. Connect durch.
hier der Output:
Grüße
Dominik
also Logging erhöht und der output ändert sich nicht.
Es sieht so aus als käme das OS gar nicht zum SSH-Client
zur Erklärung nochmal vorweg: ich habe als Workaround eine Schleife gebaut, die 100 mal versucht zu connecten, in diesem Beispiel ging der 3. Connect durch.
hier der Output:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOSTNAME has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R HOSTNAME -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOSTNAME has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R HOSTNAME -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOSTNAME has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R HOSTNAME -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOSTNAME has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R HOSTNAME -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOSTNAME has changed,
and the key for the corresponding IP address 10.61.8.93
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:225
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
8d:5c:78:13:73:32:3b:be:16:8a:40:bf:00:de:ec:88 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:364
You can use following command to remove all keys for this IP:
ssh-keygen -R HOSTNAME -f /root/.ssh/known_hosts
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
OpenSSH_6.6.1, OpenSSL 0.9.8j-fips 07 Jan 2009
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
...Grüße
Dominik
Hallo,
dann hast du nicht das vollständige Log gepostet. Wenn er eine erfolgreiche Verbindung herstellen konnte, dann muss da deutlich mehr drinnen stehen. (Insbesondere in der Debugging Ausgabe). Mal auf einen der Gegenstellen im Log geprüft, ob es überhaupt ein Verbindungsversuch gab?
Wobei eigentlich gesagt sein muss, dass selbst wenn er keine SSH Verbindung herstellen kann z.B. durch Timeout, dass dieses im Log (Debugging Ausgabe) stehen muss. Ansonsten mal den Wireshark anschmeißen und schauen, was passiert, wenn du das Script manuell ausführst.
Viele Grüße,
Exception
dann hast du nicht das vollständige Log gepostet. Wenn er eine erfolgreiche Verbindung herstellen konnte, dann muss da deutlich mehr drinnen stehen. (Insbesondere in der Debugging Ausgabe). Mal auf einen der Gegenstellen im Log geprüft, ob es überhaupt ein Verbindungsversuch gab?
Wobei eigentlich gesagt sein muss, dass selbst wenn er keine SSH Verbindung herstellen kann z.B. durch Timeout, dass dieses im Log (Debugging Ausgabe) stehen muss. Ansonsten mal den Wireshark anschmeißen und schauen, was passiert, wenn du das Script manuell ausführst.
Viele Grüße,
Exception
Hallo,
in mir wächst der Verdacht, daß zwischen beiden Systemen ein QoS dafür sorgt, daß die ersten paar Verbindungsversuche blockiert werden (connection burst).
Schonmal in diese Richtung analysiert?
Gruß.
in mir wächst der Verdacht, daß zwischen beiden Systemen ein QoS dafür sorgt, daß die ersten paar Verbindungsversuche blockiert werden (connection burst).
Schonmal in diese Richtung analysiert?
Gruß.
Zitat von @129580:
Hallo,
dann hast du nicht das vollständige Log gepostet. Wenn er eine erfolgreiche Verbindung herstellen konnte, dann muss da deutlich mehr drinnen stehen. (Insbesondere in der Debugging Ausgabe). Mal auf einen der Gegenstellen im Log geprüft, ob es überhaupt ein Verbindungsversuch gab?
Wobei eigentlich gesagt sein muss, dass selbst wenn er keine SSH Verbindung herstellen kann z.B. durch Timeout, dass dieses im Log (Debugging Ausgabe) stehen muss. Ansonsten mal den Wireshark anschmeißen und schauen, was passiert, wenn du das Script manuell ausführst.
Viele Grüße,
Exception
Hallo,
dann hast du nicht das vollständige Log gepostet. Wenn er eine erfolgreiche Verbindung herstellen konnte, dann muss da deutlich mehr drinnen stehen. (Insbesondere in der Debugging Ausgabe). Mal auf einen der Gegenstellen im Log geprüft, ob es überhaupt ein Verbindungsversuch gab?
Wobei eigentlich gesagt sein muss, dass selbst wenn er keine SSH Verbindung herstellen kann z.B. durch Timeout, dass dieses im Log (Debugging Ausgabe) stehen muss. Ansonsten mal den Wireshark anschmeißen und schauen, was passiert, wenn du das Script manuell ausführst.
Viele Grüße,
Exception
Hi,
ja ich hab nicht das vollständige Log gepostet. Ab dem Punkt an dem ich abgeschnitten habe funktioniert alles. (ich kann dir gerne noch das komplette Log posten aber da ist alles sauber)
Die Gegenstelle auf den Verbindungsversuch analysieren ist ne gute Idee, werde das mal demnächt angehen.
Grüße
Dominik
Zitat von @Evil2000:
Hallo,
in mir wächst der Verdacht, daß zwischen beiden Systemen ein QoS dafür sorgt, daß die ersten paar Verbindungsversuche blockiert werden (connection burst).
Schonmal in diese Richtung analysiert?
Gruß.
Hallo,
in mir wächst der Verdacht, daß zwischen beiden Systemen ein QoS dafür sorgt, daß die ersten paar Verbindungsversuche blockiert werden (connection burst).
Schonmal in diese Richtung analysiert?
Gruß.
Hi,
QoS ist soweit ich weiß nicht aktiv, ich werde aber nochmal in die Richtung nachfragen, vielleicht bin ich da auf nicht ganz aktuellem Stand.
Danke für den Input.
Grüße
Dominik
