ssh command

[wg]

Hallo Leute,

folgendes Situation:
mit ssh ruft Rechner A ein shell-script auf Rechner B auf:
'ssh user@rechnerB shell-script'
Das shell-script enthält u.A. einen Ghostscript-Aufruf.

Problem:
ghostscript verwendet das XWindow vom aufrufenden Rechner A.
Das bewirkt, daß Ghostscript ein falsche Ergebnis liefert, verschiedene
Zeichen (Umlaute, Euro) werden falsch dargestellt.

gs läuft ok bei direktem login auf Rechner B.

Frage:
wie bring ich's zustande, daß das auf Rechner B vorhandene XWindow
verwendet wird und nicht das vom aufrufenden Rechner A?


Oder gibt's einen besseren Ansatz als ssh?

Danke für's Lesen und Tipps
Wolf

[Stefan Enzinger]

On 11/02/2012 07:11 PM, wg wrote:
> Hallo Leute,
>
> folgendes Situation:
> mit ssh ruft Rechner A ein shell-script auf Rechner B auf:
> 'ssh user@rechnerB shell-script'
> Das shell-script enthält u.A. einen Ghostscript-Aufruf.
>
> Problem:
> ghostscript verwendet das XWindow vom aufrufenden Rechner A.
> Das bewirkt, daß Ghostscript ein falsche Ergebnis liefert, verschiedene
> Zeichen (Umlaute, Euro) werden falsch dargestellt.

X-forwarding ist wohl bei dir in einem config file auf aktiv gesetzt.
laut manüpage gibt es:
-x Disables X11 forwarding.


probier also mal den -x Schalter.

lg

[wg]

'ssh -x user@rechnerB shell-script' durchgeführt, mit dem selben Ergebnis.
ist mir total unklar; $DISPLAY ist nicht gesetzt lt echo in
shell-script.

[Helmut Springer]

wg <w...@gmx.net> wrote:
> ghostscript verwendet das XWindow vom aufrufenden Rechner A.

Das bezweifle ich mal.


> Das bewirkt, daￜ Ghostscript ein falsche Ergebnis liefert,

> verschiedene Zeichen (Umlaute, Euro) werden falsch dargestellt.
>

> gs lï¿œuft ok bei direktem login auf Rechner B.

Die ssh schickt eine Menge Environment mit, um zB charset auf dem
remote host fuer das local terminal korrekt zu setzen.

Zeichensatz, etc, explizit setzen so setzen, wie es benoetigt wird,
oder ghostscript entsprechend aufrufen.


--
Best regards
helmut springer panta rhei

[Ralph Angenendt]

Well, wg <w...@gmx.net> wrote:
> Frage:
> wie bring ich's zustande, daß das auf Rechner B vorhandene XWindow
> verwendet wird und nicht das vom aufrufenden Rechner A?

Du musst dafür sorgen, dass der X-Server auf Rechner B angesprochen
wird, und nicht der auf Rechner A.

Das bekommst du dadurch hin, dass du die Variable DISPLAY explizit auf
das Display von Rechner B setzt und dich nicht auf die von ssh (mit
X11-Forwarding) automatisch gesetzte Variable verlässt.

Das heißt natürlich auch, dass auf Rechner B ein X-Server laufen muss.

Ralph
--
Als hätte es 100 Jahre Philosophie in Göttingen studiert ...

[Ulli Horlacher]

wg <w...@gmx.net> wrote:

> folgendes Situation:
> mit ssh ruft Rechner A ein shell-script auf Rechner B auf:
> 'ssh user@rechnerB shell-script'

> Das shell-script enth�lt u.A. einen Ghostscript-Aufruf.

>
> Problem:
> ghostscript verwendet das XWindow vom aufrufenden Rechner A.

Du meinst den X-Server von user A auf host A.
Das aber nur, wenn user A sein ssh so konfiguriert hat, dass
X11-forwarding verwendet wird. Das ist standardmaessig nicht der Fall.


> Das bewirkt, da� Ghostscript ein falsche Ergebnis liefert, verschiedene

> Zeichen (Umlaute, Euro) werden falsch dargestellt.

Das wiederum liegt am falschen locale und hat nichts mit ssh zu tun.


> gs l�uft ok bei direktem login auf Rechner B.
>
> Frage:
> wie bring ich's zustande, da� das auf Rechner B vorhandene XWindow

> verwendet wird und nicht das vom aufrufenden Rechner A?

Welchen X-Server willst du ansprechen? Es koennen durchaus mehrere dort
laufen.
Generischer Ansatz:
ssh user@rechnerB 'DISPLAY=welches_auch_immer shell-script'

Zusaetzlich musst du noch die X Zugriffsrechte setzen, zB mittels xauth.

> Oder gibt's einen besseren Ansatz als ssh?

Alle anderen brauchen auch die DISPLAY Angabe.


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum IZUS/TIK E-Mail: horl...@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-68565868
Allmandring 30a Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

[Dirk Thierbach]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> wg <w...@gmx.net> wrote:

>> gs läuft ok bei direktem login auf Rechner B.
>>
>> Frage:
>> wie bring ich's zustande, daß das auf Rechner B vorhandene XWindow

>> verwendet wird und nicht das vom aufrufenden Rechner A?

> Welchen X-Server willst du ansprechen? Es koennen durchaus mehrere dort
> laufen.
> Generischer Ansatz:
> ssh user@rechnerB 'DISPLAY=welches_auch_immer shell-script'
>
> Zusaetzlich musst du noch die X Zugriffsrechte setzen, zB mittels xauth.

Das ist uebrigens eine grosse Sicherheitsluecke, wenn man sich durch
ssh einen Zugang auf den lokalen X-Bildschirm eines anderen Rechners
verschaffen kann: Dann kann man auch Tastatureingaben (Passwoerter)
ausspaehen etc.

Also dieses Mittel sehr vorsichtig einsetzen.

Die naechste Frage ist, warum Du eine gs-Ausgabe haben willst, die
Du auf dem anderen Rechner (der ja z.B. 200 km entfernt stehen kann) gar
nicht sehen kannst.

Moeglicherweise ist das eigentliche Problem ja ein voellig anderes,
und sollte auch anders geloest werden.

- Dirk

[Wolfgang Meiners]

Am 03.11.12 13:12, schrieb Oliver Sch@d:
> Dirk Thierbach wrote:

>
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>
>> Das ist uebrigens eine grosse Sicherheitsluecke, wenn man sich durch
>> ssh einen Zugang auf den lokalen X-Bildschirm eines anderen Rechners
>> verschaffen kann: Dann kann man auch Tastatureingaben (Passwoerter)
>> ausspaehen etc.
>

> Mit "ssh -X" wird lokal gerendert, nicht remote oder verstehe ich dich
> jetzt falsch?
>

wenn ich das richtig sehe: Mit "ssh -Y" erhält der entfernte Rechner
zugriff auf den lokal laufenden X-Server. Wenn also der entfernte
Rechner kompromittiert ist, hast du ein lokales Sicherheitsproblem.

Grüße
Wolfgang

[Thomas 'PointedEars' Lahn]

Wolfgang Meiners wrote:

> Am 03.11.12 13:12, schrieb Oliver Sch@d:
>> Dirk Thierbach wrote:
>>> Das ist uebrigens eine grosse Sicherheitsluecke, wenn man sich durch
>>> ssh einen Zugang auf den lokalen X-Bildschirm eines anderen Rechners
>>> verschaffen kann: Dann kann man auch Tastatureingaben (Passwoerter)
>>> ausspaehen etc.
>> Mit "ssh -X" wird lokal gerendert, nicht remote oder verstehe ich dich

^^

>> jetzt falsch?
>
> wenn ich das richtig sehe: Mit "ssh -Y" erhält der entfernte Rechner

^^

> zugriff auf den lokal laufenden X-Server. Wenn also der entfernte
> Rechner kompromittiert ist, hast du ein lokales Sicherheitsproblem.

Wer sich in Gefahr begibt, kommt darin um.

--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:

> Dirk Thierbach wrote:

>> Das ist uebrigens eine grosse Sicherheitsluecke, wenn man sich durch
>> ssh einen Zugang auf den lokalen X-Bildschirm eines anderen Rechners
>> verschaffen kann: Dann kann man auch Tastatureingaben (Passwoerter)
>> ausspaehen etc.

> Mit "ssh -X" wird lokal gerendert, nicht remote oder verstehe ich dich

> jetzt falsch?

Ja, mit "ssh -X" wird auf dem rufenden Rechner lokal gerendert. Aber
der OP will das ja offenbar *nicht* (wenn ich die Diskussion mit
DISPLAY und xauth richtig verstanden habe), sondern ein Fenster auf
dem *gerufenen* Rechner, der eben nicht lokal ist.

Wobei es bei Setzen von DISPLAY usw. voellig egal ist, ob man
"ssh" oder "ssh -X" nimmt.

- DIrk

[Dirk Thierbach]

> Dann musst du mir mal kurz erklären, welchen Kommunikationsweg dann der
> X-Client nutzt. Mit "ssh -X" geht ein Port auf der Remote-Maschine auf,
> der Datenverkehr durch SSH tunnelt zum lokalen X. Wie geht das ohne
> diesen Port?

> Und auf welches Display setzt du eigentlich die Variable DISPLAY?

Zum mitmeisseln: Gegeben Rechner A und Rechner B. Von Rechner A
setzt man einen Aufruf an Rechner B ab.

Fall 1) "ssh -X" ohne weitere Fiesematenten. Das setzt in der Shell
auf Rechner B DISPLAY auf einen Wert, der die Tunnelung der Verbindung
zu Rechner A erlaubt. Wenn man in der Shell auf Rechner B eine X-Applikation
startet, geht das Fenster auf Rechner A auf.

Wenn ich den OP richtig verstanden habe, will er das *nicht*, weil
es "falsche" (was auch immer falsch ist) Ergebnisse mit gs produziert
(warum auch immer). Details gab es ja keine.

Fall 2) Wie weiter oben von jemand anderem diskutiert: "shh" von
Rechner A auf Rechner B. Auf Rechner B laeuft ein lokaler X-Server,
typischerweise mit Display ":0.0" oder so. In der ssh-Shell auf
Rechner B macht man "export DISPLAY=:0.0", dann holt man sich mit
root-Rechten oder wie auch immer von der passenden Stelle den MIT-Keks
und setzt ihn mit "xauth". Wenn man jetzt in der shh-Shell auf Rechner
B eine X-Applikation startet, geht das Fenster auf Rechner B auf, weil
der dortige X-Server benutzt wird. Dabei ist es voellig irrelevant, ob
shh zusaetzlich eine X-Verbindung zu Rechner A tunnelt oder nicht,
weil die gar nicht benutzt wird.

Wenn ich den OP richtig verstanden habe, meint er, dass ihm das bei
seinem Problem hilft, weil auf Rechner B ja die "richtigen" (was auch
immer das ist) Ergebnisse kommen, wenn man gs dort lokal benutzt.

Ich glaube das aber nicht, weil erstens sein Fenster jetzt auf dem
anderen Rechner aufgeht und er nichts sieht, solange er an Rechner A
sitzt, und zweitens das Problem wahrscheinlich ganz woanders liegt
(wenn er denn mal erklaeren wuerde, was er eigentlich will), und es
drittens eine Sicherheitsluecke ist.

Jetzt klarer?

- Dirk

[Dirk Thierbach]

Dirk Thierbach <dthie...@usenet.arcornews.de> wrote:
> (wenn er denn mal erklaeren wuerde, was er eigentlich will),

Nachtrag: Es wuerde mich wundern, wenn das Problem mit den Umlauten
wirklich an X liegt, weil AFAIK gs eigene Fonts verwendet, und nicht
die X-Fonts.

- Dirk

[Erhard Schwenk]

Am 04.11.2012 00:02, schrieb Oliver Sch@d:
> Dirk Thierbach wrote:

>> Wobei es bei Setzen von DISPLAY usw. voellig egal ist, ob man
>> "ssh" oder "ssh -X" nimmt.
>

> Dann musst du mir mal kurz erklï¿œren, welchen Kommunikationsweg dann der

> X-Client nutzt. Mit "ssh -X" geht ein Port auf der Remote-Maschine auf,
> der Datenverkehr durch SSH tunnelt zum lokalen X. Wie geht das ohne
> diesen Port?

Man kann selbstverstï¿œndlich X11 auch ungetunnelt ï¿œber ein IP-Netz
betreiben. Vorausgesetzt, der X-Server an der lokalen Maschine lauscht
auf dem dafï¿œr vorgesehenen TCP-Port (6000 fï¿œr :0) und man gibt in
DISPLAY den Hostnamen mit an, auf dem man das Programmfenster sehen will.

Ob man das im Einzelfall will, ist nochmal eine andere Frage - beide
Varianten haben selbstverstï¿œndlich unterschiedliche Einsatzgebiete.

> Und auf welches Display setzt du eigentlich die Variable DISPLAY?

na $LOKALE_MASCHINE:$DISPLAY (also z.B. "192.168.1.10:0"), das geht
natï¿œrlich durchaus. und wenn man noch mit xhost den Zugriff freigibt
oder xauth korrekt genutzt, sieht man sogar was :-)


Daￜ das alles ein Problem mit ghostscript lￜsen soll, bezweifle ich
indes trotzdem.

--
Erhard Schwenk

Akkordeonjugend Baden-Wï¿œrttemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/

[Sieghard Schicktanz]

Hallo Thomas,

Du schriebst am Sat, 03 Nov 2012 13:45:15 +0100:

> >> Mit "ssh -X" wird lokal gerendert, nicht remote oder verstehe ich dich
> ^^
> >> jetzt falsch?
> >

> > wenn ich das richtig sehe: Mit "ssh -Y" erh�lt der entfernte Rechner

> ^^
> > zugriff auf den lokal laufenden X-Server. Wenn also der entfernte
> > Rechner kompromittiert ist, hast du ein lokales Sicherheitsproblem.

-X Enables X11 forwarding. This can also be specified on a
per-host basis in a configuration file.
X11 forwarding should be enabled with caution...

-Y Enables trusted X11 forwarding. Trusted X11 forwardings are
not subjected to the X11 SECURITY extension controls.

--
(Weitergabe von Adressdaten, Telefonnummern u.�. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder �hnlichem)
-----------------------------------------------------------
Mit freundlichen Gr��en, S. Schicktanz
-----------------------------------------------------------

[wg]

Hallo Leute,

vielen Dank für Eure Kommentare, das Problem ist behoben.
Die Ursache, wie schon von Helmut Springer und Ullrich Horlacher
bemerkt, war ein falscher Zeichensatz.
Mit LC_ALL=POSIX klappt die Sache.

Wolf

[Juergen Ilse]

Hallo,

wg <w...@gmx.net> wrote:
> vielen Dank für Eure Kommentare, das Problem ist behoben.
> Die Ursache, wie schon von Helmut Springer und Ullrich Horlacher
> bemerkt, war ein falscher Zeichensatz.
> Mit LC_ALL=POSIX klappt die Sache.

Das setzen von "LC_ALL" ist i.a. *keine* gute Idee, da durch auch alle
seperat gesetzten local-Einstellungen in der jeweiligen shell uebersteuert
werden. Es ist i.d.R. sinnvoller, nur die LC* Environment-Variablen
umzusetzen, die man auch wirklich zu aendern gedenkt (in diesem Fall
waere das wohl LC_CTYPE, ggfs. noch LC_MESSAGES). Die Variable "LANG"
stellt den Default fuer alle nicht explizit gesetzten Einstellungen
dar, die Variable LC_ALL sollte nur in Ausnahmefaellen und mit grosser
Vorsicht verwendet werden, weil sie alle durch einzelne LC_* Variablen
gesetzten Einstellungen uebersteuert (und das ist meistens weniger
wuenschenswert).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Thomas 'PointedEars' Lahn]

Sieghard Schicktanz wrote:

> Hallo Thomas,
>
> Du schriebst am Sat, 03 Nov 2012 13:45:15 +0100:

Du möchtest Dir eine (für alle Leser) sinnvolle Einleitung angewöhnen.

>> >> Mit "ssh -X" wird lokal gerendert, nicht remote oder verstehe ich dich
>> ^^
>> >> jetzt falsch?
>> >

>> > wenn ich das richtig sehe: Mit "ssh -Y" erhält der entfernte Rechner

>> ^^
>> > zugriff auf den lokal laufenden X-Server. Wenn also der entfernte
>> > Rechner kompromittiert ist, hast du ein lokales Sicherheitsproblem.
>
> -X Enables X11 forwarding. This can also be specified on a
> per-host basis in a configuration file.
> X11 forwarding should be enabled with caution...
>
> -Y Enables trusted X11 forwarding. Trusted X11 forwardings are
> not subjected to the X11 SECURITY extension controls.

Eben. Von -Y war hier nicht die Rede, und wer das verwendet, darf sich
anschliessend nicht über Sicherheitslücken beklagen.

[wg]

On 05.11.2012 17:10, Juergen Ilse wrote:
> Hallo,
>
> wg <w...@gmx.net> wrote:
>> vielen Dank für Eure Kommentare, das Problem ist behoben.
>> Die Ursache, wie schon von Helmut Springer und Ullrich Horlacher
>> bemerkt, war ein falscher Zeichensatz.
>> Mit LC_ALL=POSIX klappt die Sache.
>
> Das setzen von "LC_ALL" ist i.a. *keine* gute Idee, da durch auch alle
> seperat gesetzten local-Einstellungen in der jeweiligen shell uebersteuert
> werden. Es ist i.d.R. sinnvoller, nur die LC* Environment-Variablen
> umzusetzen, die man auch wirklich zu aendern gedenkt (in diesem Fall
> waere das wohl LC_CTYPE, ggfs. noch LC_MESSAGES). Die Variable "LANG"
> stellt den Default fuer alle nicht explizit gesetzten Einstellungen
> dar, die Variable LC_ALL sollte nur in Ausnahmefaellen und mit grosser
> Vorsicht verwendet werden, weil sie alle durch einzelne LC_* Variablen
> gesetzten Einstellungen uebersteuert (und das ist meistens weniger
> wuenschenswert).
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
>

Ja, is klar;
in diesem Falle isses in einem shellscripte, da will ich das so.

Wolf

[Oliver Sch@d]

Dirk Thierbach wrote:


> Ich glaube das aber nicht, weil erstens sein Fenster jetzt auf dem
> anderen Rechner aufgeht und er nichts sieht, solange er an Rechner A
> sitzt, und zweitens das Problem wahrscheinlich ganz woanders liegt
> (wenn er denn mal erklaeren wuerde, was er eigentlich will), und es
> drittens eine Sicherheitsluecke ist.
>
> Jetzt klarer?

In Teilen. An welcher Stelle kommt jetzt die Sicherheitslücke zum Tragen?

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> In Teilen. An welcher Stelle kommt jetzt die Sicherheitslücke zum Tragen?

Die Sicherheitsluecke im Fall 2 besteht darin, dass Zugriff auf den
lokalen Server auf Rechner B erlaubt werden muss ("durch welche
Methode wie auch immer"). Wenn dieser Zugriff erteilt ist, kann man den
Benutzer, der gerade zufaelligerweise vor Rechner B sitzt, komplett ueber
die ssh-Verbindung ausspionieren: Alle seine Eingaben (und Passwoerter)
mitlesen, ihm gefaelschte Fenster unterjubeln usw.

Deswegen sollten normalerweise nur Prozesse, die dem Benutzer gehoeren,
der vor dem Bildschirm des entsprechenden X-Servers sitzt, auch Zugriff
auf diesen X-Server haben.

- Dirk

[Oliver Sch@d]

Dirk Thierbach wrote:

> Oliver Sch@d
> <spam.entfernen.und.bring...@oschad.de> wrote:
>> In Teilen. An welcher Stelle kommt jetzt die Sicherheitslücke zum
>> Tragen?
>
> Die Sicherheitsluecke im Fall 2 besteht darin, dass Zugriff auf den
> lokalen Server auf Rechner B erlaubt werden muss ("durch welche
> Methode wie auch immer"). Wenn dieser Zugriff erteilt ist, kann man den
> Benutzer, der gerade zufaelligerweise vor Rechner B sitzt, komplett
> ueber die ssh-Verbindung ausspionieren: Alle seine Eingaben (und
> Passwoerter) mitlesen, ihm gefaelschte Fenster unterjubeln usw.

Also wenn man schon Root-Rechte auf der Kiste hat, ist das wohl kaum noch
als Sicherheitslücke zu klassifizieren, dass man dann lokale Prozesse
beobachten kann.

Ohne Root-Rechte muss der am X arbeitende Benutzer aber freiwillig die
Rechte dafür rausrücken - was dann wohl auch keine Sicherheitslücke ist.

Natürlich *könnte* rein theoretisch der X-Server auch ohne Einschränkungen
laufen, dann wäre das aber eine Konfiguration, die so im
Auslieferungszustand der meisten Distributionen doch nicht zu finden ist,
also bewusst herbeigeführt wäre.

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> Dirk Thierbach wrote:

>> Oliver Sch@d
>> <spam.entfernen.und.bring...@oschad.de> wrote:
>>> In Teilen. An welcher Stelle kommt jetzt die Sicherheitslücke zum
>>> Tragen?

>> Die Sicherheitsluecke im Fall 2 besteht darin, dass Zugriff auf den
>> lokalen Server auf Rechner B erlaubt werden muss ("durch welche
>> Methode wie auch immer"). Wenn dieser Zugriff erteilt ist, kann man den
>> Benutzer, der gerade zufaelligerweise vor Rechner B sitzt, komplett
>> ueber die ssh-Verbindung ausspionieren: Alle seine Eingaben (und
>> Passwoerter) mitlesen, ihm gefaelschte Fenster unterjubeln usw.

> Also wenn man schon Root-Rechte auf der Kiste hat, ist das wohl kaum noch
> als Sicherheitslücke zu klassifizieren, dass man dann lokale Prozesse
> beobachten kann.

Aber man kann den Keks auch ohne Root-Rechte verteilen. Z.B. durch
Aenderung der Zugriffsrechte auf die Datei, in der er gespeichert ist.
Oder durch einen Eintrag in sudo. Oder "durche welche Methode auch
immer".

Ja, das muss einmal Root machen. Aber danach darf es der, der sich mit
shh einloggt. Was man fuer solche Konstruktion wie "Fehler darueber
beheben, dass man einen anderen X Server benutzt" tun muesste. Weil
das ja ziemlich sicher nicht von Root benutzt werden soll, sondern
von einem normalen Benutzer.

Und wenn man das tut, sollte man sich halt ueber die Konsequenzen
dessen klar sein. Das ist alles. Ich habe nicht behauptet: "Die
Schutzmechanismen von xauth sind kaputt". Ich habe behauptet: "Wenn
man sie umgeht, hat das Folgen. Es gibt einen guten Grund dafuer, dass
diese Schutzmechanismen da sind".

Und falls es unklar war: Es geht nicht darum, "lokale Prozesse zu
beobachten". Man hat Zugriff auf das Interface zwischen Programm
und Benutzer (nicht auf die Prozesse selbst).

- Dirk

[Wolfgang Meiners]

Am 05.11.12 18:21, schrieb Thomas 'PointedEars' Lahn:

Dirk Thierbach schrieb von einer Sicherheitslücke und er schrieb das so,
dass es für mich nicht ganz verständlich war, wo das Problem liegt. Auch
die manpage von ssh ist da meiner Meinung nach nicht ganz eindeutig. So
wird man bei der Option -X gewarnt, X11 forwarding should be enabled
with caution, aber bei der Option -Y, die viel gefährlicher ist, steht
keine Warnung.

Wenn ich das richtig verstanden habe, verhindern die security extensions
bei -X, dass allzu schlimmes passiert, während das bei -Y nicht so ist,
der lokale XServer also dem entfernten Rechner schutzlos ausgeliefert ist.

Die Sicherheitsempfehlung müsste also lauten: Benutze ssh -X nur dann,
wenn es nötig ist. Vermeide ssh -Y immer dann, wenn es möglich ist.

Schlimmer ist allerdings: In der /etc/ssh/ssh_config meines Ubuntu steht
ForwardX11Trusted yes
und damit sind -X und -Y äquivalent!

Grüße
Wolfgang

[Dirk Thierbach]

Wolfgang Meiners <Wolfgang...@web.de> wrote:
> Dirk Thierbach schrieb von einer Sicherheitslücke und er schrieb das so,
> dass es für mich nicht ganz verständlich war, wo das Problem liegt. Auch
> die manpage von ssh ist da meiner Meinung nach nicht ganz eindeutig. So
> wird man bei der Option -X gewarnt, X11 forwarding should be enabled
> with caution, aber bei der Option -Y, die viel gefährlicher ist, steht
> keine Warnung.

Die Sicherheitsluecke kommt dadurch zustande, dass man den
Authentifizierungs-Keks einem normalen Benutzer gibt, der sich dann
mit dem lokalen X-Server verbinden kann, auch wenn er sich von einem
entfernten Rechner einloggt.

Und die Beziehung dazu haette eigentlich auch daraus klar werden
sollen, dass sie als Antwort auf den Vorschlag kam, genau das zu
tun. Ja, man kann das tun, und manchmal ist es sinnvoll, und ich habe
das auch selbst schon gemacht, aber man sollte halt ueber die
Konsequenzen Bescheid wissen. Das ist alles.

Das hat weder mit "shh -X" noch mit "ssh -Y" noch mit X11-Forwarding
per ssh auch nur das Geringste zu tun.

- Dirk

[Oliver Sch@d]

Dirk Thierbach wrote:

> Und wenn man das tut, sollte man sich halt ueber die Konsequenzen
> dessen klar sein. Das ist alles.

Den Hinweis finde ich gut und richtig, dennoch würde ich das nicht als
Sicherheitslücke klassifizieren.

> Ich habe nicht behauptet: "Die
> Schutzmechanismen von xauth sind kaputt". Ich habe behauptet: "Wenn
> man sie umgeht, hat das Folgen. Es gibt einen guten Grund dafuer, dass
> diese Schutzmechanismen da sind".

ACK

> Und falls es unklar war: Es geht nicht darum, "lokale Prozesse zu
> beobachten". Man hat Zugriff auf das Interface zwischen Programm
> und Benutzer (nicht auf die Prozesse selbst).

Klar, nur wenn man schon Root-Rechte hat, kann man auch weit mehr, als
eine bestimmte Schnittstelle belauschen.

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> Dirk Thierbach wrote:

>> Und wenn man das tut, sollte man sich halt ueber die Konsequenzen
>> dessen klar sein. Das ist alles.

> Den Hinweis finde ich gut und richtig, dennoch würde ich das nicht als
> Sicherheitslücke klassifizieren.

Ich kenne Deine Definition von Sicherheitsluecke nicht, aber wenn ich
als Administrator ein Problem der Art "Normalnutzer hat Umlautprobleme
per shh" dadurch loese (mal angenommen, es ginge) dass ich ihm
Zugriffsrechte auf den lokalen X-Server gebe, dann mache ich damit
eine Sicherheitsluecke auf. Weil der Benutzer damit wesentlich mehr
kann, als nur seine Umlautprobleme loszuwerden.

Wenn Du es anders nennen willst, bitte, ich habe nichts dagegen.
Ich streite nicht um Worte.

> Klar, nur wenn man schon Root-Rechte hat, kann man auch weit mehr, als
> eine bestimmte Schnittstelle belauschen.

Nochmal: Derjenige mit Root-Rechten und derjenige, der sich mit
ssh einloggt, muessen nicht identisch sein. Und derjenige, der
den Keks bekommt, kann damit erstmal NUR eine bestimmte Schnittstelle
belauschen. Root-Rechte hat er damit noch lange nicht. Die kriegt
er erst, wenn er z.B. die entsprechende Passworteingabe belauscht.
Weil der Administrator nicht gewusst hat, was er ihm damit ermoeglicht.

- Dirk

[Wolfgang Meiners]

Am 06.11.12 14:08, schrieb Dirk Thierbach:

> Wolfgang Meiners <Wolfgang...@web.de> wrote:
>> Dirk Thierbach schrieb von einer Sicherheitslücke und er schrieb das so,
>> dass es für mich nicht ganz verständlich war, wo das Problem liegt. Auch
>> die manpage von ssh ist da meiner Meinung nach nicht ganz eindeutig. So
>> wird man bei der Option -X gewarnt, X11 forwarding should be enabled
>> with caution, aber bei der Option -Y, die viel gefährlicher ist, steht
>> keine Warnung.
>
> Die Sicherheitsluecke kommt dadurch zustande, dass man den
> Authentifizierungs-Keks einem normalen Benutzer gibt, der sich dann
> mit dem lokalen X-Server verbinden kann, auch wenn er sich von einem
> entfernten Rechner einloggt.
>

Ja. Jetzt habe ich dein Argument glaube ich verstanden. Der Remote-user
hat meinen Cookie von mir bekommen. Dann kann er
- sich auf meinem Rechner einloggen und mit meinem Cookie auf meinen
XServer zugreifen, oder
(wenn mein XServer an TCP lauscht)
- direkt über DISPLAY=Mein_Rechner:Mein_Display auf meinen XServer
zugreifen, oder
- sich auf meinem Rechner aus der Ferne anmelden (z.B. mit ssh) und
wieder auf meinen XServer zugreifen, oder
(und das hat jetzt wohl mit ssh zu tun)
- sich auf dem entfernten Rechner anmelden und über localhost:10.0 auf
meinen XServer zugreifen. Habe ich noch was vergessen?

Ich hatte immer nur den letzten Weg gesehen und da ist ssh -X nicht so
gefährlich wie ssh -Y, jedenfalls wenn ForwardX11Trusted no in der
entsprechenden config-Datei gesetzt ist.

Grüße
Wolfgang

[Dirk Thierbach]

Wolfgang Meiners <Wolfgang...@web.de> wrote:
> Ja. Jetzt habe ich dein Argument glaube ich verstanden. Der Remote-user
> hat meinen Cookie von mir bekommen.

Genauer: Den Keks des X-Servers, vor dem Du gerade sitzt. Der ist
nicht personalisiert (wird aber ggf. fuer jede X-Session neu erzeugt,
da bin ich mir gerade nicht sicher).

> Dann kann er
> - sich auf meinem Rechner einloggen und mit meinem Cookie auf meinen
> XServer zugreifen, oder

Fuer "einloggen = nicht ueber den Bildschirm, der vom X Session
Manager controlliert wird, sondern auf andere Weise (telnet, serielle
Schnittstelle, ...)": Ja.

> (wenn mein XServer an TCP lauscht)
> - direkt über DISPLAY=Mein_Rechner:Mein_Display auf meinen XServer
> zugreifen, oder

Ja.

> - sich auf meinem Rechner aus der Ferne anmelden (z.B. mit ssh) und
> wieder auf meinen XServer zugreifen, oder

Ja.

> (und das hat jetzt wohl mit ssh zu tun)
> - sich auf dem entfernten Rechner anmelden und über localhost:10.0 auf
> meinen XServer zugreifen. Habe ich noch was vergessen?

Das geht so nicht. X11-Forwarding ueber ssh setzt auf dem Zielrechner
DISPLAY auf Werte wie "localhost:10.0" und sorgt dafuer dass die
entsprechende Verbindung, die fuer Programme wie eine lokale Verbindung
aussieht, getunnelt wird.

Wenn sich der Remote-user also nur auf dem Remote-Rechner anmeldet,
gibt es kein ssh und keine getunnelte Verbindung. Und selbst wenn man
eine solche aufbauen wuerde, benutzt die einen ganz andere Keks, als
der, der ihm verraten wurde.

Das Problem mit X11-Forwarding ist ein ganz anderes:

X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X11 authorization database) can access the local X11 dis‐
play through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring if the
ForwardX11Trusted option is also enabled.

Sprich, ein Benutzer Q an Rechner A macht eine ssh-Verbindung nach
Rechner B mit X11-Forwarding auf. Die Idee ist, dass nur die Prozesse
von Benutzer Q auf Rechner B diese Verbindung benutzen (damit er an
Rechner A deren Fenster sehen kann). Wenn aber auf Rechner B ein
Benutzer R mit Root-Rechten sitzt, kann er den Keks fuer die
getunnelte Verbindung von Benutzer Q klauen (weil er die .Xauthority
auf Rechner B von Benutzer Q lesen kann), und selbst den Tunnel
benutzen. Damit kann Benutzer R den Benutzer Q auf Rechner A
ausspaehen, obwohl R eigentlich nur die Root-Rechte auf Rechner B hat,
und nicht auf Rechner A.

Wenn man so will, ist das die Umkehrung des Falles, den ich mit
"Sicherheitsluecke, wenn der Keks von Rechner B verraten wird" meinte:
Derjenige auf Rechner A, der ssh benutzt, kann nicht jemand anders
ausspaehen, sondern wird selbst ausgespaeht.

Auf jeden Fall eine ganz andere Baustelle.

- Dirk

[Oliver Sch@d]

Dirk Thierbach wrote:

> Oliver Sch@d
> <spam.entfernen.und.bring...@oschad.de> wrote:
>> Dirk Thierbach wrote:
>
>>> Und wenn man das tut, sollte man sich halt ueber die Konsequenzen
>>> dessen klar sein. Das ist alles.
>
>> Den Hinweis finde ich gut und richtig, dennoch würde ich das nicht als
>> Sicherheitslücke klassifizieren.
>
> Ich kenne Deine Definition von Sicherheitsluecke nicht,

Wenn die Ansprüche an Sicherheit nicht erfüllt sind - das ist natürlich
relativ. Ich wäre nie auf die Idee gekommen, die von dir herausgestellten
Konsequenzen *nicht* zu beachten.

Da das aber durchaus nicht offensichtlich ist, ist es gut darauf
hinzuweisen. In dcoulm ist das aber vermutlich wie Eulen nach Athen tragen
diese Sicherheitsimplikation in sofern auch nicht als Lücke zu verstehen.

Denn wenn man die Konsequenzen beachtet, dann gibt es ja keine Verletzung
der Sicherheit.

[Oliver Sch@d]

Dirk Thierbach wrote:

> Wolfgang Meiners <Wolfgang...@web.de> wrote:
>> Ja. Jetzt habe ich dein Argument glaube ich verstanden. Der Remote-user
>> hat meinen Cookie von mir bekommen.
>
> Genauer: Den Keks des X-Servers, vor dem Du gerade sitzt. Der ist
> nicht personalisiert (wird aber ggf. fuer jede X-Session neu erzeugt,
> da bin ich mir gerade nicht sicher).

Wird er.

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> Dirk Thierbach wrote:

>> Ich kenne Deine Definition von Sicherheitsluecke nicht,

> Wenn die Ansprüche an Sicherheit nicht erfüllt sind - das ist natürlich
> relativ.

Ich dagegen wuerde jeden Vorgang der Art "Benutzer X hat nur gewisse
Privilegien, und kann sich damit zusaetzlich Previlegien verschaffen"
als Sicherheitsluecke sehen. Aber wie gesagt, ich streite nicht um
Worte. Wenn Dir "privilege escalation" lieber ist, nimm diesen Begriff.
Oder einen anderen.

> Ich wäre nie auf die Idee gekommen, die von dir herausgestellten
> Konsequenzen *nicht* zu beachten.

> Da das aber durchaus nicht offensichtlich ist, ist es gut darauf
> hinzuweisen. In dcoulm ist das aber vermutlich wie Eulen nach Athen tragen

Das glaube ich nicht. Den wenigsten Leuten ist klar, wie unsicher das
X-Protokoll ist. Wenn man jemandem erklaeren muss, auf welche Art man
sich mit einem lokalen X-Server verbinden muss, dann wuerde ich in der
Regel davon ausgehen, dass ihm die Sicherheitsimplikationen nicht klar
sind.

Und an der Diskussion sieht man ja, dass den meisten Leuten offenbar
noch nicht mal klar ist, *warum* X11-Forwarding ueber ssh unsicher sein
kann. Obwohl es eigentlich in der man-page erklaert ist.

> Denn wenn man die Konsequenzen beachtet, dann gibt es ja keine Verletzung
> der Sicherheit.

Das ist nach Deinen Definitionen richtig, aber letztlich eine Nullaussage.

Dann laege ja nie einer Verletzung der Sicherheit vor, da sich ein
guter Admin ja stets der Konsequenzen bewusst ist.

- Dirk

[Wolfgang Meiners]

was ich gerade konkret ausprobiert habe:

Rechner L (lokal)
Rechner R (Remote)

auf L gibt als user_L ein:
L$ ssh -X user_R@R

auf R loggt sich user_R ein, öffnet ein Terminal
und tippt

R$ export XAUTHORITY=.Xauthority
R$ export DISPLAY=localhost:10.0
R$ xeyes &

Damit wird auf Rechner L xeyes dargestellt. Dafür wird der Tunnel
genutzt, den user_L aufgemacht hat.

Das ganze funktioniert mit OSX 10.8 auf Rechner L als Betriebssystem und
Ubuntu 10.04 mit gnome auf Rechner R als Betriebssystem. Wenn ich nun
auf Rechner R Rootrechte habe, kann ich einfach mit
sudo su - user_R
zu dem entsprechenden User werden. Kenne ich nur das Passwort von
user_R, geht immer noch
su - user_R
oder ich melde mich gleich direkt an.

Bin ich ein anderer User an R und habe den Cookie, den ssh erzeugt hat
und der das Display localhost:10.0 benutzt, dann kann ich den einfach in
eine eigene Datenbank packen (mittels xauth add) und auch dann auf das
Display von L zugreifen. Aber um den Cookie zu bekommen, muss ich das
Kennwort von user_R kennen oder dort Rootrechte haben. Dann kann ich
mich auch gleich als user_R dort anmelden.

Wenn ich ssh -X nutze, reiße ich aber keine weitere Sicherheitslücke
auf, weil doch ssh ein Cookie erzeugt, dass mit meinem lokalen nicht
übereinstimmt. Oder übersehe ich da was?

Grüße
Wolfgang

[Dirk Thierbach]

Wolfgang Meiners <Wolfgang...@web.de> wrote:
> was ich gerade konkret ausprobiert habe:
>
> Rechner L (lokal)
> Rechner R (Remote)
>
> auf L gibt als user_L ein:
> L$ ssh -X user_R@R
>
> auf R loggt sich user_R ein, öffnet ein Terminal
> und tippt
>
> R$ export XAUTHORITY=.Xauthority
> R$ export DISPLAY=localhost:10.0
> R$ xeyes &
>
> Damit wird auf Rechner L xeyes dargestellt. Dafür wird der Tunnel
> genutzt, den user_L aufgemacht hat.

Das funktioniert aber nur, weil sich jetzt user_R zweimal auf Rechner R
eingeloggt hat, einmal direkt und einmal ueber ssh. Der interessante
Fall ist der, dass diese beiden Benutzer auf Rechner R verschieden sind.

> Bin ich ein anderer User an R und habe den Cookie, den ssh erzeugt hat
> und der das Display localhost:10.0 benutzt, dann kann ich den einfach in
> eine eigene Datenbank packen (mittels xauth add) und auch dann auf das
> Display von L zugreifen. Aber um den Cookie zu bekommen, muss ich das
> Kennwort von user_R kennen oder dort Rootrechte haben. Dann kann ich
> mich auch gleich als user_R dort anmelden.

Richtig.

> Wenn ich ssh -X nutze, reiße ich aber keine weitere Sicherheitslücke
> auf, weil doch ssh ein Cookie erzeugt, dass mit meinem lokalen nicht
> übereinstimmt. Oder übersehe ich da was?

Ja, hast Du. Wenn jemand Rootrechte auf Rechner R hat, oder aus einem
anderen Grund die .Xauthority von user_R lesen kann, dann kann er, wie
Du richtig festgestellt hast, auf das Display von L zugreifen.

Jetzt kommt der interessante Punkt: Er kann diese Verbindung ausnutzen,
um ALLE Aktionen von user_L auf Display L zu verfolgen. Auch mit ganz
anderen Fenstern. Das hast Du nicht ausprobiert, weil Du nicht weisst,
wie es geht. Und ich verrate Dir auch nicht, wie es geht. :-)

Mit anderen Worten, wenn user_L jetzt auf Rechner L einen Browser
benutzt und ein paar Bankgeschaefte taetigt, kann der Angreifer von
Rechner R das verfolgen. Obwohl der Browser gar nicht auf Rechner R
laeuft. Oder wenn user_L sein Passwort auf Rechner L eintippt, kann
der Angreifer sich da merken und sich selbst als user_L auf Rechner L
einloggen.

Und das alles, obwohl der Angreifer eigentlich nur Root-Rechte auf
Rechner R hatte. Und auf Rechner L vielleicht ueberhaupt gar keine
Rechte hat, oder sich nicht mal einloggen darf.

Der Angreifer kann also die X11-Forwarding-Verbindung von user_L dazu
ausnutzen, mehr Rechte auf Rechner L zu bekommen, als er hatte, und
user_L auszuspaehen.

*Das* ist das Problem mit "ssh -X". User_L koennte ja denken "jemand
mit Root-Rechten auf Rechner R kann dort zwar alles lesen, was ich
tue, aber wenn ich dort nichts Privates tue, sondern das nur
auf meinem lokalen Rechner L mache, bin ich sicher". Das ist aber ein
Irrtum, solange der X11-Forwarding-Tunnel offen ist.

- Dirk

[Oliver Sch@d]

Dirk Thierbach wrote:

> Dann laege ja nie einer Verletzung der Sicherheit vor, da sich ein
> guter Admin ja stets der Konsequenzen bewusst ist.

Geht ja kaum, wenn es um Software-Fehler geht. Aber bei konzeptionellen
Fehlern wäre ich da bei dir.

[Dirk Thierbach]

Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> Dirk Thierbach wrote:

>> Dann laege ja nie einer Verletzung der Sicherheit vor, da sich ein
>> guter Admin ja stets der Konsequenzen bewusst ist.

> Geht ja kaum, wenn es um Software-Fehler geht. Aber bei konzeptionellen
> Fehlern wäre ich da bei dir.

Na ja, der Unterschied dazwischen ist sehr vage (falls Du mit
"konzeptionellen Fehlern" nicht "das Sicherheitskonzept" meinst, siehe
unten). Man kann immer mal wieder Software auf eine Art benutzen, an
die vorher keiner gedacht hat, und damit mehr tun, als man eigentlich
darf. Ich nenne das eben "Sicherheitsluecken": Die Leute bleiben nicht
brav im abgesperrten Bereich, sondern koennen durch eine Luecke im
Zaun klettern, die vorher keiner gesehen hat. Wenn sie die Luecke
entdecken.

Ob das nun durch Fehler (Bugs), nicht genuegend Paranoia beim
Programmieren, oder Benutzen eines Designs (z.B. dem X-Protokoll) in
einem Kontext, fuer das es nicht entworfen worden ist; kreativer
Kombination von Dingen, die alleine harmlos sind; oder
side-channel-attacks passiert ist dabei relativ egal.

Das ist uebrigens etwas *voellig* anderes als "Luecken im
Sicherheitskonzept". Falls Du das mit "Sicherheitsluecke" meinst.

Ueber die kann man aber nur reden, wenn man das Konzept ueberhaupt
erstmal explizit macht. Worum es in der Diskussion nie ging.

- Dirk