Monthly Archives: November 2020

Externer Displayport plötzlich kaputt? Teil 2!

Mittlerweile hat sich herausgestellt, daß das Problem des hin und wieder ausfallenden zweiten Monitors auf einer Linux-Mint-Maschine irgendwo im Session Management von xfcwm und xfce steckt. Es ist mir nämlich gelungen, mit dem Session-and-Startup-Tool eine Session zu sichern, die zuverlässig (!) beide Bildschirme aktiviert. Allerdings habe ich in diesem Tool die Option

Display chooser on login

aktiviert. Der Nachteil: Ich muß nach dem Login diese Session im Chooser aktivieren. Zur Zeit versuche ich zu klären, wie ich sie zur expliziten Default Session machen kann, sodaß ich den Chooser nicht mehr benötige.

Warum Sie nicht nur in Corona-Zeiten aufhören sollten, Windows zu benutzen, und sich stattdessen mit Linux anfreunden sollten!

Der erste Grund ist: Wenn nicht jetzt, wann dann? Viele Menschen sitzen (im November 2020) zu Hause herum und wissen nichts mit sich anzufangen, warum nicht die Zeit nutzen und etwas Neues lernen? Aber ernsthaft: Neue Wege zu erkunden, ist immer gut und hält jung. Aber es gibt auch sehr konkrete Gründe für die von mir gewählte Überschrift, und ich gebe ein Beispiel:

Ich gehe davon aus, daß Sie Windows verwenden. Lassen Sie mich raten, mit welchem Programm Sie Ihre E-Mails (ja, das war dieses Nachrichtenübermittlungssystem vor der großflächigen Einführung von WhatsApp und Telegram und anderen instant messenger services) bearbeiten. Grübel, grübel und studier’… Ich komm’ nicht drauf… Jetzt: 😱 Outlook, richtig?

Haben Sie’s bezahlt? Oder raubkopiert? Oder, naja, so halblegal mit irgendeinem Schlüssel aus dem Internet freigeschaltet?

Aber das nur am Rande: Die Tatsache, daß Sie für die meiste Software, die Sie unter Linux/FreeBSD* (Erklärung am Ende des Texts) verwenden können, keinen Penny bezahlen müssen, und zwar ganz legal, ist nur ein Aspekt. Ich will auf etwas anderes hinaus:

Bis Sie Ihre E-Mailaccounts in Ihrem Outlook-Profil eingerichtet hatten, haben Sie schon Zeit investiert, oder? Und dann hatten Sie erst einmal einen ersten Rechner, den Sie für Ihre Mailkommunikation nutzen konnten. Dann kam aber der Rechner im Büro dazu, dann der im Hobbyzimmer und immer so weiter…

Haben Sie dann jedesmal ein Outlook-Profil von Grund auf neu erstellt?

Ich habe das immer und immer wieder gemacht, denn die Methoden, mit denen man das angeblich vermeiden kann, haben sich über die Jahre immer wieder geändert, und bei mir haben Sie praktisch nie ohne unangenehme Nebenwirkungen funktioniert. Da war es dann ganz einfach sinnvoller, den ganzen Kladderadatsch wieder von vorne einzutippen: Accountdaten, Serverdaten, Portnummern, Paßwörter usw. usf.

Tja, und wenn eine dieser Methoden, das Outlook-Profil auf einen anderen Rechner zu übertragen, mit einem zerschossenen Outlook geendet hat, dann dürfen Sie gerade mal de- und anschließend reinstallieren.

Ich habe nachgeschaut: Man findet so grandiose Tips wie den Export der einzelnen Kontodaten in pst-Dateien. Na toll, da wäre ich ja nie drauf gekommen. Dann haben Sie zwar einen Abklatsch der Mails, aber kein funktionierendes Postfach. Was soll so ein Hinweis?

Falls wir uns hier mißverstehen: Ich habe nicht einen E-Mailaccount bei meinem Internet-Access-Provider, sondern eine ganze Reihe Konten bei unterschiedlichen Systemen und Anbietern. Wer nur einen Account hat, und den sinnvollerweise mit dem IMAP-Protokoll betreibt, der ist natürlich fein raus und hat beim Umzug von einem auf einen anderen Rechner keine nennenswerte Arbeit. Wenn Sie aber viele Konten haben, darunter dann noch ein paar mit Zweifaktorauthentifizierung, wird’s lustig.

Genug von Windows, gehen wir zu Linux:

Unter Linux können Sie einen Mailclient wie bspw. Thunderbird benutzen. Thunderbird hat ein Verzeichnis, in dem es seinen Maschinenraum hostet, soll heißen: Die ganzen Dateien, die es zum Betrieb braucht, zuallererst die Datei thunderbird.

Aber es gibt im Home-Directory des Anwenders ein Verzeichnis .thunderbird (solche Dateien mit einem Punkt vornedran sind auf Linux/FreeBSD-Systemen versteckte Dateien bzw. Verzeichnisse), in dem sozusagen die Verwaltungsetage zu Hause ist. In diesem Verzeichnis liegen alle Ihre persönlichen Daten, alles über Ihre Accounts, Ihre Einstellungen, Ihre Mails etc. pp.

Wenn Sie jetzt sagen, supi, das ist ja übersichtlich, dann lege ich mir doch gleich noch einen zweiten Linux-Rechner an, dann können Sie dieses Verzeichnis nehmen und einfach umkopieren! Fertig!

(Ich habe das gerade beim Redigieren des Textes getan! Und es funktioniert! Ich mußte lediglich einmal auf den Server kopieren, und dann vom Server korrekt auf den neuen Client kopieren, dann zeigte Thunderbird auf dem neuen Rechner meine ganzen Accounts genauso an wie auf der ersten Maschine. So einfach kann das Leben sein!)

Machen Sie das mal mit Windows!

Und damit sind wir beim entscheidenden Punkt: Ich will nicht sagen, der Maschinenraum von Linux/FreeBSD sei simpel und übersichtlich, nein, man muß eine Menge lernen und Erfahrung sammeln, bis man sich darin zurechtfindet. Aber auf Linux/FreeBSD-Systemen ist alles eine Datei, die ich ggf. kopieren, überschreiben oder einfach nur editieren kann. Gut, natürlich keine kompilierte Binärdatei, das ist ja klar. Wer aber mal vor einem Windows-Rechner gesessen hat, auf dem eine bösartige Adware die Browserkonfiguration gekapert hat, dann verzweifelt versucht hat, das zu reparieren und das nach stundenlangen Recherchen (und dabei womöglich mit Einfangen neuer Malware) gesteckt hat und begonnen hat, sich geistig-moralisch auf die Neuinstallation von Windows vorzubereiten, der weiß, wovon ich rede! Wer ist in der Lage, die Folgen eines solchen Angriffs z. B. mit ihren Auswirkungen auf die Registry zu beheben und das System so zu reparieren, daß es danach wieder läuft wie vorher? Ja, ich weiß: Ich habe das schon hinbekommen, indem ich mit Werkzeugen aus der SysInternals-Box einzelne Komponenten der Schadsoftware identifizieren und beseitigen konnte, Schwein gehabt! Aber ich hatte auch einen Fall, in dem ich das System in die Tonne treten mußte, sprich: Rechner plattgemacht, alles von vorne eingerichtet.

Womit wir beim nächsten Punkt wären: Man kann jedes System bösartig hacken (ich sage bösartig, weil hacken per se keine böse Tat ist, im Gegenteil), aber kein System ist so anfällig und so gefährdet wie Windows, und das gilt für die Desktop- genauso wie für die Serverversionen. Allein aus dem Grund sollte man sich überlegen, ob man nicht wenigstens einen Linux-Rechner haben sollte für die Shoppingtouren im Web.

Kurzum: Wer sich als normaler Anwender, und hier meine ich mit normal Menschen, die

  1. nicht programmieren,
  2. keine IT-Sicherheitsberater sind oder ähnliches,
  3. die den PC als Alltagswerkzeug benutzen, das einfach die paar Sachen machen soll, die man täglich so braucht (drucken, surfen, Bilder anschauen, Messenger-Dienste benutzen…),

einen Gefallen tun will, der sollte die gefährlichen Dinge auf einem Linux-Rechner machen, das ist nicht schwieriger als unter Windows, es sieht nur ein bißchen anders aus. Dann nimmt er sozusagen den Windows-Rechner aus der Gefahrenzone und lernt nebenher, ein wenig mit Linux zu spielen (hier lasse ich FreeBSD mal weg, denn in aller Regel werden moderne Linux-Distributionen wie z. B. Ubuntu vom Start weg auch mit etwas ungewöhnlicherer Hardware fertig und können die Installation praktisch ohne Zutun des Nutzers erfolgreich durchführen).

In diesem Sinne: Viel Spaß beim neuen Hobby 😜😜😜 ‼

___

*) Ich schreibe Linux/FreeBSD, weil es unfair wäre, im gegebenen Zusammenhang nur von Linux oder nur von FreeBSD zu reden, aber beide zusammen stellen die heutige Unix-Welt dar, was eigentlich auch schon wieder falsch ist, weil Unix ja ein Markenname von ATT ist (oder war, wie auch immer).

Externer DisplayPort plötzlich kaputt?

Es geht um ein Lenovo ThinkPad T420s, aber dieses Problem könnte auch andere Maschinen betreffen, nein, es betrifft mit Sicherheit auch andere Maschinen! (Warum? Die Lösung folgt am Ende!)

Auf dem o. g. Gerät läuft Linux Mint 20, auch Ulyana genannt (eigentlich also Ubuntu, noch eigentlicher Debian). Der von mir verwendete Desktop war (und ist jetzt wieder) XFCE4.

Vor einiger Zeit hatte ich das Gerät eingerichtet, heftigst benutzt, und ziemlich zu Beginn einen zweiten Monitor am DisplayPort-Ausgang betrieben. Völlig problemlos.

Dann kam es, wie es kommen mußte: Hier was rumgefummelt, dort mit den Treibern gespielt, und schließlich, eines morgens, starte ich den Rechner und denke: Häh? Was ist mit meinem Monitor los? Kein Bild? Warum?

Langes Gefummel, Kabelwechsel, Monitortausch, alles hardware-fokussiert, alles sinnlos. Am Ende die Notlösung schlechthin: VGA-Kabel, alles gut. Naja, bis auf die Bildqualität und die lustigen Artefakte bei schnellen Bewegungen auf dem Bildschirm.

Also, VGA ist halt, naja, eben eine Notlösung, aber ich hatte nach vielen Recherchen das Problem ad acta gelegt und mir gesagt: Ist ein Hardwaredefekt!

Aber irgendwie habe ich mir das nicht geglaubt, und siehe da: Heute stieß ich auf Berichte, die auf folgendes hinweisen:

https://askubuntu.com/questions/1230924/ubuntu-20-04-does-not-recognize-second-monitor

Konkret geht es mir um das hier:

In der Tat fand ich das File, die Zeile war nicht auskommentiert, ich habe das geändert, aber geholfen hat es nichts. Außer in einem Punkt: Ich war mir jetzt 100% sicher, daß es DOCH ein Software- bzw. Konfigurationsproblem sein wird.

Ich habe dann zunächst vom aktuellen NVidia-Treiber auf einen älteren umgeschaltet, ohne Erfolg, dann wieder zurück auf den empfohlenen aktuellen Treiber, aber dann habe ich beim Login nicht die XFCE-Session gewählt, sondern Gnome.

Und siehe da: Der externe Monitor wurde wieder wach!

Dann habe  ich mich ausgeloggt, an meiner alten XFCE-Session wieder angemeldet, und…

Yippieh, der Monitor funktionierte immer noch!

Sachen gibt’s… Da hat wohl die Gnome-Session etwas überschrieben, was der XFCE-Session wieder auf die Sprünge geholfen hat. Keine Ahnung, was, aber Hauptsache, daß! Uff.

PS: Zwischenzeitlich war der Port schon wieder tot, aber dann konnte ich ihn durch aktivieren der Zeile, also wegnehmen der Kommentarraute,

options nvidia-drm modeset=1

wieder einschalten. Ist das lustig 😉…

Fortsetzung hier: http://www.kolloquia.de/?p=827

GitAhead zickt herum beim Zugriff auf Remotes, die auf Synology-Diskstations liegen?

Sie bekommen merkwürdige Fehlermeldungen, wenn Sie mit GitAhead einen Push auf das Remote-Repository durchführen wollen? Z. B., daß Ihr Schlüsselpaar inkonsistent wäre?

Dann tun Sie folgendes:

  1. Loggen Sie sich per SSH auf der Diskstation ein, geben Sie den Befehl sudo su ein und öffnen Sie die /etc/passwd mit einem Editor. Suchen Sie den User, der hier mit Git arbeiten soll, kopieren Sie die Zeile, ersetzen Sie den Shell-Teil, der auf die Git-Shell zeigt, mit /bin/sh und kommentieren Sie die Originalzeile mit einer Raute aus.
  2. Lesen Sie den Artikel http://www.kolloquia.de/?p=802 und erzeugen Sie ein paßwortfreies SSH-Login für Ihr Git-Anwender-Konto!
  3. Wenn das geklappt hat, loggen Sie sich als Superuser wieder ein, löschen Sie die Zeile mit /bin/sh und nehmen Sie die Raute vor der Originalzeile wieder weg.

Wenn Sie jetzt mit GitAhead auf Ihr Remote zugreifen wollen, sollte es funktionieren!

SSH-Login auf Synology/DSM ohne Paßworteingabe (passwordless)

Zum Thema gibt es einiges zu finden, manches übersichtlich, manches weniger, es gibt vollständige Anleitungen und weniger vollständige, genauer, unvollständige, mit denen es nicht klappt, und um einfach die Wahrscheinlichkeit zu erhöhen, auf einen Artikel zu stoßen, der _ALLES_ wichtige erwähnt, habe ich diesen hier erstellt. Damit also einfach einer mehr im Netz steht, der die Sachlage vollständig dokumentiert.

Los geht’s:

Sie wären nicht hier, wenn Sie Telnet für Ihre Remote-Logins verwenden wollten, nehme ich mal an. Sie verwenden SSH, wollen sich aber ohne Paßwort anmelden.

Okay, dem hat Synology einen Riegel vorgeschoben! Um den zur Seite zu schieben, loggen wir uns auf der Webverwaltungsoberfläche der Synology-Station ein, öffnen das Control Panel und klicken auf Terminal & SNMP.

Im ersten Tab, Terminal, aktivieren wir den Telnet-Dienst, und SSH werden Sie schon aktiviert haben, oder? Wenn nicht, dann tun Sie es jetzt.

Es wird oft gesagt, man solle den Default-Port 22 nicht verwenden und stattdessen irgendeine andere, hohe (vierstellige) Portnummer wählen. Was, bitte schön, soll das denn bringen? Security by obfuscation? Sorry, aber das finde ich lächerlich. (Ich habe es gerade extra recherchiert: Es gibt Admins, die ihre Server mit direktem Zugang zum Internet auf einen anderen Port setzen, aber das tun sie, um z. B. ihre Logfiles etwas kürzer zu halten. An Sicherheit bringt das keinerlei Gewinn. Und wer liest Logfiles schon persönlich? Am besten als Ausdruck auf Endlospapier vom Nadeldrucker?) Wer an Ihre Station so nahe herangekommen ist, der wird auch den Port ausfindig machen, auf dem der sshd antwortet. Aber es schadet nichts, wenn Sie einen anderen Port benutzen, nur sollten Sie das dokumentieren. Und Sie müssen dann bei jedem Login den Port mit angeben, sonst klappt’s nicht.

Warum jetzt die Telnet-Aktivierung? Ganz einfach: Weil Dinge, die schiefgehen können, schiefgehen. Und wenn wir uns jetzt aussperren, gucken wir unter Umständen dumm aus der Wäsche. Wenn Sie z. B. beim nächsten Schritt die SSH-Konfiguration zerschießen, werden Sie Schwierigkeiten haben, das zu reparieren. Also, lieber Telnet aktivieren, und später nicht vergessen, es wieder zu deaktivieren.

Wie schon angedeutet, jetzt müssen wir die SSH-Konfiguration ändern. Dazu loggen Sie sich auf der Station ein, egal wie, aber Sie benötigen ein Kommandozeilen-Prompt.

Geben Sie ein

sudo su

Jetzt sind Sie Bruce Allmächtig!

Machen Sie eine Sicherheitskopie der Datei /etc/ssh/sshd_config, denn die wollen wir nun bearbeiten.

Geben Sie ein:

vi /etc/ssh/sshd_config

Entfernen Sie die Raute vor diesen beiden Befehlen:

#RSAAuthentication yes
#PubkeyAuthentication yes

(Nachtrag: Ich habe gerade Tests auf einer zweiten Station gemacht. Auf dieser hat die Option PubkeyAuthentication yes ausgereicht! Testen Sie das ruhig, wenn Sie Zeit und Lust haben. Man lernt nie aus… )

Speichern Sie und starten Sie den sshd neu:

synoservicectl --reload sshd

Jetzt stimmt die SSH-Konfiguration auf der Serverseite. Aber jetzt müssen Sie für Ordnung in Ihrer Verzeichnisstruktur sorgen: Für einen Account, in den man sich per SSH ohne Paßwort einloggen kann, fordert die SSH, daß:

  1. Das  Home-Directory mit chmod 700 auf die richtige Berechtigungsstufe gesetzt wurde.
  2. Das .ssh-Verzeichnis eine Stufe tiefer ebenso.
  3. Die Schlüsselfiles, zumindest das des privaten Schlüssels, sollten ebenfalls mit chmod 700 entsprechend geschützt sein.

Wenn z. B. das Home-Dir auf den Vorsteinstellungen von Synology bleibt, haben Sie keine Chance!

Jetzt können Sie sich ausloggen und sich dem Client widmen. Wenn Sie bereits ein Schlüsselpaar haben, prima, wenn nicht, legen Sie eines an, am besten mit

ssh-keygen -t rsa Hotzenplotz@10.10.10.13

Jetzt können Sie den öffentlichen Schlüssel mit folgendem Befehl mit einem Rutsch übertragen, ohne sich auf der Kommandozeile weiter abzuplagen:

ssh-copy-id -i ihreprivateschlüsseldatei Hotzenplotz@10.10.10.13

Sie werden noch einmal um das Paßwort des Allmächtigen gebeten, und wenn Sie alles richtig gemacht haben, dann war’s das. Wenn Sie jetzt versuchen, sich mit

ssh Hotzenplotz@10.10.10.13

anzumelden, sollte das klappen. Wenn nicht, können Sie per Telnet wieder rein und reparieren, was zu reparieren ist.

Wenn alles klappt, Telnet deaktivieren!

Viel Erfolg!

PS:

Es ist klar, daß Sie die Passphrase für Ihren Schlüssel eingeben müssen, wenn dieser mit einer solchen geschützt ist. Wenn Sie auch das nicht haben wollen, müssen Sie keinen neuen Schlüssel ohne Passphrase erzeugen, sondern können die Passphrase vom vorhandenen Schlüssel entfernen:

ssh-keygen -p -f ~/.ssh/privatekey -P "Alte Passphrase" -N "neue oder leere Passphrase"