PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : VNC-Session lässt sich nicht öffnen



BoOnOdY
19.06.09, 14:24
Hi,

ich bin gerade am Verzweifeln, ich habe einen openSUSE 11.1 server den ich per VNC administriere.

Seit gestern habe ich nur noch ein graues Fenster mit einer KDE warteuhr...

per putty komm ich auf den server drauf.

Woran kann das liegen?

Gruß BoOnOdY

oziris
19.06.09, 19:51
Der Server ist definitiv kaputt, was man daran erkennen kann, dass er ein GUI hat und per VNC administriert wird.
Um ihn zu reparieren solltest Du das GUI und VNC deinstallieren.

stefan.becker
19.06.09, 20:13
Hi,

ich bin gerade am Verzweifeln, ich habe einen openSUSE 11.1 server den ich per VNC administriere.

Seit gestern habe ich nur noch ein graues Fenster mit einer KDE warteuhr...

per putty komm ich auf den server drauf.

Woran kann das liegen?

Gruß BoOnOdY

Und du glaubst jetzt ernsthaft, dass jemand dazu was sagen könnte?

The Crystal Bowl you are calling is not available.

Aqualung
20.06.09, 12:51
So kannst Du von der Konsole aus den X-Server neu starten:


sudo pkill -9 Xorg

Benutzung auf eigene Gefahr. Zu Risiken und Nebenwirkungen fragen Sie Ihren Admin ...

Ansonsten schließe ich mich den anderen Postern an: Ein X-Server hat auf einem Server NICHTS zu suchen !!!

Dodobo
20.06.09, 12:55
Ich find es nicht gut, dass man hier vorsätzlich "gefährliche" (Prozess kicken) oder unerwünschte Befehle postet. Und mit der Gefährlichkeit einer GUI übertreibt. Ist nicht außerdem die Absicherung viel wichtiger? Warum soll eigentlich Passwort unsicher sein - Alternative war Key auf Stick, oder? Ist aber dann auch nur ein verschlüsseltes bzw. private key, oder? Ich hab mir das nämlich jetzt bei einem PC auch mal etwas einfacher gemacht......

Der ist aber fast nie online. Und nur minutenweise. Und da brauche ich eine GUI (is ja kein Server), da mir niemand erzählen will, dass man ein kaputtes GUI-Programm dann auf der Konsole neu hinbekommen will oder kann - ohne die Symptome per GUI zu sehen und möglichst auch da zu beheben. Etwa muckende Mailprogramme...oder fehlkonfigurierte, die man nachstellen muß...

Aqualung
20.06.09, 13:11
Ich find es nicht gut, dass man hier vorsätzlich "gefährliche" (Prozess kicken) oder unerwünschte Befehle postet.

Ich halte in diesem Fall die Gefahr für verantwortbar.

Ob das (gewaltsame) Neustarten des KDE für den OP erwünscht ist, mag er selbst beurteilen ...

Dodobo
20.06.09, 14:13
Und zu meinen anderen Fragen, gibt es da wenigstens eine Randbemerkung, falls es zu offtopic werden sollte? :)

oziris
20.06.09, 21:07
Und zu meinen anderen Fragen, gibt es da wenigstens eine Randbemerkung, falls es zu offtopic werden sollte? :)Also ich wollte Dir erst nicht antworten und hab' Dich lieber auf die Ignorier-Liste getan, weil mir das zu reißerisch war. Jetzt hab ich aber doch auf "Beitrag anzeigen" geklickt und gesehen, dass Du anscheinend tatsächlich eine Antwort wünschst... Ich unignoriere Dich gleich mal...

Ich find es nicht gut, dass man hier vorsätzlich "gefährliche" (Prozess kicken)Der entsprechende Befehl ist nicht gefährlich, wenn er sowieso nur einen grauen Bildschirm sieht ... und auch sonst ist killen eine gängige Methode, um eine verkorkstes GUI zu beenden. Danach muss man es aber vielleicht manuell neu starten und natürlich gehen nicht gespeicherte Daten verloren, aber im Prinzip sind diese Daten sowieso in diesem Moment nicht greifbar, also quasi schon verloren. Man könnte höchsten, statt Xorg ggf. den entsprechenden Xserver des VNC killen und evtl. stattdessen sogar nur ein bestimmtes problematisches Unterprogramm oder KDE ganz oder teilweise.


[...] oder unerwünschte Befehle postet.Von wem unerwünscht? Hier hat doch niemand Wünsche diesbezüglich geäußert.
Natürlich konnte niemand direkt auf die Frage, nach dem Warum, von BoOnOdY antworten, weil es auf einem grauen Bildschirm nix zu diagnostizieren gibt. Man könnte nur vermuten, dass KDE etwas auf dem Xserver des VNC vermisst, falls überhaupt ein spezieller dafür verwendet wurde. ... aber eigentlich kann man das nicht beantworten.


Und mit der Gefährlichkeit einer GUI übertreibt.Übertreiben ist ja wohl Ansichtssache. Mal davon abgesehen siehst Du ja schon an diesem Thread, dass das GUI instabil ist und BoOnOdY noch Glück hatte, dass er wenigstens noch per PuTTY (hoffentlich SSH) drauf kommt. Es wäre nicht das erste Mal, dass ein GUI einen kompletten Server lahmlegt. Bei VNC ist das zwar nicht sehr häufig, aber es kommt gelegentlich vor und daher ist ein Server mit GUI drauf (besonders mit KDE oder Gnome) als baufällig einzustufen.


Ist nicht außerdem die Absicherung viel wichtiger?Da hast Du schon Recht, doch das entfernen eines VNC-Server, der vermutlich unverschlüsselt im Netz lauscht und höchstens nach einem Passwort fragt, das am Ende noch unverschlüsselt oder entschlüsselbar übertragen wird, zählt für mich zur Kategorie "Absichern".


Warum soll eigentlich Passwort unsicher seinWeil es oft zu kurz ist und durch Brute-Force-Angriffe & Co. automatisch erraten werden kann (auch weil es meist nicht oft genug geändert wird) weil es leicht abgeguckt oder aufgezeichnet werden kann.


- Alternative war Key auf Stick, oder?Für Unterwegs ja, besonders weil man den Key leicht und schnell, nach der Rückkehr in eine gesicherte Umgebung (oder bei Verlust), ändern kann. In einer abgesicherten Umgebung kann man den Key dann auch auf der Festplatte lassen, besonders wenn er zusätzlich noch eine Passphrase benötigt.
Ist aber dann auch nur ein verschlüsseltes bzw. private key, oder?Warum "nur"? Die Frage ergibt für mich keine Sinn.

[...] da mir niemand erzählen will, dass man ein kaputtes GUI-Programm dann auf der Konsole neu hinbekommen will oder kann - ohne die Symptome per GUI zu sehen und möglichst auch da zu beheben. Etwa muckende Mailprogramme...oder fehlkonfigurierte, die man nachstellen muß...Das ist ja keine Frage ... eher ein Haufen seltsamer Annahmen ...
Tatsächlich wäre es schöner, wenn man einen Fehler im GUI-Programm auch im GUI diagnostizieren kann. Das ist aber bei einem vollkommen grauen Bild nicht machbar, daher geht es sowieso nur auf der Shell.
Das ist hier aber auch eigentlich nicht von Belang, da es sich um einen Server handelt und man Server sowieso viel effizienter über die Shell fernwarten kann.
Es würde also genügen das GUI zu deaktivieren, damit es nicht noch den Rest des Servers blockiert bzw. blockierte Ressourcen freigibt und sich in die Wartung eines Servers per Shell einzuarbeiten, worüber es auch genügend Lektüre zu finden geben sollte.

Dodobo
20.06.09, 21:30
Ich wollte den Thread nicht fremdentführen und habe gedacht, dass es vielleicht eine Kurzantwort ergibt - aber so hast du dir mal Zeit genommen und es ist auch für andere Leute wie mich, die hier reinklicken, gut zu wissen.

Ich will da jetzt auch gar nicht weiter den Thread zerstören oder den Anschein erwecken, dass ich kein Wissen annehme oder einen Haufen berechtigter oder unberechtigter kritischer Fragen stelle. Ich habe eigentlich auch nur noch 1-2 Fragen und 1-2 Anmerkungen:

Ein Key ist nichts anderes als ein "langes, verschlüsselt abgelegtes Passwort" auf Stick? Wie lang sollte er sein? Wird das immer mit Passwort nochmal abgesichert oder immer verschlüsselt abgelegt? (RTFM zeigt mir nicht, wie "ihr" oder "man" das "wirklich" handhaben sollte - und nun sind wir mal kurz hier...wäre schön, was dazuzulernen, ohne gleich ein neues Faß aufzureißen.)

Und wegen den Problemen mit einem Mailprogramm habe ich extra die GUI-Fernwartung eingerichtet, damit ich das checken und unter Beobachtung halten kann - ist wie gesagt kein Server.
Meine Verbindung ist natürlich vollverschlüsselt. Was die GUI angeht: Auch Shellprobleme liest man genug - und komischweise kam ich so rein, per Shell nicht. Klar, Anwenderfehler und nicht hartnäckig genug. Aber das führt hier zu weit. NX gibt es eh nur als GUI, jedenfalls was ich so sah. Das braucht man, um Rechner am lahmen Modem grafisch fernwarten zu können. Beste Kompressionen und Caches...werde aber entsprechende VNC-Sachen auch nochmal testen irgendwann.

oziris
20.06.09, 23:51
Schon allein, weil in den Keyfiles mehr als die ca. 100 Zeichen pro Byte verwendet werden, die man als Benutzer so tippen kann, sind die Keyfiles sicherer.

Also ich benutze (beruflich und privat) RSA-Keys für SSH und ohne Passwort; privat mit 2048 bits und beruflich weiß ich's nicht, weil nicht ich die vergebe. Die werden eigentlich nur in LANs und immer von den selben paar Rechnern aus benutzt.

Für das lokale Login benutze ich zuhause pam_usb mit 1024 bits und ohne Passwort und auf der Arbeit nur recht lange Passwörter. Das ist nicht wirklich viel, aber es sollte genügen, um Unholde von der Benutzung abzuhalten, bis sie bemerkt werden.

Wenn ich meine SSH-Keys mit mir rumschleppen würde, würde ich aber auf jeden Fall noch Passwörter mit dazu nehmen, damit ich einen gewissen Vorsprung habe, den Key zu ändern, wenn man sie mir klaut.

Ich denke das ist recht sicher. Es geht zwar noch sicherer, aber das wäre vermutlich ungemütlich und übertreiben.

Ansonsten benutze ich noch LUKS verschlüsselte Loop-Devices, DVD-RAM und Festplatten-Partitionen, um meine persönlichen Daten (Fotos, Bewerbungsunterlagen, Rechnungen, usw.) vor unbefugten zu schützen. Dabei benutze ich unterschiedliche Ciphers und Passwörter. Das ist aber im Prinzip nur für den Fall, dass irgendwer den Datenträger klaut. Ich denke nicht, dass ein Dieb wirklich an den Daten darauf interessiert wäre, aber ich will den Kram wenigstens nicht offensichtlich rumliegen haben.
Ach ja, und den Swap meiner Workstation zuhause verschlüssle ich beim Booten auch gleich mit einem zufälligen Key. Wenn ich den Rechner ausmache, dann sollte nach einer Weile der Swap unbrauchbar werden. Ich weiß aber nicht genau wie lange es dauert, bis man nach dem Ausschalten den Key nicht mehr aus dem DDR-SDRAM lesen kann...