Kurztipp: no matching key exchange method found

Noch eine kleine Begleiterscheinung die nach dem Upgrade auf Ubuntu 20.04 aufgetreten ist: Ein SSH zu einer VM mit einem Uralt-SCO-Unix scheitert mit folgender Fehlermeldung:

$ ssh vmsco
Unable to negotiate with 192.168.47.11 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Abhilfe: Für den Host und seine IP-Adresse die alten, mittlerweile als unsicher erachteten Verbindungsparameter aktivieren, die Ubuntu per Default nicht mehr verwendet:

$ sudo vi /etc/ssh/ssh_config.d/vmsco.conf

Host vmsco
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc

Host 192.168.47.11
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc

Links:

Kurztipp: Legitimierung Farbprofil / farbverwaltendes Gerät

Nach den beiden Kurztipps zum NetworkManager (hier und hier) hier nun noch ein Tipp der Sorte, wie man nervende PolicyKit-Warnungen weg bekommt.

Nach dem Upgrade auf Ubuntu 20.04. und dem Login innerhalb einer Remote-Session über XDMCP poppten nacheinander folgende Warnmeldungen auf und verlangen die Kennworteingabe:

Nach den Erfahrungen der älteren Tipps habe ich einfach geraten und folgende Dateien mit entsprechenden Inhalten angelegt. Und was soll ich sagen, es hat funktioniert, yipeeh!

Legitimierung ist zur Erstellung eines farbverwaltendes Geräts notwendig

$ sudo vi /etc/polkit-1/localauthority/50-local.d/52-allow-color-manager-create-device.pkla

[Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.settings.modify.system;org.freedesktop.color-manager.create-device
ResultAny=no
ResultInactive=no
ResultActive=yes

Legitimierung ist zum Erstellen eines Farbprofils erforderlich

$ sudo vi /etc/polkit-1/localauthority/50-local.d/52-allow-color-manager-create-device.pkla

[Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.settings.modify.system;org.freedesktop.color-manager.create-profile
ResultAny=no
ResultInactive=no
ResultActive=yes

Kurztipp: System policy prevents Wi-Fi scans

Nach dem Upgrade auf Ubuntu 20.04 nervt ein weiteres kleines Problem, sobald ich eine neue Remote-Session per XDMCP starte. Kurze Zeit nach dem Login taucht diese Meldung auf:

Wie gut, dass ich vor geraumer Zeit ein ähnliches Problem (Klick) hatte und die Lösung hier im Blog niedergeschrieben hatte, denn so hatte ich gleich die Steilvorlage zur Lösung dieses Problems.

$ sudo su

# cd /etc/polkit-1/localauthority/50-local.d

# vi 51-allow-wifi-scan.pkla

Sodann schreibe / kopiere man folgende Zeilen hinein, speichern und beenden.

[Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.wifi.scan
ResultAny=no
ResultInactive=no
ResultActive=yes

Beim nächsten Login über XDMCP sollte die Meldung nicht mehr auftauchen.

Kurztipp: Der Download wird als root und nicht Sandbox-geschützt…

Nach dem Upgrade auf Ubuntu 20.04 und dem Versuch, mit Synaptic Software zu installieren, erhielt ich zwischendurch folgenden Warnhinweis:

Die Installationsprozesse von Synaptic scheinen als Benutzer „_apt“ zu laufen, der Benutzer „_apt“ hatte jedoch keine Rechte, auf das oben genannte Verzeichnis zugreifen zu dürfen. Folgendes Kommando beendete den Spuk:

sudo chown _apt /root/.synaptic

Kurztipp: Die Systemrichtlinien verhindern…

Nach dem Login über XDMCP erschien immer nach kurzer Zeit folgender Dialog:

Eine Antwort auf dieser Seite (klick) lieferte mir die Lösung: Ein „PolicyKit Local Authority File“ musste her.

$ sudo su

# cd /etc/polkit-1/localauthority/50-local.d

# vi 50-allow-network-manager.pkla 

[Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.network-control
ResultAny=no
ResultInactive=no
ResultActive=yes

Danach wurde alles gut.

Xubuntu 16.04 auf HP ProLiant Microserver Gen10

Ich weiß nicht, woran es liegt, aber das dutzendfach auf anderer Hardware durchgeführte Szenario „ISO-File auf USB-Stick dd’en, mit USB-Stick booten, installieren, fertig“ mag beim HP ProLiant Microserver Gen10 und Xubuntu 16.04 einfach nicht gelingen. Im HP steckt nur eine SSD am Sata-Port 5, das BIOS habe ich nicht verändert. Die direkte Installation aus dem GRUB-Bootmenü des Installations-USB-Sticks hängt irgendwo bei der Netzwerkerkennung, die grafische Installation friert zwischendurch ein oder scheitert alternativ im Anschluss an die Partitionierung beim Kopieren der ersten Dateien.

Als Ausweg habe ich das Installation-ISO für Ubuntu Server 16.04 verwendet, die Installation problemlos über die Text-Oberfläche durchgeführt, das frisch installierte System gebootet, obligatorisch mittels „apt update && apt upgrade“ auf den neuesten Stand gebracht, mittels „shutdown -r now“ den jüngsten jüngstinstallierten Kernel gebootet und dann ein „apt install xubuntu-desktop“ durchgeführt, um den Rest von Xubuntu nachzuinstallieren.

Ferner habe ich light-locker und/oder gnome-screensaver in Verdacht, dass sie unter X zum Einfrieren der grafischen Oberfläche führen – per ssh kam ich noch auf das System und konnte manchmal etwas durch einen Neustart von lightdm retten). Nachdem ich die beiden deinstalliert habe (light-locker macht auf meinen Ubuntu-Notebooks auch immer nur Mist), habe ich kein Einfrieren mehr feststellen müssen.

Sony Xperia X Compact und Ubuntu 14.04

Stand heute (04.03.2017) wird mein Sony Xperia X Compact („XC“) nicht als MTP-Gerät von Ubuntu 14.04.5 LTS erkannt, wenn ich es mit dem beigefügten USB-Kabel an mein Notebook anschließe. dmesg zeigt dies hier:

[294511.879537] usb 2-1.2: new high-speed USB device number 17 using ehci-pci
[294511.973305] usb 2-1.2: New USB device found, idVendor=0fce, idProduct=01e8
[294511.973313] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[294511.973318] usb 2-1.2: Product: F5321
[294511.973321] usb 2-1.2: Manufacturer: Sony
[294511.973324] usb 2-1.2: SerialNumber: QV702xxxxx

Beim Anstöpseln des XC und Wahl von „Dateien übertragen“ spuckt das Syslog dies hier aus:

Mar  4 09:49:56 localhost kernel: [295026.967823] usb 2-1.2: new high-speed USB device number 19 using ehci-pci
Mar  4 09:49:56 localhost kernel: [295027.061437] usb 2-1.2: New USB device found, idVendor=0fce, idProduct=01e8
Mar  4 09:49:56 localhost kernel: [295027.061445] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar  4 09:49:56 localhost kernel: [295027.061449] usb 2-1.2: Product: F5321
Mar  4 09:49:56 localhost kernel: [295027.061453] usb 2-1.2: Manufacturer: Sony
Mar  4 09:49:56 localhost kernel: [295027.061456] usb 2-1.2: SerialNumber: QV702FGJ0B
Mar  4 09:49:56 localhost mtp-probe: checking bus 2, device 19: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
Mar  4 09:49:56 localhost mtp-probe: bus: 2, device: 19 was not an MTP device

„Device was not an MTP device“. Vermutung: Linux führt irgendwo eine Liste, anhand derer entschieden wird, ob ein USB-Gerät ein MTP-Device ist oder nicht. Und richtig, diese befindet sich hier:

/lib/udev/rules.d/69-libmtp.rules

Folgendes ist zu erledigen:

  • Als root mit einem Editor die Datei öffnen:
    sudo vi /lib/udev/rules.d/69-libmtp.rules
  • Einen Eintrag kopieren und einfügen (ich habe die des „Z3 compact“ gewählt)
  • idProduct durch die des X Compact ersetzen (siehe syslog-Ausgabe: 01e8)
  • Datei speichern
  • Smartphone neu anstöpseln und „Datei übertragen“ wählen
  • Freuen!

Für die Copy-Paster unter Euch hier meine beiden Zeilen für die libmtp.rules:

# SONY Xperia X Compact MTP
ATTR{idVendor}=="0fce", ATTR{idProduct}=="01e8", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Update: Hat man auf dem X Compact in den Entwickleroptionen das USB-Debugging aktiviert, so meldet es sich mit der idProduct 51e8. Eine weitere Zeile ist dann den MTP-Rules hinzuzufügen.

Kurztipp: sysdba-Passwort nach Xubuntu-Neuinstallation

Während der Installation von firebird2.5-super unter Xubuntu 14.04.3 LTS öffnet sich ein Dialog zur Eingabe des Passworts des SYSDBA. Scheinbar hat die Installation hier einen Bug, denn selbst wenn man hier „masterkey“ eingibt, lautet das Passwort später anders:

dh@kiste:~$ sudo more /etc/firebird/2.5/SYSDBA.password
# Password for firebird SYSDBA user
#
# You may want to use the following commands for changing it:
#   dpkg-reconfigure firebird2.5-super
# or
#   dpkg-reconfigure firebird2.5-classic
#
# If you change the password manually with gsec, please update it here too.
# Keeping this file in sync with the security database is critical for the
# correct functioning of the init.d script and for the ability to change the
# password via `dpkg-reconfigure firebird2.5-super/classic\'

ISC_USER=sysdba
ISC_PASSWORD="c88cec96"

Folgendes ist zu tun: 1. Passwort mittels der Firebird-Bordmittel ändern und 2. das neue Passwort in die SYSDBA.password eintragen.

dh@kiste:~$ gsec -user sysdba -password c88cec96
GSEC> modify sysdba -pw masterkey
Warning - maximum 8 significant bytes of password used
GSEC> quit

dh@kiste:~$ sudo vi /etc/firebird/2.5/SYSDBA.password