Hallo,
ich verbinde mich über eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
1. Ist SSH vollständig 8-bit-fähig, oder muss ich da noch irgendwas beachten? Mit anderen Worten: Kann ich den so erzeugten Dump wieder verlustfrei einspielen?
2. kann ich es irgendwie erreichen, dass stderr und stdout getrennt übertragen werden? Wenn ich so eine DB ziehe, werden die Passwortabfragen usw. von der zweiten ssh und von mysqldump mit in die Datei geschrieben, was die Bedienung etwas doof macht und hinterher sowieso wieder rausgelöscht werden muss.
Tobias
Hi Tobias,
On Wed, May 09, 2007 at 16:39:04 +0200, Tobias Schlemmer wrote:
ich verbinde mich ueber eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
- Ist SSH vollstaendig 8-bit-faehig, oder muss ich da noch irgendwas
beachten? Mit anderen Worten: Kann ich den so erzeugten Dump wieder verlustfrei einspielen?
Ich denke schon. Ueber ssh habe ich auch schon solche Kontrukte benutzt (remote tar packt ein, lokale tar empfaengt von ssh):
ssh user@host tar czf - src/ | tar xpzf -
Waere ssh nicht 8-Bit clean, wuerde das schiefgehen.
- kann ich es irgendwie erreichen, dass stderr und stdout getrennt
uebertragen werden? Wenn ich so eine DB ziehe, werden die Passwortabfragen usw. von der zweiten ssh und von mysqldump mit in die Datei geschrieben, was die Bedienung etwas doof macht und hinterher sowieso wieder rausgeloescht werden muss.
Am besten vermeidest Du die Passwortabfragen durch Public Key Authentication und ssh-agent / Agent Forwarding.
Gruss, Chris
Christian Perle schrieb:
- kann ich es irgendwie erreichen, dass stderr und stdout getrennt
uebertragen werden? Wenn ich so eine DB ziehe, werden die Passwortabfragen usw. von der zweiten ssh und von mysqldump mit in die Datei geschrieben, was die Bedienung etwas doof macht und hinterher sowieso wieder rausgeloescht werden muss.
Am besten vermeidest Du die Passwortabfragen durch Public Key Authentication und ssh-agent / Agent Forwarding.
Das würde ich evtl. auch machen, aber aber schon bei der ersten Verbindung hab ich das bisher nicht hinbekommen. Und die zweite hat den Nachteil, dass das Homeverzeichnis vollkommen öffentlich per WWW abrufbar ist. Da ist mir ein .ssh-Verzeichnis unsympathisch, auch wenn ich weiß, wie ich dem IIS (!) verbieten kann, da reinzugehen.
Tobias.
Hi Tobias,
On Fri, May 11, 2007 at 09:30:50 +0200, Tobias Schlemmer wrote:
Am besten vermeidest Du die Passwortabfragen durch Public Key Authentication und ssh-agent / Agent Forwarding.
Das wuerde ich evtl. auch machen, aber aber schon bei der ersten Verbindung hab ich das bisher nicht hinbekommen. Und die zweite hat den Nachteil, dass das Homeverzeichnis vollkommen oeffentlich per WWW abrufbar ist. Da ist mir ein .ssh-Verzeichnis unsympathisch, auch wenn ich weiss, wie ich dem IIS (!) verbieten kann, da reinzugehen.
Public Key Authentication bedeutet nicht automatisch, dass es kein Passwort mehr gibt. Nur wird dort anstelle des Account-Passworts die Passphrase des privaten Schluessels erfragt. Um die Passphrase nicht dauernd eingeben zu muessen, kann ssh-agent sie zwischenspeichern.
+------+ +-------+ +-------+ |client|------->|server1|------>|server2| +------+ +-------+ +-------+
Auf "server1" und "server2" muss kein privater ssh-Key liegen, den brauchst Du _nur_ auf "client".
ssh-Schluesselpaar auf "client" erzeugen: $ ssh-keygen -t dsa
Den Dateinamen mit Return bestaetigen, als Passphrase etwas sicheres/sinnvolles waehlen. Der private Schluessel ~/.ssh/id_dsa verbleibt auf "client" und ist durch die Passphrase geschuetzt. Den oeffentlichen Schluessel ~/.ssh/id_dsa.pub hinterlegst Du auf "server1" und "server2" jeweils unter dem Namen ~/.ssh/authorized_keys.
Wenn Du den oeffentlichen Schluessel per scp auf "server1" und "server2" gelegt hast, startest Du auf "client" den ssh-agent: $ eval $(ssh-agent)
Eventuell laeuft ssh-agent schon, das kannst Du an den Umgebungsvariablen SSH_AGENT_PID und SSH_AUTH_SOCK sehen. Dann fuegst Du den privaten Schluessel zum Agent hinzu: $ ssh-add ~/.ssh/id_dsa
Es wird nach der oben festgelegten Passphrase gefragt. Danach solltest Du in der Lage sein, Dich ohne Passwort von "client" auf "server1" einzuloggen. Wenn Du jetzt noch Agent Fowarding fuer den ssh-Client auf "client" einschaltest, kannst Du Dich ohne Passwort von "client" auf "server2" einloggen: $ ssh -t server1 -t server2
Agent Forwarding konfigurierst Du in ~/.ssh/config:
Host server1 FowardAgent yes
Fuer die spaetere Benutzung musst Du nur sicherstellen, dass ssh-agent auf "client" laeuft und der Schluessel hinzugefuegt wurde (koennte man beim Login auf "client" automatisieren).
Gruss, Chris
Am 09.05.2007 um 16:39 schrieb Tobias Schlemmer:
- Ist SSH vollständig 8-bit-fähig, oder muss ich da noch irgendwas
beachten? Mit anderen Worten: Kann ich den so erzeugten Dump wieder verlustfrei einspielen?
Hängt, soweit ich weiß, vom verwendeten Terminal ab, wenn es um "Tipperei" geht. Ansonsten ist ssh ja "nur" ein Schweizer Taschenmesser für verschlüsseltes Datenübertragen.
- kann ich es irgendwie erreichen, dass stderr und stdout getrennt
übertragen werden?
Du kannst solche Scherze wie $echo BLA | ssh hostname 'cat > B' machen, und Du hast dann auf der Gegenseite (hostname) eine Datei B mit dem Inhalt "BLA\n".
Hoffentlich hilft Dir das bei Deinem Problem.
HTH Sebastian
Hallo
Tobias Schlemmer schrieb:
Hallo,
ich verbinde mich über eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
Warum Arbeitest du nicht einfach mit Portforwarding? So könntest du auf dem Remotrechner deinen lokalen mounten und das Image dahinspielen oder umgekehrt mysqldump auf dem lokalen Rechner durchführen.
- Ist SSH vollständig 8-bit-fähig, oder muss ich da noch irgendwas
beachten? Mit anderen Worten: Kann ich den so erzeugten Dump wieder verlustfrei einspielen?
Das ist wie schon vom Vorposter gesagt normalerweise kein Problem.
- kann ich es irgendwie erreichen, dass stderr und stdout getrennt
übertragen werden? Wenn ich so eine DB ziehe, werden die Passwortabfragen usw. von der zweiten ssh und von mysqldump mit in die Datei geschrieben, was die Bedienung etwas doof macht und hinterher sowieso wieder rausgelöscht werden muss.
Hier bietet sich das Portforward an.
Tobias
Alex
Hallo
Danke an alle, die geantwortet haben. Jetzt bin ich erstmal beruhigt.
Alexander Kühnlein schrieb:
Hallo
ich verbinde mich über eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
Warum Arbeitest du nicht einfach mit Portforwarding? So könntest du auf dem Remotrechner deinen lokalen mounten und das Image dahinspielen oder umgekehrt mysqldump auf dem lokalen Rechner durchführen.
Das habe ich gemacht, solange ich direkten Zugriff auf den SSH-Port der Maschine hatte. Das doppelte Portforwarding ist ne nervige Sache. Erst recht, wenn man das aus einem Skript heraus machen möchte. Da habe ich nämlich keine Rückmeldung, wann die zweite Verbindung aufgebaut ist.
Hier bietet sich das Portforward an.
Nicht wirklich.
Tobias.
Hallo,
Tobias Schlemmer wrote:
Alexander Kühnlein schrieb:
ich verbinde mich über eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
Warum Arbeitest du nicht einfach mit Portforwarding? So könntest du auf dem Remotrechner deinen lokalen mounten und das Image dahinspielen oder umgekehrt mysqldump auf dem lokalen Rechner durchführen.
Das habe ich gemacht, solange ich direkten Zugriff auf den SSH-Port der Maschine hatte. Das doppelte Portforwarding ist ne nervige Sache. Erst recht, wenn man das aus einem Skript heraus machen möchte. Da habe ich nämlich keine Rückmeldung, wann die zweite Verbindung aufgebaut ist.
Hier bietet sich das Portforward an.
Nicht wirklich.
Doch :-)
# Verbindung zu server1 aufbauen und in Hintergrund gehen, # wenn Verbindung steht ssh -f -L 1222:server2:22 server1 sleep 300 # Verbindung zu server2 aufbauen und in Hintergrund gehen, # wenn Verbindung steht ## ggf Option NoHostAuthenticationForLocalhost verwenden ## oder besser mittels eigenem Config- und Knownhosts-File ## den für server2 korrekten Schlüssel für localhost eintragen ## und prüfen... ssh -f -p 1222 -L 13306:server2:3306 localhost sleep 300 # Verbindung steht jetzt: mysqldump starten mysqldump -other-options -P 13306 -h localhost DBname ## Wenn der dump länger als 300 Sekunden dauert, fällt die ssh ## auch erst zu, wenn sie zufallen soll...
ggf interessant: man ssh und dann suche nach -f :-)
Ciao, Thomas
Hallo,
# Verbindung zu server2 aufbauen und in Hintergrund gehen, # wenn Verbindung steht ## ggf Option NoHostAuthenticationForLocalhost verwenden ## oder besser mittels eigenem Config- und Knownhosts-File ## den für server2 korrekten Schlüssel für localhost eintragen ## und prüfen... ssh -f -p 1222 -L 13306:server2:3306 localhost sleep 300
Du meinst ssh -f -p 1222 -o UserKnownHostsFile=~/.ssh/kh.server2 ...?
Werde ich mal drüber nachdenken, alles andere ist genauso nervig, wie die bisherige Lösung. Insbesondere weil ich mir localhost freihalten möchte.
Btw: Warum eigene Config?
Host server1 Hostname server1.domain.example.com LocalForward :1222 server2.example.com:22
Host server2 Hostname localhost UserKnownHostsFile=~/.ssh/kh.server2 LocalForward :13306 localhost:3306
ssh -f server1 sleep 300 ssh -f -p 1222 server2 sleep 300 mysqldump ...
ggf interessant: man ssh und dann suche nach -f :-)
Damit hab ich früher Mails getunnelt.
Tobias
Hallo Tobias,
Tobias Schlemmer wrote:
Hallo,
ich verbinde mich über eine doppelte SSH-Verbindug zu einem Server mit MySQL-Datenbank:
ssh -t server1 ssh -t server2 mysqldump dbname
- Ist SSH vollständig 8-bit-fähig, oder muss ich da noch irgendwas
beachten?
Bei der ssh nicht...
Mit anderen Worten: Kann ich den so erzeugten Dump wieder verlustfrei einspielen?
Möglicherweise nein, weil mysqldump noch die Option --allow-keywords braucht, um wirklich in allen Fällen einen vollständigen Dump zu liefern. Ansonsten könnte das von den Definitionen deiner Tabellen abhängig sein... ;-)
Ciao, Thomas
lug-dd@mailman.schlittermann.de
-
Alexander Kühnlein -
Christian Perle -
Sebastian Hegler -
Thomas Köhler -
Tobias Schlemmer