Automatische Datentransfers per SFTP mit Passwort und via Proxy

Dieser Artikel beschreibt einen Spezialfall aus dem Bereich OpenSSH, bei dem mehrere erschwerende Bedingungen zusammenkommen:

• 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 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

Allgemein

Für jede der Bedinungen gibt es einzelne Lösungen, die im Zusammenspiel allerdings trickreich sein können.

nur SFTP, automatisiert

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.

sftp ist ein sogenannte subsystem aus SSH und nur genau dieses Subsystem ist für uns erreichbar.

This service allows sftp connections only.

Wir müssen also für alle Zugriffe das "sftp"-Tool verwenden, oder zumindest das "sftp"-Subsystem per ssh ansprechen.

Mittels sftp -b kann man einfache vordefinierte Batchscripte ausführen, also eine Abfolge von diesen commands:

sftp> help
Available commands:
bye                                Quit sftp
cd path                            Change remote directory to 'path'
chgrp grp path                     Change group of file 'path' to 'grp'
chmod mode path                    Change permissions of file 'path' to 'mode'
chown own path                     Change owner of file 'path' to 'own'
df [-hi] [path]                    Display statistics for current directory or
                                   filesystem containing 'path'
exit                               Quit sftp
get [-Ppr] remote [local]          Download file
help                               Display this help text
lcd path                           Change local directory to 'path'
lls [ls-options [path]]            Display local directory listing
lmkdir path                        Create local directory
ln [-s] oldpath newpath            Link remote file (-s for symlink)
lpwd                               Print local working directory
ls [-1afhlnrSt] [path]             Display remote directory listing
lumask umask                       Set local umask to 'umask'
mkdir path                         Create remote directory
progress                           Toggle display of progress meter
put [-Ppr] local [remote]          Upload file
pwd                                Display remote working directory
quit                               Quit sftp
rename oldpath newpath             Rename remote file
rm path                            Delete remote file
rmdir path                         Remove remote directory
symlink oldpath newpath            Symlink remote file
version                            Show SFTP version
!command                           Execute 'command' in local shell
!                                  Escape to local shell
?                                  Synonym for help

É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 sftp(1)-Tool die Datei ssh_config(5) (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 ssh_config(5) 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

ProxyCommand /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p

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

ProxyCommand /usr/bin/ssh server.dmz.lan /bin/nc.openbsd %h %p

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:

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

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:

/bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 ftp.example.com 22
SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
^C

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.

export SSHPASS=geheimespasswort 
/usr/bin/sshpass -e ssh username@ftp.example.com -s sftp -f -N

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

/usr/bin/nohup /bin/nc.openbsd -X CONNECT -x proxy.dmz.lan:3128 %h %p

.

Alle weiteren Zugriffe auf username@ftp.example.com verwenden dann die bestehende Verbindung, zB

sftp username@ftp.example.com  < <(echo dir)

oder auch als sshfs-Mount (verwendet sftp)

sshfs username@ftp.example.com ./ftp/
ls -la ./ftp/