Aktuelle Version |
Dein Text |
Zeile 1: |
Zeile 1: |
| Dieser Artikel beschreibt einen Spezialfall aus dem Bereich [[OpenSSH]], bei dem mehrere erschwerende Bedingungen zusammenkommen: | | Dieser Artikel beschreibt einen Spezialfall aus dem Bereich [[OpenSSH]], bei dem mehrere erschwerende Bedingungen zusammenkommen: |
| * Es sollen automatisiert Dateien per '''SFTP''' ausgetauscht werden | | * Es sollen automatisiert Dateien per '''SFTP''' ausgetauscht werden |
− | * Zugriffe sollen '''gescriptet''' werden (Batch-Mode, Shell-Scripte), also nicht-interaktiv
| |
| * Zugriff auf den Server ausschließlich mit '''SFTP''' möglich, keine normale SSH-Shell, kein scp, kein rsync+ssh oder ähnliches. | | * Zugriff auf den Server ausschließlich mit '''SFTP''' möglich, keine normale SSH-Shell, kein scp, kein rsync+ssh oder ähnliches. |
| * Zugriff auf das Zielsystem nur per HTTP-Proxy möglich | | * Zugriff auf das Zielsystem nur per HTTP-Proxy möglich |
| * Zugriff auf den Account '''nur mit Benutzername und Passwort''' möglich, keine Public-Key Authentifikation möglich | | * Zugriff auf den Account '''nur mit Benutzername und Passwort''' möglich, keine Public-Key Authentifikation möglich |
| + | * Zugriffe sollen '''gescriptet''' werden (Batch-Mode, Shell-Scripte), also nicht-interaktiv |
| + | |
| | | |
| __TOC__ | | __TOC__ |
Zeile 11: |
Zeile 12: |
| Für jede der Bedinungen gibt es einzelne Lösungen, die im Zusammenspiel allerdings trickreich sein können. | | Für jede der Bedinungen gibt es einzelne Lösungen, die im Zusammenspiel allerdings trickreich sein können. |
| | | |
− | === nur SFTP, automatisiert === | + | === nur SFTP === |
| Für viele Anwendungsfälle aus dem Bereich automatisierter Filetransfer greift man zu Lösungen wie scp oder rsync+ssh oder andere Konstrukte die direkt auf ssh aufbauen. In diesem Fall ist auf dem Zielserver nur sftp möglich. | | Für viele Anwendungsfälle aus dem Bereich automatisierter Filetransfer greift man zu Lösungen wie scp oder rsync+ssh oder andere Konstrukte die direkt auf ssh aufbauen. In diesem Fall ist auf dem Zielserver nur sftp möglich. |
| | | |
Zeile 54: |
Zeile 55: |
| ? Synonym for help | | ? Synonym for help |
| </pre> | | </pre> |
− |
| |
− | És gibt wiederum verschiedene Tools, die im Hintergrund '''sftp''' sprechen, zum Beispiel '''lftp''' mit seiner mächtigen Scriptsprache oder '''sshfs''' als FUSE-Treiber für ein auf sftp basiertes Dateisystem, das man in Linux (nicht Gnome, KDE) mounten kann. Diese Möglichkeiten sind hier out-of-scope.
| |
− |
| |
− | Wichtig zu wissen ist, dass das '''{{man|freebsd|1|sftp}}'''-Tool die Datei '''{{man|freebsd|5|ssh_config}}''' (in /etc/ssh/ und ~/.ssh/config) verwendet.
| |
− |
| |
− |
| |
− | === Zielsystem nur per Proxy erreichbar ===
| |
− | ;Szenario:
| |
− | : Wir befinden uns im Backend eines ''DataWarehouse'' oder im einen ''Entwicklernetz'' '''ohne direkten Zugang zum Internet'''.
| |
− | : Wir müssen den einen oder anderen Proxy verwenden, wenn wir auf Ziele im Internet zugreifen können möchten.
| |
− |
| |
− | OpenSSH selbst kennt keine Mechanismen für SOCKS-Proxy oder HTTP(s)-Proxy, bietet allerdings eine Schnittstelle an, wo man eigene Proxy-Clients konfigurieren kann. Diesen Client mit allen erforderlichen Optionen konfiguriert man über '''ProxyCommand''' in '''{{man|freebsd|5|ssh_config}}''' ein.
| |
− |
| |
− | ;Beispiele dazu:
| |
− | * [[SOCKS Proxy nutzen/openssh]]
| |
− | * [[Firewall Piercing/Beispiele/OpenSSH via HTTPS-Proxy als SOCKS Proxy verwenden]]
| |
− |
| |
− | Gerade in Verbindung mit HTTP-Proxy ist wichtig, dass der HTTP-Proxy den '''CONNECT-Zugriff''' auf das Zielsystem erlaubt. Normalerweise ist das für HTTPS nur der Port 443, Details Dazu unter [[Firewall Piercing#Einen_Webproxy_als_Transportweg_verwenden]]
| |
− |
| |
− | ;HTTP-Proxy mit netcat, in ssh_config:
| |
− | <pre>
| |
− | ProxyCommand /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p
| |
− | </pre>
| |
− |
| |
− | Alternativ kann man eine Verbindung zur Außenwelt auch andere Konstrukte benutzen zum Beispiel eine SSH-Verbindung zu einem Server in der DMZ (erreichbar von innen und mit Zugriff auf das Internet):
| |
− |
| |
− | ;DMZ-Server mit netcat-openbsd, in ssh_config:
| |
− | <pre>
| |
− | ProxyCommand /usr/bin/ssh server.dmz.lan /bin/nc.openbsd %h %p
| |
− | </pre>
| |
− |
| |
− | === Zugriff nur mit Passwort ===
| |
− | Falls man das unbeschreibliche Pech hat auf einen SFTP-Server zugreifen zu müssen, auf den man sich ausschließlich per Username+Passwort einloggen kann, muss man zu externen Hilfsmitteln greifen, eines davon ist '''sshpass''', andere Lösungen bevorzugen '''expect'''.
| |
− |
| |
− | OpenSSH kennt keine Methoden für eine Passwortübergabe, es fragt ausschließlich interaktiv (über ein Terminal/pty). sshpass ruft also ssh oder sftp auf und verwendet dazu ein Pseudo-TTY, damit das jeweilige Binary auch nach dem Passwort fragt. Dieses TTY ist unabhängig vom TTY der Shell, in der wir das ausprobieren.
| |
− |
| |
− | '''sshpass''' wiederum akzeptiert ein Passwort über verschiedene Parameter:
| |
− | * als Commandline Argument: -ppassword
| |
− | * aus der ersten Zeile einer Datei mit -ffilename
| |
− | * aus einem Filedescriptor über -dnumber
| |
− | * oder aus einer Umgebungsvariable SSHPASS mittels -e
| |
− |
| |
− |
| |
− | == Gesamtlösung ==
| |
− | Die Gesamtlösung ist mehr als der oben vorgestellten Einzelaspekte. Die Lösung berücksichtigt den Aspekt, dass man bei OpenSSH mehrere parallele oder aufeinander folgende SSH-Verbindungen durch eine '''ControlMaster'''-Verbindung leiten kann, lediglich der erste Zugriff muss dabei Authentifiziert werden ('''ControlMaster''', '''ControlPath''', '''ControlPersist'''). Diese Eigenschaft machen wir uns hier zunutze.
| |
− |
| |
− | === ssh_config ===
| |
− | Zunächst eine vollständige ~/.ssh/config mit Zeilennummern:
| |
− | <pre>
| |
− | 01 Host ftp.example.com
| |
− | 02 Hostname ftp.example.com
| |
− | 03 Port 22
| |
− | 04 Protocol 2
| |
− | 05 StrictHostKeyChecking no
| |
− | 06 ServerAliveCountMax 30
| |
− | 07 ServerAliveInterval 10
| |
− | 08 ProxyCommand /usr/bin/nohup /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p
| |
− | 09 ControlMaster auto
| |
− | 10 ControlPath /run/shm/ssh_master_%r@%h:%p.sock
| |
− | 11 ControlPersist yes
| |
− | 12 KbdInteractiveAuthentication no
| |
− | 13 PasswordAuthentication yes
| |
− | 14 PubkeyAuthentication no
| |
− | 15 PreferredAuthentications password
| |
− | 16 RequestTTY no
| |
− | </pre>
| |
− |
| |
− | ; ProxyCommand (Zeile 8):
| |
− | :* '''ESSENZIELL''' wichtig: Das '''nohup''' im ProxyCommand verhindert, dass '''sshpass''' den netcat-Prozess ('''nc.openbsd''') beendet (SIGHUP), das scheint mir einer der Bugs von sshpass zu sein.
| |
− | :* /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p verwendet die CONNECT-Methode des HTTP-Proxy-Servers proxy.dmz.lan auf Port 3128, um die TCP-Verbindung zum Zielserver (%h:%p ftp.example.com:22) herzustellen. Anstelle eines HTTP-Proxys könnte auch ein SOCKS-Proxy verwendet werden (-X 5), anstelle von /bin/nc.openbsd kann auch ein SSH-Aufruf stehen, der dann netcat als remote command ausführt
| |
− | :* Man kann den Proxy-Zugriff testen, indem man das ProxyCommand einzeln aufruft:
| |
− | <pre>/bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 ftp.example.com 22
| |
− | SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
| |
− | ^C
| |
− | </pre>
| |
− |
| |
− | ;Timeout vermeiden (Zeilen 6+7): Aufgrund von mit '''ServerAliveInterval''' und '''ServerAliveCountMax''' werden regelmäßig (zB alle 10sec) Dummy-Pakete durch die SSH-Verbindung geschickt. Das soll verhindern, dass der Proxy-Server oder ein NAT-Router die Verbindung aufgrund von Inaktivität vergisst oder aktiv beendet..
| |
− |
| |
− | ;ControlMaster (Zeilen 9-11): Die ControlMaster Optionen erzeugen einen UnixDomain-Socket zB '''/run/shm/ssh_master_username@ftp.example.com:22.sock'''. Alle SSH-Zugriffe in der Form '''username@ftp.example.com:22''' werden (sofern vorhanden) durch diesen Socket geleitet, welcher durch die initiale SSH-Verbindung gehalten wird.
| |
− |
| |
− | ;Authentifikationsmethode gezielt wählen(Zeilen 12-15): Mit '''KbdInteractiveAuthentication''', '''PasswordAuthentication''', '''PubkeyAuthentication''' und '''PreferredAuthentications''' wird die passwortbasierte Authentifikation erzwungen, andere Möglichkeiten (zB Public-Keys) werden hier unterbunden und können somit auch bei vorhadenen Keys nicht zu Fehlversuchen führen.
| |
− |
| |
− | ;RequestTTY (Zeile 16): Mit '''RequestTTY no''' sagen wir dem initialen SSH-Aufruf, dass er obwohl er in einem TTY-Kontext (durch sshpass) aufgerufen wird selbst kein TTY auf dem Server anfordern soll. Es wird für sftp nicht benötigt und könnte nur zu Fehlern führen.
| |
− |
| |
− | === Verbindungsaufbau ===
| |
− | Die initiale SSH-Verbidung (sftp) wird authentifiziert und tut sonst nichts weiter als die dann offene Verbindung aufrecht zu erhalten.
| |
− | <pre>
| |
− | export SSHPASS=geheimespasswort
| |
− | /usr/bin/sshpass -e ssh username@ftp.example.com -s sftp -f -N
| |
− | </pre>
| |
− | '''sshpass''' soll das Passwort aus dem Prozess-Environment beziehen. Es wird '''ssh''' statt '''sftp''' ausgeführt, jedoch mit speziellen Parametern: durch "-s sftp" sprechen wir gezielt das "sftp"-Subsystem an, mit "-f -N" wird der Client in den Hintergerund geforkt (-f) und führt sonst nichts weiter aus (-N).
| |
− |
| |
− | sshpass führt ssh aus und das wiederum dann <pre>/usr/bin/nohup /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p</pre>.
| |
− |
| |
− | ;Alle weiteren Zugriffe auf '''username@ftp.example.com''' verwenden dann die bestehende Verbindung, zB:
| |
− | <pre>
| |
− | sftp username@ftp.example.com < <(echo dir)
| |
− | </pre>
| |
− |
| |
− | ;oder auch als sshfs-Mount (verwendet sftp):
| |
− | <pre>
| |
− | sshfs username@ftp.example.com ./ftp/
| |
− | ls -la ./ftp/
| |
− | </pre>
| |
− |
| |
− |
| |
− | [[Kategorie:Anwendungsbeispiel]]
| |
− | [[Kategorie:OpenSSH]]
| |