ubuntuusers.de

Hallo, ich möchte eine lokale Datei per scp auf einen Webserver kopieren; mein Code:

1
2
3
4

strPathONline="https://sub.test.org/main/"
strFileONline="ABC-HowTo_x_ONline.html"
strWebUser="username"
scp "$strWebUser"@"$strPathONline:$strFileONline"

Das liefert leider nur

usage: scp [-346ABCOpqRrsTv] [...

Die Datei $strFileONline existiert in meinem aktuellen Verzeichnis.

scp funktioniert erstmal ähnlich zu cp, also:

scp $quelle $ziel

Ein Unterschied zu cp ist dann, dass Quelle oder Ziel auch remote per SSH erreichbar sein können.

Sowas ist also valide:

scp datei.txt username@meinserver.de:/pfad/auf/remote

In deinem Falle dann mutmaßlich sowas in der Richtung:

scp "$strFileONline" "$strWebUser"@deinserver.de:/pfad/auf/remote

Ich hab’ hier immer noch „deinserver.de“ und „/pfad/auf/remote“ als Platzhalter drin, weil mir nicht so ganz klar ist, wie das bei dir konkret aussieht. Was du jedenfalls nicht machen kannst, ist https://-URLs mit scp zu verwenden, denn die sind eine andere „logische Ebene“ als das, was du mit scp bespielen kannst. Dazu müsste man jetzt wissen, wie dein Webserver die Pfade aus dem Dateisystem zu URLs mapped.

Möglicherweise geht’s einfach so, wenn das Verzeichnis, in dem du dich nach einem SSH-Connect befindest, schon das vom Webserver ist:

scp "$strFileONline" "$strWebUser"@sub.test.org:main/

Also hier ist Platz genug, für das, was die Usagemeldung sagt.

Sehen wir es uns an:

1
2
3

usage: scp [-346ABCOpqRrsTv] [-c cipher] [-D sftp_server_path] [-F ssh_config]
           [-i identity_file] [-J destination] [-l limit] [-o ssh_option]
           [-P port] [-S program] [-X sftp_option] source ... target

Die Hilfe ist traditionell gestaltet. Nicht alle, aber die allermeisten Kommandos/Programme halten sich an folgende Konvention:

Alles, was geschrieben werden muss, erscheint als undekorierter Text, hier also:

1

scp source target

Hier also, man kopiert eine Quelle (source) in ein Ziel (target).

Die Backsteinklammern umschließen Optionen, d.h. sie sind optional, man kann das alles weglassen (wenn man es nicht braucht).

Die 3 Punkte zw. Source und Target werden nicht ausgeschrieben, sondern man kann viele Quellen ins Ziel bringen.

In Deinem Code

1

scp "$strWebUser"@"$strPathONline:$strFileONline"

fehlt entweder die Quelle oder das Ziel. Dass die Datei an beiden Orten den gleichen Pfad hat kommt nicht so selten vor, wird aber nicht, wenn eines davon fehlt, automatisch geschlossen.

Womöglich meinst Du folgendes:

1

scp $strFileONline $strWebUser@$strPathONline:$strFileONline

(Die Anführungsstriche sind überflüssig, da Du keine Blanks maskierst.)

Der Doppelpunkt zw. Pfad und File mutet mich noch seltsam an. Ich glaube, richtig wäre:

1
2
3
4

ziel=sub.test.org/main
file=OSM-HowToMap_x_ONline.html
webUser=username
scp $file $webUser@$ziel/$file

Der Slash wird nicht als Teil des Variablennamens interpretiert ($ziel/) und dient hier als natürlicher Trenner. Daher kann man den trailing Slash im Pfad weglassen, aber /home/////hugo funktioniert genauso wie /home/hugo, so dass er auch doppelt gesetzt nicht schadet.

(Edit): Ach, da war wer schneller.

Noch vergessen zu erwähnen: Das Leerzeichen trennt die Elemente (Befehlsname, Source) und (Source Target). Es darf nicht weggelassen werden und wenn Source oder Target oder Befehl (kommt wahrscheinlich auch noch in Mode) ein Blank enthalten, dann müssen die Blanks maskiert/gequotet werden. Aber sonst nicht.

(Edit 2): Oh, ja, das "https:" habe ich auch überlesen. Jetzt habe ich meine Zielvariable angepasst, und das "https:" rausgeschnitten. Angenommen, die Url funktioniert so.

Danke @Vain, verstehen tue ich gar nichts. Die beiden letzten Codezeilen liefern

scp: stat local "": No such file or directory

Danke @user_unknown, Deine beiden Codezeilen ab

Womöglich meinst Du folgendes:

liefern wie in meinem ersten Post

usage: scp [-346ABCOpqRrsTv] [...

Der Aufruf der zu kopierenden Datei im Browser funktioniert so:

https://sub.meineDomain.de/Bereich/Dateiname%20ONline.html

Das mit dem Doppelpunkt hat bei scp seine Richtigkeit, das folgt dem Muster [user@]host:[path], sagt meine Manpage. 🙂

– edit: Ah, jetzt hab’ ich kapiert, was user_unknown mit dem Doppelpunkt meinte. 😅 Ja, das wirkt falsch im initialen Beispiel.

michahe: Mir schwant, du führst unsere Beispiele einfach so am Terminal aus – ohne, dass die Variablen mit Inhalt befüllt sind. Kann das sein? Vielleicht probierst du’s im ersten Schritt mal ganz ohne Variablen. Beispiel:

scp ABC-HowTo_x_ONline.html username@sub.test.org:main/

Das würde bedeuten, dass die lokale Datei ABC-HowTo_x_ONline.html auf den Server namens sub.test.org kopiert wird, dabei wird beim Serverlogin der Username username verwendet und das Zielverzeichnis für die Kopieraktion ist main/ auf dem Server (relativ zu dem Verzeichnis, in dem du dich direkt nach Login befindest).

Ja, wie von Vain und mir beschrieben, ist https ein Marker für ein anderes Protokoll, nämlich https. Womöglich spricht Dein Server https und ssh, aber für scp musst Du eine ssh-Adresse angeben.

Und die Serveradresse (sub.test.org) wird vom Dateipfad mit Doppelpunkt getrennt (sub.test.org:/home/hugo oder 192.168.1.2:/hugo/com) aber sub.test.org/main/ enthält mit "/main" ja offenbar schon den Zielordner. Aber über https: muss main nicht im Wurzelverzeichnis liegen, sondern der Webserver könnte "main" auf "/var/www/main" oder einen anderen Ort mappen, wenn meine Webserverkenntnisse mich nicht fehlleiten.

Aber nach dem "main" kommt bestimmt kein Doppelpunkt, sondern zw. (Servername oder Serveradresse) und Pfad auf dem Server.

Vain schrieb: ... Vielleicht probierst du’s im ersten Schritt mal ganz ohne Variablen. Beispiel:

scp ABC-HowTo_x_ONline.html username@sub.test.org:main/

liefert

ssh: connect to host sub.test.org port 22: Connection refused
scp: Connection closed

michahe schrieb:

1 2 3 4

strPathONline="https://sub.test.org/main/" strFileONline="ABC-HowTo_x_ONline.html" strWebUser="username" scp "$strWebUser"@"$strPathONline:$strFileONline"

liefert bei mir

1
2

echo "$strWebUser"@"$strPathONline:$strFileONline"
username@https://sub.test.org/main/:ABC-HowTo_x_ONline.html

Da scheint der ':' falsch zu liegen.
Ob das mit https funktioniert, kann ich nicht sagen.
Ein hostname hat normalerweise kein Protokoll davor.
So:
"scp datei.txt nutzer@example.com:/pfad/zum/verzeichnis"

michahe schrieb:

scp ABC-HowTo_x_ONline.html username@sub.test.org:main/

liefert

ssh: connect to host sub.test.org port 22: Connection refused
scp: Connection closed

Okay, da musst du den Hostnamen deines Servers einsetzen statt sub.test.org. 🙂 Die SSH-Zugangsdaten zu deinem Server hast du doch, oder? (Aus Sicherheitsgründen solltest du den echten Hostnamen deines Servers hier tatsächlich nicht im Forum posten.)

Vain schrieb:

michahe schrieb:

scp ABC-HowTo_x_ONline.html username@sub.test.org:main/

liefert

ssh: connect to host sub.test.org port 22: Connection refused
scp: Connection closed

Okay, da musst du den Hostnamen deines Servers einsetzen statt sub.test.org.

Habe ich gamcht, aber es kommt keine Abfrage des Passworts ...

... aber es kommt keine Abfrage des Passworts ...

Da kann durchaus der Normalfall sein, wenn dein SSH-Agent sich um den Zertifikatsaustausch kümmert.

So wie du fragst, drängt sich mir allerdings der Eindruck auf, dass du bisher wohl wenig mit "ssh" Verbindungen zu tun hattest. Der "scp" Befehl ist nur eine "ssh" Anwendung, die du auch wie folgt ausführen kannst.

$ echo "Hallo Welt" >x.txt
$ # statt
$ scp x.txt host:
$ # kannst du dies auch mit folgendem ssh Befehl machen
$ cat x.txt | ssh host "cat - >x.txt"
$

Hast du das Wiki hier über "ssh" bereits gelesen und verstanden?

Teste erst mal, ob eine "ssh" Verbindung zu deinem Host funktioniert mit dem Befehl "ssh -v $deinHostName" und schau dir die Ausgabe des "ssh" Befehls an. Da kannst du sehen, ob deine "~/.ssh/config" Konfiguration korrekt von dir erstellt worden ist.

Es kann auch sein, dass dein Host so konfiguriert ist, das eine Verbindung ohne Zertifikat abgelehnt und daher keine Passwortabfrage gestellt wird. Aber das sind alles Antworten, die nur du kennst und beantworten kannst, da du ja "scp" einsetzen willst.

Danke @shiro

So wie du fragst, drängt sich mir allerdings der Eindruck auf, dass du bisher wohl wenig mit "ssh" Verbindungen zu tun hattest.

Stimmt!

Hast du das Wiki hier über "ssh" bereits gelesen und verstanden?

Gelesen ja, verstanden nein ...

Teste erst mal, ob eine "ssh" Verbindung zu deinem Host funktioniert mit dem Befehl "ssh -v $deinHostName" und schau dir die Ausgabe des "ssh" Befehls an.

$ ssh -v $meineDomain.de                                  # MIT $ vor DomainName
debug1: OpenSSH_10.0p2, OpenSSL 3.5.3 16 Sep 2025
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
ssh: Could not resolve hostname .de: Name or service not known
$ ssh -v meineDomain.de                                   # OHNE $
debug1: OpenSSH_10.0p2, OpenSSL 3.5.3 16 Sep 2025
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: Connecting to intago.de [85.13.141.96] port 22.
debug1: connect to address 85.13.141.96 port 22: Connection refused
ssh: connect to host intago.de port 22: Connection refused

Mit FileZilla / FTP kann ich die Datei übertragen ...

ssh -v meineDomain.de

Ja, das hatte ich befürchtet. Gemäß Log hast du keine "per-user" Konfiguration unter "~/.ssh/config" eingerichtet, da der "ssh" Befehl einen Fallback auf die systemweite Konfiguration versucht und damit natürlich Schiffbruch erleidet. Damit erklärt sich die Fehlermeldung "Connection refused".

Mit FileZilla / FTP kann ich die Datei übertragen ...

FileZilla unterstützt den Transfer via FTP (Port 21), FTP über TLS (FTPS meist über Port 990) und SFTP (über Port 22 wie bei ssh üblich). Wie du Filezilla nutzt weist nur du. Ich vermute aber, dass dies nicht SFTP ist.

Da du einen Domain-Name offenbar bei einem Service-Provider erhalten hast, der das "Kundenadministrationssystem (KAS)" verwendet, gehe ich davon aus, dass er eine Beschreibung geliefert hat, wie die von dir erstellten Webseiten mit welchen Authentisierungs-Maßnahmen zu deinem gemieteten Webserver übertragen werden sollen.

Wenn du dort einen SFTP Zugang frei geschaltet bekommen hast, kannst du häufig auch "ssh" und somit "scp" verwenden, wenn du diese Informationen in deinem Verzeichnis "$HOME/.ssh/" erzeugst und z.B. den öffentlichen Schlüssel an den Webserver weiter leitest. Man kann auf der Server Seite allerdings SFTP erlauben und "ssh/scp" verbieten. Also ist SFTP keine Gewähr, dass du "scp" zum Laufen bekommst.

Eine reine FTP (Post 21) Kommunikation würde ich nicht nutzen, da diese keinerlei Schutz bietet. FTPS bietet zwar ein wenig Transportverschlüsselung über TLS aber nur eine Authentifizierung über Username/Passwort. Wenn kein SFTP angeboten wird, solltest du mindestens FTPS verwenden.

Welche Art der Kommunikation bietet dein Service Provider an?

PS: Ich habe mal die Webhosting Angebote von all-incl.com angeschaut. Das "Privat" Paket unterstützt demnach nur FTP, kein SSH. Erst die Pakete "Premium" und "Business" unterstützen auch SSH.

Es wäre daher hilfreich, wenn du eine derartige Information auch liefern könntest. In jedem Fall wird der Service-Provider Informationen liefern, wie du den "public-Key", den du für SSH generieren musst an ihn abliefern darfst. Dafür könnte zur Not ein Kontakt mit der Hotline des Providers erforderlich sein.

Danke an alle, die mich unterstützen! @shiro hatte die richtige Idee: Vom Provider habe ich auf Nachhfrage die Info bekommen, dass kein SSH unterstützt wird!

Deshalb zwei Fragen:

1. Wie sieht ein Zugriff über FTPS aus? Ist $ lftp der richtige Ansatz? Leider ist die ManPage niht gerade übersichtlich ... Ich möchte die Übertragung in einem existierenden BASH-Script erledigen, der FTP-Transfer z.B. mit FileZilla gelingt mir bereits.

2. Hat jemand einen Vorschlag für einen Provider mit ssh, fünf Inclusiv-Domains und gutem Support. Das All-Inkl - Paket Premium ist recht teuer (24 Euro/Jahr nur für ssh), da z.B. die zehn Domains nicht benötigt werden. Die anderen Anbieter mit ssh, die @shiro und ich gefunden haben, bieten keine fünf Domains.

Wie sieht ein Zugriff über FTPS aus? Ist $ lftp der richtige Ansatz?

FileZilla bietet zwar auch Zugriff über die Command-Line doch wird es oft über die GUI bedient. Ob der WebServer des Service Providers "ftps" unterstützt, kann man leicht feststellen, wie die Antwort auf einen ftps-Verbindungsaufbau ausschaut.

Gegenüber FileZilla bietet "lftp" die Möglichkeit des Synchronisierens ("mirror"), wie man es sonst nur mit "rsync" bewerkstelligen kann. Welches Programm man verwendet hängt stark von der eigenen Arbeitsweise ab. Die "lftp" Befehle entsprechen sonst denen des Standard-ftp (put, get usw).

Ich erstelle und teste z.B. meine Webseiten lokal ("http-server" bzw "busybox httpd") und synchronisiere die Änderungen in die Zielverzeichnisstruktur des Webservers via

dstHost="ftps://meinWebserver.de -u $user,$pass"
dsrDir="pfad/zum/Webauftritt"
lftp $dstHost -e "cd $dstDir; mirror -v -e -R; exit"

Erhält man die Meldung "Verbindungsaufbau abgelehnt", wenn man z.B. nur den "lftp" Befehl (ohne -e ...) eingibt, wird eine FTPS Verbindung seitens des Anbieters nicht möglich sein. Dann bleibt nur der reine FTP Verkehr mit dem Problem, dass die Kommunikation ohne Verschlüsselung (Passwort!!!) stattfindet. Dies trifft auch für die FileZilla Kommunikation zu. Es gibt allerdings einige Anbieter, die eine eigene Software basierend auf dem https Upload verwenden um Änderungen zu laden (z.B. WebFTP oder WebExplorer usw). Das automatisierte Nutzen dieser https-Upload Schnittstellen kann allerdings ein wenig herausfordernd oder einfach (z.B. via curl oder POST) sein. Weitere Anbieter ermöglichen, die Webseite mittels eines "Web-Baukastens" auf ihrem Server zu erstellen. Damit bleibt die Webseite und ihre Änderungen nur in der Server-Umgebung des Anbieters und man braucht keinen Upload wie FTP oder SSH.

... fünf Inclusiv-Domains ...

Für jede Domain fallen ca 1€/Monat an (eventuell auch billiger aber denic will ja auch leben). Dies kann im angebotenen Komplettpaket inkludiert sein oder muss halt dazu gekauft werden. Hier hilft in der Regel ein Gespräch mit dem potentiellen Anbieter.