Ich versuche eigentlich kein Problem zu lösen, sondern nur es besser zu verstehen. Soweit ich verstehe, übersenden ssh (bzw. auch sshfs) das aktuelle LC_LOCALE mit an den Server. Gibt es dort das locale nicht wird die Verbindung verweigert.
Warum ist das so? Warum muss denn das locale zwischen Client und Server übereinstimmen?
Man kann den Client und auch Server entsprechend konfigurieren, das locale nicht mit zusenden bzw. dessen Empfang zu ignorieren. Ein weiterer Workaround ist es LC_LOCALE (oder LC_ALL) temporär auf C zu setzen, was vom Server dann sicher akzeptiert wird.
Dem ssh Client könnte ich auf der Kommandozeile per -o SendEnv -LC_* (Minuszeichen!) das "SendEnv" austreiben.
Bei sshfs konnte ich noch gar keine Möglichkeit finden.
Kurz: Ich (bzw. meine User) möchte nicht an Konfigurationsdateien rumschrauben. Ich möchte das Verhalten auf der Kommandozeile beeinflussen können.
Siehe auch:
https://unix.stackexchange.com/q/269159/136851
https://www.linuxbabe.com/linux-server/ ... able-error
Warum meckert ssh(fs), wenn remote das "locale" nicht vorhanden ist?
Warum meckert ssh(fs), wenn remote das "locale" nicht vorhanden ist?
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Re: Warum meckert ssh(fs), wenn remote das "locale" nicht vorhanden ist?
Die Manpage von sftp erwähnt -o ebenfalls, um gewohnte SSH-Optionen zu benutzen. Und erwähnt dort auch ausdrücklich SendEnv. Das gleiche in der Manpage von sshfs, nur dass die Option nicht explizit erwähnt ist.
Klappt's damit nicht?
Klappt's damit nicht?
Manchmal bekannt als Just (another) Terminal Hacker.
-
- Beiträge: 58
- Registriert: 26.06.2023 09:09:40
- Lizenz eigener Beiträge: GNU General Public License
Re: Warum meckert ssh(fs), wenn remote das "locale" nicht vorhanden ist?
Hi,
was ich mir vorstellen könnte ist das die übereinstimmen müssen damit es keine Problem beim mit dem Charset und den Dateinamen gibt. Locale ist doch zb. de_DE.UTF-8 wenn die andere Seite dann z.B iso nimmt kommt da kauderwelch raus. Ist aber nur eine Vermutung.
was ich mir vorstellen könnte ist das die übereinstimmen müssen damit es keine Problem beim mit dem Charset und den Dateinamen gibt. Locale ist doch zb. de_DE.UTF-8 wenn die andere Seite dann z.B iso nimmt kommt da kauderwelch raus. Ist aber nur eine Vermutung.
vs2-free-users community
#vs2-free-users #VS2FreeUsers
#vs2-free-users #VS2FreeUsers
Re: Warum meckert ssh(fs), wenn remote das "locale" nicht vorhanden ist?
Die Vermutung hatte ich auch. Im Grunde ist ja dann der Workaround das eigene Client locale temporär auf C zu setzen fahrlässig, weil es Fehler provoziert.VS2FreeUsers hat geschrieben:30.06.2023 07:59:22was ich mir vorstellen könnte ist das die übereinstimmen müssen damit es keine Problem beim mit dem Charset und den Dateinamen gibt. Locale ist doch zb. de_DE.UTF-8 wenn die andere Seite dann z.B iso nimmt kommt da kauderwelch raus. Ist aber nur eine Vermutung.
Anders herum gesagt, sollte man vermutlich den Fehler, dass die locales zwischen Client und Server nicht übereinstimmen bzw. das client locale nicht auf dem Server verfügbar ist, auch wirklich ernst nehmen und nicht einfach mit einem workaround wegbügeln.
Ich frage mal bei den Entwicklern rum.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Teil des Upstream Betreuer Teams von Back In Time (backintime)