- Mitglied seit
- 05. Sep 2012
- Beiträge
- 3.259
- Punkte für Reaktionen
- 600
- Punkte
- 174
Das wäre eine feine Sache[...] Optionsschalter einbauen, der ein Verbose für SSH bereitstellt [...]
Das wäre eine feine Sache[...] Optionsschalter einbauen, der ein Verbose für SSH bereitstellt [...]
Das ist wieder so eine Glaskugelfrage, die sich kaum beantworten lässt. Halten wir einfach fest, das es wieder funktioniert und hinterfragen in diesem Zusammenhang nicht die Gründe dafür.ich habe die SSH Verbindungen nochmal neu erstellt und jetzt gehen sie Backupjobss wieder ohne Fehler.
Warum ich die Prozedur nochmals machen musste, ist allerding ein Rätzel…
Du bist der Beste! Ganz große Klasse die schnelle Umsetzung.Über die Optionsschalter -v, -vv sowie -vvv werden neben den erweiterten rsync Protokollen nun auch SSH Verbindungsprotokolle für den Debugging Mode 1, 2 und 3 ausgegeben.
Grrrrr Baby!Du bist der Beste!
Fehler behoben. Habe das Paket mit der Version 0.6-300 nochmal neu auf GitHub geladen. All diejenigen, die sich die ursprüngliche Verion 0.6-300 bereits installiert haben, bitte ich, die jetzt auf GitHub verfügbare Version erneut zu installieren.Ich sehe aber grade, das die Ausgabe der SSH Debug Protokolle nur in der Konsole ausgegeben werden und nicht im Sicherungsprotokoll auftauchen.
Prima, ich habe es bei mir einmal ausprobiert und kann dies bestätigen.Fehler behoben.
Weshalb wird dann der Version String nicht angepasst? Ist meine persönliche Meinung, aber ein Bugfix mit der gleichen Versionskennung auszuliefern finde ich unmöglichHabe das Paket mit der Version 0.6-300 nochmal neu auf GitHub geladen.
Ich habe damit aufgehört, mich von dir ärgern zu lassen, seit dem klappt das mit uns beiden scheinbar wieder besser … obwohl ich dir ja wirklich viel zu verdanken habe, hast du dich doch sehr ausdauernd darum bemüht, mir einige Dinge zu erklären, die mir zu dem Zeitpunkt nicht bekannt waren bzw. ich anfangs nicht verstehen wollte.Lass dich von mir nicht ärgern...
Schimpf und Schande über mich! Aber ja, du hast natürlich vollkommen recht, sowas macht man eigentlich nicht. Ich kann zu meiner Verteidigung nur sagen, das zwischen dem ersten und dem zweiten Release grade mal 2 Stunden an einem Freitagvormittag lagen. Daher habe ich…Ist meine persönliche Meinung, aber ein Bugfix mit der gleichen Versionskennung auszuliefern finde ich unmöglich
So oder so ähnlich muss es wohl gewesen sein. Man könnte es auch als künstlerische Freiheit abtun. Egal. Kommt nicht mehr vor.…diesen Weg vermutlich nur aus Bequemlichkeit gewählt um schnell handeln zu können und um den Patch schnellstmöglich bereitzustellen.
Freut mich, das du mit dem Ergebnis zufrieden bist. Dein Tipp - oder Wink mit dem Zaunpfahl - das ins Protokoll aufzunehmen, war aber auch wirklich gut und wird in Zukunft wohl dabei helfen, Verbindungsprobleme schneller zu identifizieren.Prima, ich habe es bei mir einmal ausprobiert und kann dies bestätigen.
Frohe Ostern!Frohe Ostern!
root@NAS01:~# ssh -p 22 stefan@192.168.178.12
kex_exchange_identification: read: Connection reset by peer
ssh -p 22 -v stefan@192.168.178.12
root@NAS01:~# ssh -p 22 -v stefan@192.168.178.12
OpenSSH_8.2p1, OpenSSL 1.1.1l 24 Aug 2021
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.178.12 [192.168.178.12] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
kex_exchange_identification: read: Connection reset by peer
Ist der User "stefan" Mitglied der Gruppe "administrators"?
Hier im Post #210 wird versucht die Verbindung von NAS01 auf das andere NAS herzustellen.root@NAS01:~# ssh -p 22 stefan@192.168.178.12
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.