[Sonstiges] Fernwartung mit VNC, RDP oder anders?

[sia]

Hi Leute,

Unter Linux nutze ich gerne TigerVNC oder x2go-agent als Server für GUI-Fernwartungsaufgaben.

Was funktioniert eurer Meinung denn unter Windows am Besten? TigerVNC hängt schon ziemlich. Ist RDP da besser?

Anforderungen wäre nur, dass ich mit

You do not have permission to view link please Anmelden or Registrieren

oder

You do not have permission to view link please Anmelden or Registrieren

darauf zugreifen kann. Bonus: über Chocolatey auf den Clients installierbar.

 

[Novgorod]

ich bin erst kürzlich auf

You do not have permission to view link please Anmelden or Registrieren

gestoßen und hab noch nie einen schnelleren remote-client gesehen .. bisher war RDP immer die beste lösung für windows gewesen (aber nicht simultan mit dem lokalen user möglich), aber anydesk haut es locker weg, deren codec ist unschlagbar! ich weiß allerdings nicht wie gut das unter linux funktioniert und es gibt leider (noch) keinen android-client..

 

[sia]

You do not have permission to view link please Anmelden or Registrieren

Klingt interessant, aber das ist doch nur in der Cloud, oder?

Unsere Server setzen auf Erlang

– Erlang läuft unter Linux, das wäre nicht das Problem. Aber die geben die Serversoftware vermutlich nicht raus. Die Netzwerk-Appliance

You do not have permission to view link please Anmelden or Registrieren

"auf Anfrage"…

Kann RDP wirklich kein Screensharing? Ich meine, dass eine Firma, in der ich mal gearbeitet hatte, das, was derjenige am PC sehen konnte auch auf dem Schirm hatte, also quasi 1:1-Darstellung. Muss bei RDP immer eine eigene Sitzung gestartet werden? Dann ist das unpassend :/

 

[Novgorod]

anydesk ist nicht teamviewer (obwohl es von aussteigern von teamviewer entwickelt wurde) - es nutzt immer eine direktverbindung falls möglich und geht nur als fallback über deren server (und für die namensauflösung, falls man deren alias-system nutzen will).. die exe ist client und server in einem und lässt sich wie vnc als dienst einrichten.. ich setze es regelmäßig im LAN ohne internetzugriff ein, überhaupt kein problem - in dem fall muss man die IP-adresse oder den windows-computernamen eingeben..

ich habe mal irgendwann einen workaround gesehen, wie screensharing mit RDP geht, das war aber in meiner erinnerung ein riesen gefrickel.. ich glaube das nennt sich "remote-unterstützung" und muss vom zielrechner initiiert werden (ähnlich wie die ganzen teamviewer-derivate von den support-scammern ), aber die engine dahinter ist RDP.. das gefrickel besteht darin, diese remoteunterstützung auf dem zielrechner zu initiieren, ohne dass jemand davor sitzt und das aktiv tut (über ein RPC-skript glaub ich)..

also tu dir nen gefallen und teste erstmal anydesk in deinem netzwerk, bevor du zu verzweifelten RDP-maßnahmen greifst .. die bezahlservices dort sind soweit ich weiß professionelle cloud-dienste und eigene firmen-aliase.. ich weiß allerdings nicht, ob du für kommerzielle nutzung des normalen server/clients eine lizenz brauchst (oder ob das überhaupt nachprüfbar ist)..

 

[Mephisto]

You do not have permission to view link please Anmelden or Registrieren

Kann RDP wirklich kein Screensharing? Ich meine, dass eine Firma, in der ich mal gearbeitet hatte, das, was derjenige am PC sehen konnte auch auf dem Schirm hatte, also quasi 1:1-Darstellung. Muss bei RDP immer eine eigene Sitzung gestartet werden? Dann ist das unpassend :/

Screensharing ist mit RDP nicht möglich. Wenn du mit Windows Tools ein Screensharing nutzen möchtest mußt du mit Remote Assistance (Remoteunterstützung) arbeiten.
RDP und Remoteunterstützung sind normalerweise teil von Windows.

 

[Novgorod]

jau, das steht so auch im post über dir ..

 

[drfuture]

die Remote Assistance ist nichts anders als RDP... - du nutzt ja auch keine rdp.exe sondern z.B. mstsc wobei es dafür auch div. andere Clients gibt.

*gefrickl* ist gut.. einfach msra.exe /offerra eingeben und den hostnamen dem man unterstützung anbieten möchte.
Nachteil hier:
-*drüben* muss einer sitzen der ja sagt (in der fremden Sitzung)
- Man muss im Lan sein - da das halt nicht nach draußen geht.

Insofern man am Gerät angemeldet ist macht rdp keine neue Sitzung - man kann sich selbstverständlich in der laufenden Sitzung anmelden und diese übernehmen insofern man Username und Passwort hat.

Eine *schöne* Lösung die im Lan läuft über Guacamole und ich von extern im Browser auf nen Windows Client komme währe schon was... da kenne ich aktuell auch nichts.
Außer eben die div. Cloud-Anbieter.
Wobei AnyDesk echt Cool ist - n kollege von mir hat Priv. dort ein wenig mitgeholfen - allerdings nur Netzwerktechnisch - ist kein Entwickler...

 

[Novgorod]

na das meine ich doch mit gefrickel - wenn für remotezugriff jemand am anderen ende vor der kiste sitzen muss, hat's in 90% der fälle den sinn verfehlt.. das gefrickel ist der workaround, damit es auch "unattended" geht..

und natürlich geht RDP auch übers internet - wie kommst du drauf, dass man dafür im LAN sein muss? man muss nur den entsprechenden port offen haben, so wie auch bei VNC & co..

 

[drfuture]

Ja klar wenn ich für jeden PC im Lan den port ändere und alle Ports forwarde geht das...
anydesk, teamviewer und ähnliche gehen ohne Portforwarding.
Ebenso kann man im Lan eine Oberfläche wie von phre4k oben verlinkt zur Verfügung stellen und damit auf einer Geschützen Webseite den Zugriff bündeln - in dem Fall erfolg der Zugriff aber wieder nur im Lan und die Software tunnelt nach draußen.

unattend geht es wenn man sich selber anmeldet bzw. das passwort des angemeldeten users kennt - dann ist man wie gesagt auch direkt in der Sitzung des angemeldeten Benutzers.

Das man nicht direkt ohne Information + Zutun eines 3. unbekannten Benutzers kommt ist durchaus recht vernünftig.

 

[Novgorod]

anydesk, teamviewer und ähnliche gehen ohne Portforwarding.

das geht über drittserver, was performance- und sicherheitstechnisch nicht wirklich optimal ist, und außerdem ist es die gängige methode, nutzern künstliche kosten aufzudrücken (oder z.b. die laufzeit der verbindung zu limitieren).. und wenn man ein größeres netzwerk mit vielen rechnern administrieren will, empfiehlt sich eh eine VPN-verbindung, damit ist dann auch das port forwarding kein thema mehr.. anydesk unterstützt (und bevorzugt) übrigens direktverbindungen, daher ist dort die "cloud"-verbindung nur ein bonus, keine pflicht..

unattend geht es wenn man sich selber anmeldet bzw. das passwort des angemeldeten users kennt - dann ist man wie gesagt auch direkt in der Sitzung des angemeldeten Benutzers.

ja, aber der lokale benutzer bekommt einen sperr-screen, darum gehts hier doch gerade.. RDP unterstützt ohne gefummel kein unattended screensharing und das nervt in einigen situationen - der lokale user wird unerwartet rausgeschmissen (und kann dich seinerseits rausschmeißen) und nachdem man mit dem remoten fertig ist, wird er nicht automatisch wieder eingeloggt, sondern der rechner bleibt für immer gesperrt.. das nervt, wenn der rechner z.b. als informationsanzeige o.ä. genutzt wird.. keine andere remote-control-software sperrt den lokalen user aus, nur MS hat die extrawurst ..

 

[drfuture]

das es über drittserver geht und das es die obigen Nachteile hat ist mir klar - ich nutze teamviewer auch nirgends wo es relevant ist das die Verbindung geht, um fremden kurz zu helfen ist es schnell und praktisch.
AnyDesk habe ich ja oben auch schon gelobt

Die Idee des RemoteZugriffs ist schlicht eine andere - die sich halt zumindest für mich nicht beißt.
Wenn jemand vor dem PC sitzt kann und MUSS dieser meiner Meinung nach auch persönlich zustimmen das ich seinen Bildschirm sehen darf (Ist im Geschäftsumfeld sogar im Datenschutzgesetzt vorgeschrieben).
Folglich macht es msra.exe genau richtig.
Für den Fall das ich nicht in die Sitzung eines Benutzers muss und so Administrativ auf den PC muss - wobei da eh 99% schneller und schöner über die Console funktionieren - dann ist die 2. Methode das der Benutzer gesperrt wird korrekt. Dieser hat beim verlassen des PC's so oder so den Rechner zu sperren - folglich passiert hier nichts unerwartetes - das er sich wieder anmelden muss.

RDP hat einen viel größeren Nachteil - das die UAC bei der Remote-Unterstützung (msra) nicht funktioniert. Das ist eher ein Ausschlusskriterium.
Und für den Sonderfall eines InfoScreens ohne Tastatur usw. ist RDP ebenso keine Lösung. Dafür ist dann VNC bekanntermaßen recht beliebt - aber eben nicht so performant.

Kommerziell gibt es noch einige Lösungen, InHouse nutze ich die Remote-Unterstützung des Microsoft ConfigMgr - nur besteht diese Option für Kleinunternehmen nicht.
Die Ideale Lösung - die für mich eine art Teamviewer zum selberhosten ist - habe ich leider ebenso nicht gefunden.

 

[Novgorod]

ja, mir gehts nicht um große unternehmen mit generalstabsmäßigen richtlinien, sondern um ein umfeld, wo die user größtmögliche freiheit haben oder rechner "gleichberechtigt" teilen (privatnutzung, rechen-workstation, laborrechner, "special interest" o.ä.) - letztlich kann keine software mit ihren standardeinstellungen es allen richtilinien, die eine firma haben könnte, recht machen.. dass RDP standardmäßig den angemeldeten user rausschmeißt, ist eine unnötige unannehmlichkeit und könnte auch problemlos lediglich eine option sein (haken: "lokalen desktop sperren").. der zwang bietet überhaupt keinen mehrwert an sicherheit, weil sich der user jederzeit wieder selbst einloggen (und den remote-user rauswerfen) kann und weil man ja trotzdem den bildschirm ggf. ohne einwilligung sieht, wenn man die session übernimmt, hat aber die beschriebenen nachteile (man muss sich vorher vergewissern, dass gerade niemand am rechner arbeitet und man kann den rechner nicht im ursprünglichen zustand hinterlassen, wenn er nicht gesperrt war).. wieso hat denn kein anderes remote-desktop tool den sperr-zwang wie RDP (aussperren ist optional trotzdem möglich, nur eben kein zwang)? vielleicht weil es schwachsinn ist ..

und wie gesagt, anydesk kommt ziemlich nah an die ideale lösung zum selberhosten - und wenn man deren nameservice nutzt, kombiniert das die simplizität von dyndns & co. mit der kontrolle des selberhostens.. wenn die endlich mal aus dem arsch kommen und den seit 5 jahren versprochenen android-client rausbringen würden, wäre es wirklich perfekt ..

 

[PLanB]

Das stimmt so nicht novgorod. Den Bildschirm ohne Einwilligung siehst du selbstverständlich nicht, schließlich hast du ja nicht das Passwort des angemeldeten Nutzers. Sollte dies so sein gibt es ein generelles Problem, denn Shared Secrets sind gerade bei Systembenutzern keine gute Idee.

Ich habe für diesen Anwendungsfall bei uns eine Lösung mittels Tightvnc und SSH Tunnel zur verschlüsselung realisiert. Tightvnc fragt beim angemeldeten Nutzer nach ob die Session geteilt werden soll. Das ist aus Datenschutzrechtlichen Gründen auch die einzige sinnvolle Lösung.

Ist kein Benutzer lokal da um die Meldung zu akzeptieren kann auch RDP verwendet werden, ist ja eh kein Nutzer aktuell am Rechner der rausgeworfen wird.

Nur mein Kleingeld zum Thema.

 

[keinbenutzername]

wir nutzen hier dameware. Ist auch ziemlich mächtig.
Wie es da aber mit Linux aussieht, keine Ahnung...

 

[sia]

You do not have permission to view link please Anmelden or Registrieren

TightVNC hat einen netten Nachfolger namens TigerVNC, schau dir das mal an. Finde ich besser, insbesondere das Polling funktioniert schneller.

Tightvnc fragt beim angemeldeten Nutzer nach ob die Session geteilt werden soll. Das ist aus Datenschutzrechtlichen Gründen auch die einzige sinnvolle Lösung.

Finde ich nicht. Wenn im Fernwartungsvertrag drin steht, dass die Fernwartung bei nicht angemeldeten Benutzern stattfinden darf und ansonsten nur bei Initiation durch den Nutzer, finde ich das unproblematisch. Habe bisher auch keine Urteile zum Datenschutz gefunden und auch ein befragter Anwalt findet das okay.

Muss halt geloggt werden, wann wo zugegriffen wird…

 

[drfuture]

ja aber genau die Anforderung macht ja rdp / remote unterstützung genauso ^^
Das einzige was nicht geht und Novgorod möchte ist direkt in die Sitzung des Benutzers ohne das er was mitbekommt.

 

[Novgorod]

Das einzige was nicht geht und Novgorod möchte ist direkt in die Sitzung des Benutzers ohne das er was mitbekommt.

mitbekommen würde er es schon, wenn das hintergrundbild verschwindet und die maus sich von allein bewegt .. es geht mir in erster linie um die technik, nicht um datenschutz - den kann ja jeder nach seinen eigenen richtlinien handhaben.. und ich habe ja auch ein beispiel genannt, wo man als remote-user die login-daten des lokalen users kennt, nämlich ein rechner, der von mehreren leuten unter demselben useraccount benutzt wird und normalerweise nicht für privates genutzt wird (z.b. ein steuer-PC für irgendwelche anlagen oder wissenschaftlichen geräte, wo es bei der komplexität der software und benutzerfluktuation keinen sinn macht, für jeden einen eigenen useraccount anzulegen und die software entsprechend einzurichten).. das ist vielleicht nicht der standard-anwendungsfall in irgendwelchen großbüros, aber es wäre technisch trivial, dem remote-user die option zu geben, den lokalen user nicht zu sperren, wenn er dessen logindaten hat - so wie jede andere remote-software das macht..

 

[PLanB]

Finde ich nicht. Wenn im Fernwartungsvertrag drin steht, dass die Fernwartung bei nicht angemeldeten Benutzern stattfinden darf und ansonsten nur bei Initiation durch den Nutzer, finde ich das unproblematisch.

Muss halt geloggt werden, wann wo zugegriffen wird…

Das ist natürlich unproblematisch, wird auch per default von tightvnc so gehandhabt. Werde mir tigervnc mal anschauen.

@Novgorod - du musst aber die maus nicht bewegen, einfach Zuschauen geht auch, und hier liegt der Hase begraben.
Den Anwendungsfall des Steuerpc sehe ich auch, ist aber auch anders zu werten da keine personenbezogenen Daten auszuwerten sind.
Technisch hast du schon recht, nur haben manche, einfach gestrickte, admins gerne einen kleinen gottkomplex und denken dass alles was möglich ist auch rechtens ist.
Somit finde ich diese Einschränkung per se nicht schlimm, wenn auch letztendlich unnötig.

Gruß,
PLanB

 

[Novgorod]

eben - völlig unnötig
ich sehe aber auch das problem nicht, wenn ein gemeinsamer rechner und useraccount benutzt wird und alle user sich darüber im klaren sind.. die meisten remote-programme (u.a. RDP und anydesk) haben auch einen ziemlich unübersehbaren indikator, dass gerade ein remote-zugriff erfolgt, aber auch das ist kein schutz vor missbrauch und paranoia.. wenn der admit mit dem gottkomplex wirklich admin ist, kann er rechner verwanzen und heimlich schnüffeln soviel er will, ohne dass der user eine chance hat, das mitzubekommen.. schutz der privatsphäre und befolgen von gesetzen wird nicht dadurch erzwungen, dass ein bestimmtes tool den funktionsumfang künstlich einschränkt, während es unzählige andere tools genau zu dem zweck gibt..