In Kubernetes wurde ein Sicherheitsproblem entdeckt, bei dem ein unbefugter Benutzer in der Lage sein kann, per SSH auf einen VM-Knoten zuzugreifen, der ein mit dem Kubernetes Image…
Der Sicherheitsexperten Qualys hat mit der RegreSSHion getauften Sicherheitslücke in OpenSSH eine Schwachstelle gefunden, die sich remote ausnutzen lässt, um Code darüber auszuführen.
Eine von Qualys entdeckte Sicherheitslücke im OpenSSH-Server mit einem CVSS-Score von 9 wurde geschlossen. Erfolgreiche Angreifer erhalten automatisch Root-Rechte.
Dem Forscherteam von Qualys ist es gelungen, eine ältere Sicherheitslücke in OpenSSH, die schon eigentlich längst geschlossen war, erneut auszunutzen. Die neue Lücke wird als CVE-2024-6387 geführt und ist deswegen brisant, weil Sie bei Erfolg dem Angreifer Root-Rechte ohne vorherige Authentifizierung ermöglicht. Die nötigen Bedingungen für ein Ausnutzen der Lücke sind allerdings nicht ganz trivial.
Die gesamte Erläuterung der Sicherheitslücke ist im Bericht von Qualys umfangreich erläutert wollen. Wenn wir es schaffen, werden wir diesen schon Mittwoch im Risikozone-Podcast detaillierter erläutern.
So viel sei gesagt: die Lücke existierte schon mal als CVE-2006-5051, wurde dann gefixt und konnte jetzt (erstmals) ausgenutzt werden, da der eigentlich kritische Teil 2020 wieder versehentlich eingebaut wurde.
Der Fehler selber baut darauf, dass syslog() zur Protokollierung asynchron aufgerufen wird, obwohl die Funktion nicht "async-signal-safe" ist. Kann ein Angreifer Timingeigenschaften ausnutzen, wird er in die Lage versetzt, Code einzuschleusen, der in einem privilegierten Teil von OpenSSH ausgeführt wird. Der Zeitaufwand ist allerdings hierfür nicht zu unterschätzen, da das Codefragment nur bei einem Verbindungstimeout aufgerufen wird.
Es ist gemäß des Qualys-Berichtes hervorzuheben:
Mit anderen Worten: abhängig von eurem System ist die Schwachstelle vorhanden, weswegen ihr in eure Distribution schauen solltet, ob es Updates gibt.
OpenSSH ist nichtsdestotrotz im Hinblick auf seine Rolle und Exposition eines der sichersten Programme der Welt. Die Software ist ein sehr stringent abgesicherter Dienst, der u. a. auf Sandboxing-Mechansimen setzt, um den Umfang der Codesegmente, die als root ausgeführt werden, gering zu halten. Diese Lücke ist eine der seltenen Situationen, in der trotzdem ein Security-Bug vorhanden ist. Dabei ist eine Ausnutzung vergleichsweise aufwändig.
Cisco Talos, ein zu Cisco gehörendes Cybersecurity-Unternehmen, beobachtet seit Mitte März 2024 einen weltweiten Anstieg von Brute-Force-Angriffen gegen eine Vielzahl von Zielen, darunter…
OpenSSH will die Unterstützung für DSA-Schlüssel entfernen und informiert über den Zeitplan und den einhergehenden Prozess dazu.
Die freie SSH-Implementierung OpenSSH ist in Version 9.4 erschienen. Die neue Ausgabe bringt Bugfixes und einige neue Features.
Darunter fällt das neue ssh_config “Tag” und ein entsprechendes “Match tag”-Prädikat. Das Config-Tag könne dazu verwendet werden, um Konfigurationsblöcke auszuwählen, was die Konfiguration erleichtern soll. Neu ist auch die Möglichkeit des Forwarding von Unix-Domain-Sockets.
Neben den Neuerungen werden auch eine Reihe von Fehlern ausgebügelt. Die neue Version entfernt die Unterstützung für ältere Versionen von libcrypto, teilen die Entwickler mit. Und OpenSSH benötigt nun LibreSSL ab Version 3.1.0 oder OpenSSL ab Version 1.1.1.
Der Beitrag OpenSSH 9.4 verbessert Konfiguration erschien zuerst auf Linux-Magazin.
Mit Version 9.3p2 der freien Verschlüsselungssuite OpenSSH schließen die Entwickler eine kritische Sicherheitslücke, die den Remote-Zugriff ermöglicht.
Angreifer könnten dann unter bestimmten Umständen Schadcode einschleusen, warnt das OpenSSH-Projekt. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Sicherheitslücke auf dem Radar und stuft sie als hochriskant ein. Ein entfernter, anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um einen Denial of Service Angriff durchzuführen, schreibt das BSI in seiner Warnmeldung.
Die Entwickler erläutern in der Ankündigung zur neuen Version von OpenSSH, die die Lücke schließt, dass bestimmte Voraussetzungen gegeben sein müssen, damit der Remote-Zugriff funktioniert. So sei die das Vorhandensein bestimmter Bibliotheken auf dem Opfersystem nötig und die Fernausnutzung erfordert auch, dass der Agent an ein vom Angreifer kontrolliertes System weitergeleitet wurde.
Der Beitrag OpenSSH 9.3p2 schließt hochriskante Lücke erschien zuerst auf Linux-Magazin.
Das Raspberry Pi OS wurde aktualisiert und es gibt einen neuen Linux-Kernel. Während in der Vorgänger-Version 5.15 eingesetzt wurde, ist in der neueste Version Linux-Kernel 6.1.21 vorinstalliert. Neben diversen Bugfixes hat das Team auch andere Software-Pakete aktualisiert. Mit von der Partie sind Chrome 113 sowie aktualisierte Versionen von RealVNC Server und Viewer. Der Raspberry Pi Imager wurde ebenfalls aktualisiert. Ebenso gibt es ein Update bezüglich VLC-Hardware-Beschleunigung. Matlab ist ab sofort als Version 13.2.1 verfügbar. Tipp: Hast Du Probleme mit Chromium, […]
Der Beitrag Raspberry Pi OS ab sofort mit Linux-Kernel 6.1 ist von bitblokes.de.
Mit Version 9.3 der freien SSH-Suite OpenSSH beheben die Entwickler unter anderem Sicherheitsprobleme.
Die neue Version enthalte Korrekturen für ein Sicherheitsproblem und ein Speicher Sicherheitsproblem, teilen die Entwickler mit. Das Speichersicherheitsproblem sei wohl nicht ausnutzbar, heißt es in der Ankündigung, man melde aber die meisten netzwerkerreichbaren Speicherfehler als Sicherheitslücken.
Das Problem stecke im portablen OpenSSH, das eine Implementierung der “getrrsetbyname”-Funktion zur Verwendung durch die VerifyHostKeyDNS-Funktion biete, falls die Standardbibliothek sie nicht zur Verfügung. Eine speziell gestaltete DNS-Antwort könnte diese Funktion dazu veranlassen ein Out-of-Bounds-Read von benachbarten Stack-Daten durchzuführen. Mehr als ein Denial-of- Service beim SSH-Client sei damit wohl aber nicht zu erreichen.
Zu den neuen Funktionen zähle, dass “ssh-keygen” und “ssh-keyscan” akzeptieren nun die Option “-Ohashalg=sha1|sha256” bei der Ausgabe von SSHFP-Fingerprints, um so die Auswahl des Algorithmus zu ermöglichen.
Der Beitrag OpenSSH 9.3 schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.
Mit der Veröffentlichung von OpenSSH 9.2 beseitigen die Entwickler der freien SSH-Implementierung unter anderem Fehler und schließen Sicherheitslücken.
Zu letzteren zählte ein Speicherfehler vor der Authentifizierung, der sich in OpenSSH 9.1 eingeschlichen hat. Die Entwickler glauben allerdings nicht, dass der Fehler für Angreifer ausnutzbar gewesen sei. Beseitigt wurde auch ein Problem, dass in OpenSSH-Versionen nach 8.7 die PermitRemoteOpen-Option ihr erstes Argument ignorierte, wenn es nicht eines der speziellen Schlüsselwörter “any” oder “none” war, was dazu führte, dass die Berechtigungsliste nicht geöffnet werden konnte, wenn nur eine Berechtigung angegeben war.
ZU den neuen Features zählt die Unterstützung für Channel-Inaktivitäts-Timeouts über eine neue sshd_config-ChannelTimeout-Direktive. Dadurch können Kanäle, die in einem konfigurierbaren Intervall keinen Verkehr gesehen haben, automatisch geschlossen werden.
Die Release Notes zählen alle Änderungen auf.
Der Beitrag OpenSSH 9.2 beseitigt Bugs erschien zuerst auf Linux-Magazin.
Wer die Remotedesktopverbindung von Windows verwendet oder mit PuTTY auf andere PCs zugreift, der kennt das Problem mit den vielen offenen Verbindungen und deren Verwaltung. Lange Zeit konnte man sich auf Tools wie mRemote verlassen und konnte mehrere Verbindungen in einem Programm zusammenfassen und perfekt verwalten. Leider wird mRemote nicht mehr weiterentwickelt (Vers. 1.50 von 2008). Dafür gibt es inzwischen einen Open Source Zweig für dieses Remoteverwaltungstool. Das Projekt nennt sich mRemoteNG "Mulit-Remote Next Generation" und ist zurzeit in der Version 1.63 erhältlich.
Wie schon der Vorgänger unterstützt mRemoteNG jede Menge Protokolle und ist zusätzlich portabel erhältlich
Das Programm erklärt sich von selbst. Man richtet eine Verbindung ein und hinterlegt seine Daten, wie zum Beispiel Auflösung, Protokoll, IP bzw. Nutzer und Passwort und schon kann man loslegen.
Es ist jedoch zu beachten, dass für Firefox der XULrunner und für Citrix ein Client nachinstalliert werden muss. Der Windows RDP Client wird natürlich auch benötigt, jedoch ist dieser auf fast jedem Windowssystem schon vorinstalliert.
Wer mehrere Verbindungen zum Arbeiten offen hat, der kommt an diesem Tool nicht vorbei. Es gibt bestimmt auch Alternativen, jedoch ist mRemoteNG zurzeit mein Favorit.
Das Windows Subsystem for Linux ist erwachsen geworden. Es ist nur für Windows 10 und Windows 11 im Microsoft Store erhältlich und gilt nicht mehr als »experimentell«. Der größte Vorteil der neuen Bezugsquelle: WSL-Updates werden in Zukunft unabhängig von Windows-Updates viel einfacher und schneller erfolgen.
Die Umstellung auf die Microsoft-Store-Variante ist denkbar einfach: Entweder installieren Sie WSL einfach aus dem Microsoft Store neu (vorhandene WSL-Distributionen bleiben dabei erhalten), oder Sie führen wsl --update aus (das setzt aber voraus, dass Ihre Windows-Version über alle aktuellen Updates verfügt).
Aus meiner persönlichen Perspektive viel interessanter ist der Umstand, dass WSL nun endlich systemd unterstützt. Die Aktivierung erfolgt ganz einfach, in dem Sie in der WSL-Distribution die Datei /etc/wsl.conf verändern und dort zwei Zeilen hinzufügen:
Anmelden
# in /etc/wsl.conf (innerhalb der WSL-Distribution)
[boot]
systemd=true
Die Änderung wird erst aktiv, wenn Sie die Distribution beenden, WSL herunterfahren (wsl --shutdown) und die Distribution dann neuerlich starten. Bei meinen Tests hat die systemd-Aktivierung erstaunlicherweise auch bei WSL-Distributionen funktioniert, die schon recht alt waren (z.B. Ubuntu 21.04).
Der entscheidende Fortschritt im Vergleich zu älteren WSL-Versionen ohne systemd besteht darin, dass es nun endlich unkompliziert möglich ist, Server-Dienste (SSH, Apache, MySQL usw.) so einzurichten, dass Sie mit dem Start der WSL-Distribution automatisch mitaktiviert werden. Auch Cron-Jobs funktionieren jetzt ohne Verrenkungen.
Beachten Sie, dass Server-Dienste nur zur Verfügung stehen, solange die betreffende WSL-Distribution aktiv ist, also ein WSL-Fenster geöffnet ist.
Noch zwei Tipps zum Betrieb eines SSH-Servers unter WSL mit Ubuntu 22.04. Der initiale Start scheitert, weil es keine SSH-Host-Keys gibt, und weil die sonst übliche automatischer Erzeugung beim ersten Start aus mir nicht nachvollziehbaren scheitert. Abhilfe schafft einmalig ssh-keygen -A. Danach führt systemctl enable --now ssh zum Erfolg. Der Versuch, sich von Windows aus mit ssh <name>@172.30.xxx.yyy anzumelden, führt zum Fehler permission denied: publickey. Schuld ist die Einstellung PasswordAuthentication no in /etc/ssh/sshd_config innerhalb von Ubuntu. Stellen Sie die Option auf yes und starten Sie den SSH-Server neu, dann klappt es.
Alles in allem ist die Verwendung von SSH im Zusammenspiel mit WSL + Ubuntu 22.04 weiterhin mühsam.
WSL liegt in zwei grundlegenden Varianten/Architekturen vor, die (noch) beide gepflegt werden.
WSL 1 bildet dagegen Linux-Funktionen nach (und ist aus technischer Sicht viel bemerkenswerter). Die Integration der WSL-Distributionen in das lokale Netzwerk ist anders als bei WSL 2 (manchmal vorteilhafter). Der Hauptunterschied: WSL 1 erfordert keine Virtualisierung, läuft also auch dann, wenn sich Windows selbst in einer virtuellen Maschine befindet!
Standardmäßig wird bei einer WSL-Installation aus dem Microsoft Store nur WSL 2 aktiviert. Die für WSL 1 erforderlichen Features können aber problemlos mit wsl --install --enable-wsl1 nachinstalliert werden.
Losgelöst von der WLS-Architektur 1 und 2 gibt es auch eine WSL-Versionsnummer, die nichts mit der Architektur zu tun hat. wsl --version liefert aktuell 1.0.0.0 und zeigt, dass WSL dem Beta-Stadium entwachsen ist.
Aus meiner Linux-Perspektive ist es immer wieder erstaunlich, wie viele »offizielle« Wege es gibt, um Windows-Komponenten zu installieren:
Andere Komponenten wie der SSH-Client und -Server sind tief in den Einstellungen versteckt (Apps / Optionale Features, das muss man wirklich erst mal finden …).
Wieder andere Komponenten wie Hyper-V & Co. gelten als Windows Features und werden über das gleichnamige Programm aktiviert.
Da soll noch einer sagen, Linux wäre schwer verständlich ;-)
Wer Linux ausprobieren oder samt Desktop anwenden möchte, unter Windows arbeitet und keine physische Installation durchführen will, für den/die ist das Virtualisierungssystem VirtualBox eine attraktive Wahl. Dieser Artikel fasst die wichtigsten Schritte einer Installation von Ubuntu 22.04 zusammen und erklärt auch die Nutzung der Gasterweiterungen und die Konfiguration für eine SSH-Verbindung zwischen Host (=Windows) und der Virtuellen Maschine (VM).
Testumgebung: Windows-PC mit Intel-CPU, Windows 11 Pro mit 22H2-Update (Hyper-V und WSL aktiviert), VirtualBox 7.0
Der erste Schritt ist die Installation von VirtualBox. Dieses Virtualisierungssystem von Oracle kann von der folgenden Seite kostenlos heruntergeladen werden:
https://www.virtualbox.org/wiki/Downloads
Beachten Sie, dass das Grundprodukt VirtualBox zwar kostenlos genutzt werden darf, das diese Regel aber nicht für das optionale VirtualBox Extension Pack gilt! Dessen Nutzung ist nur Privatnutzern bzw. zur Evaluation erlaubt, erfordert beim Einsatz in Firmen aber eine Lizenz! Die im Extension Pack enthaltenen Funktionen (RDP, Disk Image Verschlüsselung, NVMe und PXE Boot für Intel Systeme) werden normalerweise nicht benötigt. Wenn Sie unsicher sind, installieren Sie das Extension Pack nicht!
Als Grundlage für die Installation müssen Sie von der Ubuntu-Website ein ISO-Image für Ubuntu 22.04 (64 Bit) herunterladen.
https://ubuntu.com/download/desktop
Mit dem Button Neu starten Sie die Installation einer neuen VM. Im ersten Dialog müssen Sie der VM einen Namen geben, einen Speicherort am Hostsystem (in unserem Fall ist das Windows) angeben, ein ISO-Image auswählen sowie Linux-Typ und -Versionsnummer auswählen.
Ubuntu 22.04 wird von VirtualBox besonders gut unterstützt. Standardmäßig wird eine Unattended Installation durchgeführt. Damit kommen Sie mit dem Installationsprogramm von Ubuntu gar nicht in Berührung. Stattdessen geben Sie den Hostnamen, den Benutzernamen und das Passwort für die Ubuntu-VM vorweg in einem VirtualBox-Dialog an. In der virtuellen Maschine werden die sogenannten »Gasterweiterungen« automatisch installiert. Das ermöglicht eine bessere Integration zwischen Hostsystem (Windows) und Gast (Ubuntu), z.B. zum Austausch von Text über die Zwischenablage oder zum Austausch von Dateien über ein gemeinsames Verzeichnis (Shared Folder).
Tipp: Verwenden Sie ein Passwort ohne Sonderzeichen und ohne die Buchstaben Y und Z. Nach der Installation gilt für den Ubuntu-Login das US-Tastaturlayout.
Bevor es richtig losgeht, müssen Sie noch die Eckdaten der VM einstellen. Meine Empfehlung:
Den Arbeitsspeicher und das RAM können Sie bei Bedarf später unkompliziert verändern. Die Disk-Größe kann hingegen nur sehr umständlich vergrößert werden, eine Verkleinerung ist nahezu unmöglich. Vergleichsweise einfach ist es, später eine zweite Disk hinzuzufügen. Allerdings müssen Sie schon etwas Linux-Erfahrung haben, um die zweite Disk dann auch innerhalb von Ubuntu sinnvoll nützen zu können.
Nach dem Zusammenfassungsdialog startet VirtualBox die virtuelle Maschine und führt darin — wie von Zauberhand — die gesamte Installation durch. Das dauert einige Minuten, während der Sie nur zusehen können (oder sich einer anderen Aufgabe zuwenden).
Nach Abschluss der Installation wird die virtuelle Maschine neu gestartet. Sie können sich jetzt einloggen, wobei Sie den im Dialog »Unattended Installation« Namen und das dort gewählte Passwort angeben. Das VirtualBox-Fenster ist anfänglich ziemlich klein. Sie können es einfach vergrößern, die Auflösung des Desktops der virtuellen Maschine passt sich automatisch an.
Ein Nachteil der Unattended Installation besteht darin, dass Ubuntu beim ersten Start Englisch als Sprache verwendet und ein US-Tastaturlayout vorsieht. Um die Einstellungen zu ändern, starten Sie das Programm Settings, am einfachsten im Systemmenü, das Sie rechts oben im Panel öffnen.
Die Spracheinstellungen finden Sie im Modul Region & Lanugage. Mit Manage Installed Languages und Install/Remove Language fügen Sie German hinzu. (Dabei müssen diverse Pakete installiert werden, weswegen dieser Vorgang ca. eine Minute dauert.) Schließlich können Sie die Präferenz der Sprachen einstellen, in dem Sie Deutsch in der Liste der installierten Sprachen ganz nach oben verschieben. Die geänderte Sprache ist noch nicht aktiv — dazu müssen Sie sich aus- und neu einloggen.
Vorher sollten Sie gleich noch das Tastaturlayout ändern. Dazu wechseln Sie im Einstellungsprogramm in den Dialog Keyboard, fügen zuerst das neue Layout German hinzu und entfernen dann das Layout English (US).
Damit diese Einstellungen wirksam werden, müssen Sie sich aus- und neu einloggen. Im Systemmenü, das Sie rechts oben im Panel öffnen, klicken Sie zuerst auf Power Off/Log Out und im nun erscheinenden Untermenü auf Log Out.
Normalerweise hat der erste in Ubuntu eingerichtete Benutzer sudo-Rechte. Dafür gibt es unter Ubuntu kein Passwort für den Benutzer root.
Wenn Sie in VirtualBox die Unattended Installation durchgeführt haben, gelten andere Regeln: Der eingerichtete Benutzer gehört nicht zur sudo-Gruppe und hat entsprechend keine administrativen Rechte. Dafür hat der Benutzer root das gleiche Passwort, das Sie dem Standardbenutzer zugewiesen haben.
Damit sich Ubuntu auch in VirtualBox so verhält wie immer, öffnen Sie über Aktivitäten ein Terminal-Fenster und führen dann die folgenden Kommandos aus, mit denen Sie den Standardbenutzer der Gruppe sudo hinzufügen:
username$ su -l
Passwort: ******** (das Passwort, das Sie in VirtualBox
vor der Installation angegeben haben)
root# usermod -a -G sudo <username>
Anstelle von <username> geben Sie den Namen Ihres Accounts an.
Die Änderung wird wiederum erst wirksam, wenn Sie sich in Ubuntu aus- und neu einloggen.
Nachdem Sie sudo repariert haben, können Sie — wenn Sie möchten — noch das Tastaturlayout für den Ubuntu-Login auf Deutsch umstellen. Dazu öffnen Sie ein Terminal-Fenster und führen dort sudo dpkg-reconfigure keyboard-configuration aus. Als Tastaturmodell wählen Sie Generic 105-key PC, als Sprache German. Alle weiteren Optionen bestätigen Sie einfach mit Return.
Damit Sie unkompliziert Text zwischen dem Host-Rechner (Windows) und der virtuellen Maschine (Ubuntu) über die Zwischenablage austauschen können, führen Sie im Menü des VirtualBox-Fensters Geräte / Gemeinsame Zwischenablage / Bidirektional aus. (Diese Funktion setzt voraus, dass in der virtuellen Maschine die VirtualBox-Gasterweiterungen installiert sind. Das ist bei der Unattached Installation automatisch der Fall. Wenn Sie eine manuelle Installation von Ubuntu durchgeführt haben, müssen Sie die Pakete virtualbox-guest-utils und virtualbox-guest-x11 installieren und außerdem den Ubuntu-Standardbenutzer der zusätzlichen Gruppe vboxsf zuordnen.)
Über Geräte / Gemeinsame Ordner gelangen Sie in einen Dialog, in dem Sie ein Windows-Verzeichnis (in der folgenden Abbildung: Dokumente) mit einem Verzeichnis innerhalb der virtuellen Maschine (hier: /mnt/win-documents) verbinden können. Damit können Sie innerhalb der virtuellen Maschine unkompliziert auf Windows-Dateien zugreifen. (Auch diese Funktion setzt voraus, dass zuvor die VirtualBox-Gasterweiterungen installiert wurden.)
Wenn ich auf Kommandoebene arbeite, bediene ich meine virtuellen Maschinen gerne über SSH. Unter Ubuntu muss dazu der SSH-Server installiert werden, was mit sudo apt install openssh-server rasch gelingt.
Das reicht aber noch nicht: VirtualBox gibt der virtuellen Maschine standardmäßig mittels Network Address Translation Zugriff auf die Netzwerkverbindung des Host-Computers. Die virtuelle Maschine ist aber im Netzwerk des Hosts unsichtbar, eine SSH-Verbindung ist unmöglich.
Die einfachste Lösung ist eine Port-Weiterleitung. Dazu führen Sie im VirtualBox-Fenster Geräte / Netzwerk / Einstellungen aus, klappen bei Adapter 1 den Bereich Erweitert aus und klicken auf Port-Weiterleitung. Nun richten Sie eine neue Regel ein, die Port 2222 des Hosts (127.0.0.1) mit Port 22 der virtuellen Maschine (10.0.2.15) verbindet.
Nachdem Sie die Einstellungen gespeichert haben (ein Neustart der virtuellen Maschine ist nicht notwendig), können Sie in cmd.exe oder in der PowerShell von Windows mit dem folgenden Kommando eine SSH-Verbindung in die virtuelle Maschine herstellen:
ssh -p 2222 name@localhost
Wichtig ist dabei die Option -p 2222. ssh soll nicht wie üblich Port 22 verwenden, sondern eben Port 2222. Wichtig ist auch, dass Sie als Zieladresse localhost angeben. Aufgrund der Port-Weiterleitung landen Sie wunschgemäß in der virtuellen Maschine. Anstelle von name geben Sie Ihren Ubuntu-Account-Namen an.
Die Windows-Variante von VirtualBox 7 hat mich mit dem Programm ein wenig versöhnt. In den letzten Jahren hatte ich unter Windows nämlich derart häufig Stabilitätsprobleme (ausgelöst vermutlich durch das schlechte Zusammenspiel mit Hyper-V), dass ich den Einsatz von VirtualBox für Windows nicht mehr empfohlen habe und diesen auch im Linux-Unterricht — so gut wie möglich — vermieden habe. Mit Version 7 hatte ich diesbezüglich (bisher) keine Probleme — gut so.
Ein wenig irritierend ist der bunte Mix von deutschen und englischen Texten in den Dialogen. Aus meiner Sicht wäre English Only die beste Option. Aber wenn eine deutschsprachige GUI erwünscht ist, wäre es gut, die Lokalisierung konsequent fertigzustellen. So wirkt das halbfertig.
Die Unattended Installation überzeugt mich nicht: Was ich an Zeit während der Installation gespart habe, musste ich später wieder investieren, um Sprach- und Tastatureinstellungen zu ändern und die sudo-Konfiguration zu reparieren. Da ist mir eine manuelle Installation lieber, das weiß ich wenigstens, was ich bekomme. Als einziger Vorteil bleibt die automatische Installation der VirtualBox-Gasterweiterungen, deren manuelle Durchführung mühsam ist.
VirtualBox 7 unterstützt erstmals auch Apple Rechner mit Apple Silicon (M1, M2 …). Oracle weist explizit darauf hin, dass diese Funktionen noch experimentell und langsam sind. Ich habe VirtualBox 7 auf einem Mac Mini mit M1-CPU dennoch ausprobiert, und war etwas konsterniert: Die virtuellen Maschinen müssen eine 32-Bit x86-CPU verwenden (kein 64-Bit x86, auch nicht ARM).
Ganz egal, wie die Performance ist, engt das die Auswahl doch sehr stark ein. Viele Desktop-Distributionen für x86 sind 64-Bit-only. Ich hätte eigentlich erwartet, dass VirtualBox wie UTM auf virtuelle Maschinen für die ARM-Plattform setzt, aber meine diesbezüglichen Experimente sind ins Leere gegangen.
Gescheitert bin ich selbst mit dem Versuch, eine 32-Bit-Version (i386) von Debian zu installieren — selbst hier die Nachricht unsupported CPU. Diese Beta ist wirklich noch sehr experimentell :-(
Es gibt unter macOS Mojave keine Autovervollständigung der definierten Hosts aus der Datei ~/.ssh/config. Hierzu habe ich in die Datei ~/.bash_profile folgende Funktion eingetragen : Nun reicht wieder ein ssh TAB in der Konsole um die einzelnen Hosts und der … Weiterlesen →
Der Beitrag macOS: SSH Hosts mit Autovervollständigung aufrufen erschien zuerst auf Got tty.
