Hi,
ihr könnt mich unter umst. weiterhelfen.
hab mir gentoo in ne vm-ware maschine installt. soweit läuft alles gut.
-vmware 4.0
-linux gentoo mit vmwaretreibern
-xp host
Ich arbeite viel von unterwegs auf meinem rechner per terminalsession und habe das problem das im linuxguest der vmware die maus nicht zu benutzen ist. sie bleibt hängen, geht nur ansatzweise in die richtung die ich mag, ich kann so nicht arbeiten.
hatte das selbe problem unter einem fedora guest auch schon.
wenn ich lokal am rechner bin besteht das mausproblem nicht.
weiss einer von euch was das ist oder wie ich das hinkriege?
mfg
klon
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Mausproblem wenn Terminal-Session auf Linuxguest unter XP Ho
hoi folks, :wink:
hab mir das jetzt mal angesehn, aber in kde finde ich nur nen remote desktop client. nen server oder ähnliches finde ich nicht.
X-
^^ was isn das
- man verzeihe mir aber jeder hat ma irgendwo klein angefangen.
habe bei der wahl des bestimmten remote-servers noch fragen:
- gibt es soetwas wie remotedesktop für kde? terminalserver?
- was ist besser zum arbeiten, remotedesktop oder vnc server?
vnc suckt im vergleich mit terminaldiensten von m$ total ... o_O,
- gibt es ausser den beiden genannten noch bessere alternativen?
ich muss dazusagen das ich absoluter linux noob bin und auf teufel komm raus mit gentoo anfangen musste. hat ja alles geklappt an sich,
nur
jetzt sitz ich hier und mir fehlt ein bisschen der ansatz die äquivalenten programme an den start zu kriegen welche ich zum arbeiten mit der maschine benötige.
wäre lieb wenn ihr mir etwas helfen könntet.
mfg
klon
hab mir das jetzt mal angesehn, aber in kde finde ich nur nen remote desktop client. nen server oder ähnliches finde ich nicht.
X-
^^ was isn das
- man verzeihe mir aber jeder hat ma irgendwo klein angefangen.
habe bei der wahl des bestimmten remote-servers noch fragen:
- gibt es soetwas wie remotedesktop für kde? terminalserver?
- was ist besser zum arbeiten, remotedesktop oder vnc server?
vnc suckt im vergleich mit terminaldiensten von m$ total ... o_O,
- gibt es ausser den beiden genannten noch bessere alternativen?
ich muss dazusagen das ich absoluter linux noob bin und auf teufel komm raus mit gentoo anfangen musste.
hat ja alles geklappt an sich,
nur
jetzt sitz ich hier und mir fehlt ein bisschen der ansatz die äquivalenten programme an den start zu kriegen welche ich zum arbeiten mit der maschine benötige.
wäre lieb wenn ihr mir etwas helfen könntet.
mfg
klon
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Hi
Rdesktop von XP zu XP oder 2k3 ist schon was feines - der Linuxport von Rdesktop hinkt aber etwas hinterher und ist etwa auf dem Niveau von Rdesktop 2k zu 2k.
VNC koennen alle - das ist der groesste Vorteil von VNC. - Und man kann bei VNC Lehrer - Schueler Sachen machen - einer bewegt die Maus und der ander schaut zu. Auch zur Ueberwachung - Spionage denkbar.
Von Windows zu *nix gibt es auch noch die Variante Xserver fuer Windows.
Ein Xserver ist derjenige, der von den Programmen den Befehl erhaelt, irgendein bestimmtes Objekt bunt auf den Bildschirm zu bringen.
Grob koennte man sagen - wenn du Rdesktop von XP zu XP machst, laeuft auf deinem entfernten XP das Programm und bei dir der Xserver.
Wie gesagt - ganz grob gesagt.
Ein Xserver fuer Windows gibt es fuer lau bei cygwin oder fuer Geld mit Xwin32 oder Hummingbird Exceed. Von der Performance sind diese Loesungen klar besser als VNC und spielen etwa in der Liga von Rdesktop XP zu XP.
Grundsaetzlich sollte man meinen, dass es mehr Sinn macht direkt mit dem Gast zu verbinden, als erst den Host einzuschalten.
Von daher ist die Ueberlegung von unterwegs seinen Linuxgast per X von einer Knoppix-CD zu warten ziemlich interessant. Vorrausgesetzt mann hat keinen echten *nix Rechner zur Hand.
Starte bei deinem Gentoo Gast einen SSH-server - boote unterwegs Knoppix und oeffne ein xterm.
ssh demklon@demklons-rechner -X
oder eine Variante dieses Befehls und du bist drin. In Bunt und mit Maus -Firewallangelegenheiten mal ganz ausser Acht gelassen.
Wie der Befehl fuer Gentoo aussaehe und was man an den Profilen einstellen muss, kann dir vielleicht Looping sagen.
Continuum
Rdesktop von XP zu XP oder 2k3 ist schon was feines - der Linuxport von Rdesktop hinkt aber etwas hinterher und ist etwa auf dem Niveau von Rdesktop 2k zu 2k.
VNC koennen alle - das ist der groesste Vorteil von VNC. - Und man kann bei VNC Lehrer - Schueler Sachen machen - einer bewegt die Maus und der ander schaut zu. Auch zur Ueberwachung - Spionage denkbar.
Von Windows zu *nix gibt es auch noch die Variante Xserver fuer Windows.
Ein Xserver ist derjenige, der von den Programmen den Befehl erhaelt, irgendein bestimmtes Objekt bunt auf den Bildschirm zu bringen.
Grob koennte man sagen - wenn du Rdesktop von XP zu XP machst, laeuft auf deinem entfernten XP das Programm und bei dir der Xserver.
Wie gesagt - ganz grob gesagt.
Ein Xserver fuer Windows gibt es fuer lau bei cygwin oder fuer Geld mit Xwin32 oder Hummingbird Exceed. Von der Performance sind diese Loesungen klar besser als VNC und spielen etwa in der Liga von Rdesktop XP zu XP.
Grundsaetzlich sollte man meinen, dass es mehr Sinn macht direkt mit dem Gast zu verbinden, als erst den Host einzuschalten.
Von daher ist die Ueberlegung von unterwegs seinen Linuxgast per X von einer Knoppix-CD zu warten ziemlich interessant. Vorrausgesetzt mann hat keinen echten *nix Rechner zur Hand.
Starte bei deinem Gentoo Gast einen SSH-server - boote unterwegs Knoppix und oeffne ein xterm.
ssh demklon@demklons-rechner -X
oder eine Variante dieses Befehls und du bist drin. In Bunt und mit Maus -Firewallangelegenheiten mal ganz ausser Acht gelassen.
Wie der Befehl fuer Gentoo aussaehe und was man an den Profilen einstellen muss, kann dir vielleicht Looping sagen.
Continuum
super antwort!
dank dir, das mit dem ssh server und der knoppix cd hört sich verlockend an, werd ich hier mal testen. muss nur mal schauen ob knoppix hier in der firma den dhcp server blickt und ob ich netz habe. wenn das geht wärs schon ne geile möglichkeit! dangöö :wink:
@looping, wär fein wenn du kurz anreissen könntest was ich im gentoo für einstellungen brauche.
dank dir, das mit dem ssh server und der knoppix cd hört sich verlockend an, werd ich hier mal testen. muss nur mal schauen ob knoppix hier in der firma den dhcp server blickt und ob ich netz habe. wenn das geht wärs schon ne geile möglichkeit! dangöö :wink:
@looping, wär fein wenn du kurz anreissen könntest was ich im gentoo für einstellungen brauche.
Starte bei deinem Gentoo Gast einen SSH-server - boote unterwegs Knoppix und oeffne ein xterm.
ssh demklon@demklons-rechner -X
oder eine Variante dieses Befehls und du bist drin. In Bunt und mit Maus -Firewallangelegenheiten mal ganz ausser Acht gelassen.
Wie der Befehl fuer Gentoo aussaehe und was man an den Profilen einstellen muss, kann dir vielleicht Looping sagen.
jo, was muss ich beim errichten des ssh servers beachten?
is der schon bei kde an board?
und wie lautet der connection befehl?
danke für eure hilfe
der bei linux gebräuchliche ssh-server ist ein produkt der open-group (das sind die jungs, die openbsd bauen) - deswegen heißt er openssh. der eigentliche deamon ist der sshd. der sshd sollte unabhängig von deinem windowmanager oder sonst irgendeiner X-variante auf deinem system sein, es ist nämlich ein konsolenwerkzeug. der sshd bietet dir eine konsole deines lokalen systems auf einem entfernten system über eine starke kryptographische verschlüssulung an. niemand, der nicht das entsprechende mantra kennt, bzw. den entsprechenden key-file hat, kann die konsole öffnen und nutzen, kannst du dich dem systm gegenüber aber authentifizieren, hast du von überall auf der welt zugriff auf eine konsole, als säßest du direkt am entfernten rechner. es gibt dann noch einen schalter X-forewarding, der die grafische ausgabe von programmen an einen entfernt laufenden x-server übergibt - das ist das was du suchst.
der sshd ist mit größter wahrscheinlichkeit schon auf deinem system installiert. abfragen kannst du das auf der konsole einfach mit
#ps -ax|grep sshd
(das gibt dir alle laufenden prozesse aus, in denen die buchstabenkombination sshd vorkommt - dort sollte also zumindest eine auskabe erscheinen) oder mit
#ssh -V
, dass gibt dir die aktuelle versionsnummer deines installierten sshd, die verwendeten protokolle und (soweit installiert) die versionsnummer des openssl-moduls aus.
die konfiguration findest du in /etc/ssh - hier sollten sich 6 schlüsseldateien, die ssh_config, die sshd_config und eine moduli-datei befinden. mit den schlüsseldateien authentifiziert sich dein rechner gegenüber anderen rechnern, die ssh_config ist eine grundeinstellungsdatei für lokale ssh-clients, in der sshd_config ist die konfiguration des sshd festgelegt und die moduli-datei wird zum erstellen von zufallszahlen benötigt.
es gibt 2 möglichkeiten sich einem laufenden sshd gegenüber zu authentifizieren: einmal über ein mantra (passwort) oder über einen schlüsselring (keyring, keypair). quick and dirty gehts über die passwortauthentifizierung - die ist jedoch so trivial, dass du sie in den man-pages oder auf der openssh-site selbst einfach nachlesen kannst. ich versuche dir die etwas kompliziertere aber sicherere und komfortablere keypair-variante zu erklären.
erstmal benötigst du zwei linuxkisten mit ssh oder alternativ eine linuxkiste und eine windowsbüchse mit dem programm putty. auf der linuxkonsole des einen lokalen rechners (der dann zukünftig als ssh-server dienen wird) legst du dir einen user an (oder benutzt einen bereits vorhandenen), und erstellst diesem user ein schlüsselpaar
~$ssh-keygen -b 2048 -t rsa
beachte: dies ist ein userkommando das im /home-directory des users ausgeführt wird. dieser aufruf erzeugt dir einen 2048bit großen rsa keyring, und legt in deinem /home-verzeichniss das versteckte directory ~/.ssh an. in diesem verzeichnis werden die schlüssel rsa_id und rsa_id.pub gespeichert. hast du deinem schlüssel auch eine passphrase gegeben? wenn nicht, solltest du das unbedingt nachholen:
$ssh-keygen -p -f ~/.ssh/id_rsa
als nächstes setzt du deinen privaten userkey auf nur für den besitzer les- und schreibbar
$chmod 600 ~/.ssh/id_rsa
jetzt musst du diese schlüssel irgendwie auf den zukünftigen client bekommen - dafür gibt es ein tool:
$ssh-copy-id -i ~/.ssh/id_rsa demklon@demklonspc.
wenn das geklappt hat, gibt es im userverzeichnis demklon auf dem rechner demklonspc nun ebenfalls einen order ~/.ssh und du kannst dich mit dem aufruf
$ssh demklon@server
nach abfrage der passphrase für den key auf dem server einloggen. ist der user in der gruppe wheel, kannst du auf dem entfernten system sogar root werden (mit su).
falls du mit putty von einer windowskiste auf deinen ssh-server zugreifen willst, kannst du das auch entweder quick and dirty über passwordauthentification oder (so wie es im echten leben richtig gehen sollte) über das keypair.
bei einer putty verbindung ist das alles ein bisschen anders. putty bietet dir ausschließlich die konsole (kann also kein X-forewarding), da auf deinem windows-client ja kein x-server läuft. dazu bräuchtest du entweder cygwin oder hummingbird exceed (beides sind x-server für windowsrechner, cygwin ist kostenlos, hummingbird exceed kostet richtig geld). beachte das du die putty-version 0.54 benötigst, um mit dem programm puttygen einen openssh-key zu importieren. dazu klickst du unter [conversions] auf [import key] und gibst den pfad zum keyfile an (die key's solltest du vorher sinnigerweise auf diskette kopieren - schick deinen privat-key niemals ungesichert über das netz. puttygen importiert die keys, die du dann unter beliebigen namen abspeichern kannst (natürlich nicht irgendwo, sondern in einem gesicherten bereich, oder so wie man das eigendlich macht: auf einem usb-token/usb-stick, der niemals an zweite weitergegeben wird). vor der verbindungserstellung mit putty gibst du noch im unterpunkt [SSH][AUTH] den pfad zu deinem key-file an, fertig.
probier das erstmal - wenn die verbindung läuft, kümmern wir uns um die config-files.
mfg
looping
der sshd ist mit größter wahrscheinlichkeit schon auf deinem system installiert. abfragen kannst du das auf der konsole einfach mit
#ps -ax|grep sshd
(das gibt dir alle laufenden prozesse aus, in denen die buchstabenkombination sshd vorkommt - dort sollte also zumindest eine auskabe erscheinen) oder mit
#ssh -V
, dass gibt dir die aktuelle versionsnummer deines installierten sshd, die verwendeten protokolle und (soweit installiert) die versionsnummer des openssl-moduls aus.
die konfiguration findest du in /etc/ssh - hier sollten sich 6 schlüsseldateien, die ssh_config, die sshd_config und eine moduli-datei befinden. mit den schlüsseldateien authentifiziert sich dein rechner gegenüber anderen rechnern, die ssh_config ist eine grundeinstellungsdatei für lokale ssh-clients, in der sshd_config ist die konfiguration des sshd festgelegt und die moduli-datei wird zum erstellen von zufallszahlen benötigt.
es gibt 2 möglichkeiten sich einem laufenden sshd gegenüber zu authentifizieren: einmal über ein mantra (passwort) oder über einen schlüsselring (keyring, keypair). quick and dirty gehts über die passwortauthentifizierung - die ist jedoch so trivial, dass du sie in den man-pages oder auf der openssh-site selbst einfach nachlesen kannst. ich versuche dir die etwas kompliziertere aber sicherere und komfortablere keypair-variante zu erklären.
erstmal benötigst du zwei linuxkisten mit ssh oder alternativ eine linuxkiste und eine windowsbüchse mit dem programm putty. auf der linuxkonsole des einen lokalen rechners (der dann zukünftig als ssh-server dienen wird) legst du dir einen user an (oder benutzt einen bereits vorhandenen), und erstellst diesem user ein schlüsselpaar
~$ssh-keygen -b 2048 -t rsa
beachte: dies ist ein userkommando das im /home-directory des users ausgeführt wird. dieser aufruf erzeugt dir einen 2048bit großen rsa keyring, und legt in deinem /home-verzeichniss das versteckte directory ~/.ssh an. in diesem verzeichnis werden die schlüssel rsa_id und rsa_id.pub gespeichert. hast du deinem schlüssel auch eine passphrase gegeben? wenn nicht, solltest du das unbedingt nachholen:
$ssh-keygen -p -f ~/.ssh/id_rsa
als nächstes setzt du deinen privaten userkey auf nur für den besitzer les- und schreibbar
$chmod 600 ~/.ssh/id_rsa
jetzt musst du diese schlüssel irgendwie auf den zukünftigen client bekommen - dafür gibt es ein tool:
$ssh-copy-id -i ~/.ssh/id_rsa demklon@demklonspc.
wenn das geklappt hat, gibt es im userverzeichnis demklon auf dem rechner demklonspc nun ebenfalls einen order ~/.ssh und du kannst dich mit dem aufruf
$ssh demklon@server
nach abfrage der passphrase für den key auf dem server einloggen. ist der user in der gruppe wheel, kannst du auf dem entfernten system sogar root werden (mit su).
falls du mit putty von einer windowskiste auf deinen ssh-server zugreifen willst, kannst du das auch entweder quick and dirty über passwordauthentification oder (so wie es im echten leben richtig gehen sollte) über das keypair.
bei einer putty verbindung ist das alles ein bisschen anders. putty bietet dir ausschließlich die konsole (kann also kein X-forewarding), da auf deinem windows-client ja kein x-server läuft. dazu bräuchtest du entweder cygwin oder hummingbird exceed (beides sind x-server für windowsrechner, cygwin ist kostenlos, hummingbird exceed kostet richtig geld). beachte das du die putty-version 0.54 benötigst, um mit dem programm puttygen einen openssh-key zu importieren. dazu klickst du unter [conversions] auf [import key] und gibst den pfad zum keyfile an (die key's solltest du vorher sinnigerweise auf diskette kopieren - schick deinen privat-key niemals ungesichert über das netz. puttygen importiert die keys, die du dann unter beliebigen namen abspeichern kannst (natürlich nicht irgendwo, sondern in einem gesicherten bereich, oder so wie man das eigendlich macht: auf einem usb-token/usb-stick, der niemals an zweite weitergegeben wird). vor der verbindungserstellung mit putty gibst du noch im unterpunkt [SSH][AUTH] den pfad zu deinem key-file an, fertig.
probier das erstmal - wenn die verbindung läuft, kümmern wir uns um die config-files.
mfg
looping
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste