macOS 10.12.2 Sierra: Änderungen bei SSH Keys und Passphrase

Mit dem macOS Sierra Update 10.12.2 setzt Apple nun auf die OpenSSH-Version 7.3p1. Im Gegensatz zu früheren Mac-OS Versionen gibt es seit 10.12 Sierra für die Speicherung von SSH-Passphrasen im Schlüsselbund keinen grafischen Abfragedialog mehr. Um Passphrasen und Kennwörter nun im Schlüsselbund ablegen zu können, muss die SSH-Konfigurationsdatei um die Option UseKeychain yes ergänzt werden. Dies lässt sich auch für einzelne Hosts festlegen.

Beispiel:

…

Host Servername
    Hostname 192.168.5.23
    User MeinBenutzerName
    IdentityFile ~/.ssh/PrivatKeyName
    UseKeychain yes

…

OpenSSH lädt die Keys außerdem nicht länger automatisch in den ssh-agent, dies passe das Verhalten von macOS an das OpenSSH-Projekt an.
Falls die Passphrase nicht im Schlüsselbund gespeichert wird, erkundige sich SSH deshalb immer wieder neu nach dem Kennwort. Um den oder die SSH-Schlüssel wieder im Agent verfügbar zu machen, muss die SSH-Konfigurationsdatei um den Zusatz AddKeysToAgent yes ergänzt werden.

Weiterführende Links:
https://www.heise.de/mac-and-i/meldung/macOS-10-12-2-Sierra-Aenderungen-bei-SSH-Keys-und-Passphrase-3588517.html
https://developer.apple.com/library/content/technotes/tn2449/_index.html

SSH-Audit

Jemand hat sich mal hingesetzt und eine Sammlung an Python-Skripten geschrieben, mit dem sich ein SSH-Server auf die verwendete Version, den Algorithmen und Sicherheitsinformationen abklopfen lässt, sowie die dazu passenden Empfehlungen ausgibt. Das Programm ist auf GitHub verfügbar und mit Python 2.6, Python 3.x und PyPy kompatibel.

ssh-audit

Link: https://github.com/arthepsy/ssh-audit

macOS Sierra

Vor nunmehr fünf Wochen hat Apple sein aktuelles Computerbetriebssystem macOS Sierra veröffentlicht. Neben Neuerungen wurden aber auch einige Änderungen unter der Haube durchgeführt.
Eine wesentliche was die Kompatibilität mit älteren Programmen betrifft, ist der Wegfall der Garbage Collection für das Handling des Arbeitsspeichers der Programme. Hat ein Programm auf dieses gesetzt, so wird es nach dem Upgrade leider nicht mehr ausführbar sein, da Apple die Unterstützung für den Garbage Collector in Sierra entfernt hat. Um also vor dem Upgrade prüfen zu können, ob Programme mit Sierra kompatibel sind oder nicht, kann man mit folgenden Befehl im Terminal dies überprüfen, um hinterher keinen Reinfall zu erleben. Allerdings muss für die Prüfung Xcode installiert sein.:

Befehl:

otool -oV /Applications/PROGRAMMNAME.app/Contents/MacOS/PROGRAMMNAME | tail -3

Ausgabe:

Contents of (__DATA,__objc_imageinfo) section
  version 0
    flags 0x6 OBJC_IMAGE_SUPPORTS_GC

Sollte in der Terminalausgabe nun „OBJC_IMAGE_SUPPORTS_GC“ erscheinen, so kommt noch der Garbage Collector zum Einsatz und das Programm ist unter macOS Sierra nicht mehr lauffähig.

Außerdem ist Apple beim Einsatz von OpenSSH von Version 6.x auf 7.x gewechselt. Die Entwickler von OpenSSH haben aber in der Major-Version 7.0 eine wesentliche Änderung vorgenommen, was das automatische Laden von SSH-Schlüsseln in den ssh-agent betrifft. Hat man sich früher mit dem lokalen Mac via SSH auf einen anderen Rechner eingeloggt und sich dann wiederum von diesem mittels Public-Key-Verfahren auf einen weiteren Rechner verbunden, so hat der lokale SSH-Client sowohl Privat-Key als auch die Passphrase in den ssh-agent hinein geladen. Dies funktioniert seit Version 7 nicht mehr. Um sich dennoch Schlüssel und Passphrase des Man-in-the-middle-Computers wieder in den Agent seines lokalen Computers dauerhaft laden zu können, reicht es, wenn man in die benutzereigene Client-Konfiguration folgende Option hinzufügt.

echo "AddKeysToAgent yes" >> ~/.ssh/config

Des weiteren lässt sich wie gewohnt der macOS-Installer auf einem GPT-vorformatierten USB-Stick mit folgendem Konsolenbefehl kopieren, so dass dieser auch für künftige Installationen ohne Internetverbindungen ein Rettungssystem beinhaltet.

sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/Stick --applicationpath /Applications/Install\ macOS\ Sierra.app/ --nointeraction

WLAN am Raspberry PI einrichten

Der Net-Installer des Debian-Port Raspbian für den Raspberry Pi ist recht übersichtlich und auf der Projektseite hier dokumentiert. Da ich in dem Fall zu Anfangs lediglich immer nur ein Grundsystem mit einem SSH-Server auf eine SD-Karte werfe, gibt es keine Möglichkeit, dass man sich mit dem Pi out of the Box via WiFi ins Netz verbinden kann. Leider fehlt bei einer Standart-Debian-Installation auch das Toolkit um WLAN-Adapter zu konfigurieren. Also muss dieses als erstes nach installiert werden:

apt-get install wireless-tools wpasupplicant

Da ich mich auch für den allgemein bei den Pi’s sehr beliebten Edimax EW7811Un USB-Adapter entschieden habe, hilft es auf folgende Weise zu verifizieren ob dieser vom System im eingesteckten Zustand ordentlich erkannt wurde.
Durch Eingabe von lsusb sollte das WLAN-Gerät über den USB-Host-Adapter mit seinen vollen Namen aufgelistet werden.
Mit lsmod kann man prüfen, ob das entsprechende Kernelmodul zu den Realtek-Chip mit geladen wurde. In diesem Fall heisst dies 8192cu.
Als finale Möglichkeit zu Überprüfen ob der Edimax einsatzbereit ist, kann man sich mit iwconfig mal die „aktuelle“ Konfiguration des WLAN-Interface anzeigen lassen. Entscheidend dabei ist, das es einen Eintrag mit wlan0 gibt.

Wenn das alles gegeben ist, kann man mit restlichen Konfiguration weiter machen.

Als erstes muss das WLAN-Gerät in die Datei /etc/network/interfaces hinzugefügt und die Konfigurationsparameter mitgegeben werden. In diesem Fall soll die IP-Adresse via DHCP bezogen werden und es wird in der letzten Zeile ein Verweis auf die Konfigurationsdatei wpa_supplicant.conf gesetzt.

/etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary LAN-network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The Edimax USB-WiFi interface
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Die eigentliche WLAN-Konfiguration mit den Parametern zum Aufbau der (verschlüsselten) Verbindung wird unter /etc/wpa_supplicant/wpa_supplicant.conf definiert. In dem Fall WPA/WPA2 verschlüsselt. Sollte die Datei noch nicht existieren, dann erstellt man sie einfach.

/etc/wpa_supplicant/wpa_supplicant.conf:

network={
        ssid="_Name_des_Netwerk_"
        scan_ssid=1
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        psk="_Absolut_sicheres_Passwort_"
}

Mit dem Befehl ifup wlan0 wird dann das Interface neu gestartet und soll eine IP-Adresse beziehen mit der es sich dann versucht ein zu wählen. Ein Neustart des gesamten Raspbian tut aber auch nicht weh. Wenn ein ifconfig wlan0 als Ausgabe plausible Adress- und Netzmaskenwerte gibt, dann wurde alles richtig gemacht.

Im Wiki des Ubuntu-Forum gibt es auch sehr hilfreiche Howtos und Erklärungen zu Thema, die einem weiter bringen.
http://wiki.ubuntuusers.de/WLAN/Installation
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant

Kopieren des öffentlichen Schlüssels für die SSH unter Mac OS X

Vor wenigen Tagen habe ich meinen kleinen Home-Server mit einem neuen System von grundauf neu aufgesetzt. Da ich schliesslich ein fauler Mensch bin und mich es ziemlich nervt auch noch für eine SSH-Sitzung mir ein Passwort zu merken, nutze ich also für so einen Fall die Authentifizierung über Public-Keys. Aber aus welchen Gründen auch immer, es gibt unter Mac OS X leider nicht das Programm ssh-copy-id, um den öffentlichen Teil des Schlüsselpaars auf den gewünschten Host zu kopieren. Stattdessen kann man das aber auch über den klassischen Unix-Weg der kleinen Dinge mit Pipe und Ausgabeumleitung erledigen. Bevor man dies tut, sollte man prüfen ob im Benutzer-Verzeichnis des Zielrechners der Ordner .ssh/ bereits existiert. Wenn nicht, so kann man diesen über die normale SSH-Benutzeranmeldung mit Passwortabfrage unter folgendem Befehl erstellen:

ssh user@server.tld 'mkdir .ssh'

Mit dem folgendem Befehl wird nun der Publik-Key des Schlüsselpaar aus dem lokalem .ssh-Ordner ausgelesen, an den Server umgeleitet und in das dortige .ssh-Verzeichniss eingefügt.

cat .ssh/id_rsa.pub | ssh user@server.tld 'cat >> .ssh/authorized_keys'

Jetzt ist es aber immer noch möglich sich mit dem Passwort anzumelden. Damit man sich nun mit dem Key anmelden kann, setzt man die Optionen

PasswordAuthentication no
UsePAM no

in der Konfigurationsdatei des SSH-Servers. Schlussendlich wird der dieser neu gestartet.