Seite 13 von 14

macOS: Unsichtbare Zertifikate aus der Keychain löschen

11.11.2017 / / Keine Kommentare

In gewissen Situation kommt es vor, dass Apples Keychain („Schlüsselbund“) Zertifikate nicht mehr anzeigt, obwohl sie im System vorhanden sind. Problematisch ist dies, wenn bspw. ein altes Zertifikat gelöscht und durch ein neues ersetzt werden soll. In meinem akuten Fall ging es um den Austausch des Root-Zertifikats einer lokalen CA (Certificate Authority). Das alte Zertifikat wurde nicht angezeigt und ein Import des neuen, auf den gleichen Namen lautenden Zertifikats schlug ohne Angabe von Gründen fehl.

Wenn der Name des nicht mehr dargestellten Zertifikats bekannt ist, lässt sich dieses über das Command Line Interface löschen. Für Zertifikate in der Keychain „System“:

sudo security delete-certificate -c "Zertifikatsname" -t /Library/Keychains/System.keychain

Oder bei Zertifikaten, die im Schlüsselbund „login“ eines Benutzers abgespeichert wurden:

sudo security delete-certificate -c "Zertifikatsname" -t /Users/Benutzername/Library/Keychains/login.keychain

Ein neues Zertifikat kann zum Beispiel mittels

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain neues_zertifikat.crt

in die Systems-Keychain (so dass es von allen Benutzern des Rechners genutzt werden kann) importiert werden.

Permanent Redirect auf https in der Apache-Config

07.07.2017 / / Ein Kommentar

Regelmäßig stehe ich vor dem Problem, HTTP-Anfragen auf SSL HTTPS umzuleiten. Die einfachste Lösung ist der Einzeiler Redirect permanent / https://www.example.com. Wem dies genügt und wer ohne mod_rewrite auskommt, der kann hier mit dem Lesen aufhören.
Für meine Anwendungsfälle, habe ich hier eine minimalistische Apache V-Host Config hingepackt:

<Virtualhost *:80>
ServerName example.com
ServerAlias *.example.com
DocumentRoot /var/www/html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
</Virtualhost>

Die drei Zeilen mit „Rewrite“ würden auch problemlos in eine .htaccess-Datei im DocRoot passen. Da besteht allerdings die Gefahr, dass der Webentwickler hier die Hände im Spiel hat und es ist (wenn auch nur minimal bei kleinen Webs oder wenigen V-Hosts) performanter.

MikroTik RSA-Key Login

24.06.2017 / / Ein Kommentar

In meinem letzten Blog-Post habe ich mich mit OpenSSH (ab Version 7.0) und dem SSH-Login bei MikroTik beschäftigt, genauer gesagt mit dem DSA-Algorithmus. Dieser wurde bei OpenSSH neuerdings deaktiviert. Nachdem ich den „Workaround“ eingerichtet und geposted hatte, habe ich mich auf die Suche nach dem RSA Support in der Feature-Liste für die nächsten RouterOS Versionen gemacht. Hätte ich mal lieber im Changelog gesucht, wäre ich auch fündig geworden. Seit RouterOS 6.33 wird RSA beim SSH-Login mit 2048 Bit unterstützt. Das zum Thema „Wer lesen kann ist klar im Vorteil“ oder auch #RTFM, wobei im MikroTik Manual an entsprechender Stelle auch nur DSA erwähnt wird.
Und wenn ich schon dabei bin, teste ich doch gleich mal meinen 4096-bitigen Schlüssel, welchen ich generell für Backups schon erzeugt habe. Funktioniert zu meiner Überraschung.
Und wenn ich eh schon beim „Hardening“ angekommen bin, habe ich noch zwei optionale Parameter für RouterOS gesetzt, welche ich euch ebenfalls empfehlen würde auf dem Terminal zu setzen:

/ip ssh set host-key-size=4096 strong-crypto=yes

MikroTik: SSH Login ab Debian 9.0

24.06.2017 / / Keine Kommentare

UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.

Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:

#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done

Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:

PubkeyAcceptedKeyTypes +ssh-dss

Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:

ssh -oHostKeyAlgorithms=+ssh-dss

Quellen:
OpenSSH

mysqldump nach Wechsel auf mariadb-client sichert nicht mehr

05.06.2017 / / Keine Kommentare

Nach einem kurzfristigen Wechsel von mysql-client-5.x auf mariadb-client-10.x (via default-mysql-client) auf Debian Stretch wollte mysqldump keine Daten eines MySQL-Servers (5.1.73-1) mehr sichern:

root@backup:/backup/# mysqldump -h server1 -u backup -p -v database1
Enter password:
-- Connecting to server1...
-- MySQL dump 10.16 Distrib 10.1.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: server1 Database: database1
-- ------------------------------------------------------
-- Server version 5.1.73-1

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
-- Retrieving table structure for table table1...
-- Skipping dump data for table 'table1', it has no fields

Ursache ist das in /etc/mysql/mariadb.conf.d/50-client.cnf angegebene Character-Set utf8mb4, welches nach dem Paketwechsel standardmäßig verwendet wird und den früheren Standardwert des mysql-client-Paketes (utf8) ablöste:

[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4

Da der zu sichernde MySQL-Server utf8mb4 nicht unterstützt,  führte die Änderung von default-character-set auf utf8 zur Lösung und nun wieder vollständigen Datenbank-Backups mittels mysqldump.

Der eingangs genante Paketwechsel erwies sich also als recht tückisch, da ab diesem Zeitpunkt keine MySQL-Backups mehr erzeugt wurden, die Sicherung jedoch keinerlei Fehler aufzeigte. Das Backupskript lief erfolgreich durch und es wurden stets neue Backupfiles erzeugt, jedoch alle Tabellen beim Sichern der Inhalte übersprungen („Skipping dump data…“). Nur durch ein manuelles Prüfen der erzeugten Backupfiles fiel auf, dass das Backup nicht mehr funktionsfähig war.

macOS: Alte Netzwerkfreigaben entfernen

22.04.2017 / / Keine Kommentare

Freigaben von Dateien und Ordnern werden bei macOS in den Systemeinstellungen unter Freigaben → Dateifreigabe verwaltet. War eine Freigabe auf einer Festplatte eingerichtet, die bspw. auf Grund eines Defekts ausgetauscht wurde, wird diese Freigabe in der Übersicht nicht mehr dargestellt.

Eine neue Freigabe eines gleichnamigen Ordners kann zwar wieder eingerichtet werden, der Name der Netzwerkfreigabe wird jedoch um „-1“ ergänzt, da die ursprüngliche Freigabe im System noch vorhanden und der Name „belegt“ ist – obwohl die Freigabe eben nicht mehr in den Systemeinstellungen angezeigt wird. Der Freigabename wird bei macOS nirgends in der grafischen Oberfläche angezeigt und kann folglich auch nicht verändert werden. Dies ist besonders dann hinderlich, wenn aus dem Netzwerk auf den bisherigen Namen des Netzlaufwerk zugegriffen werden soll und Rechner, Programme oder Skripte, welche die Freigabe nutzen, nicht angepasst werden sollen.

Abhilfe schafft der Befehl sharing, welcher mit der Option -l alle im System angelegten und auch ehemaligen Freigaben anzeigt. Mit -r <name> können Freigaben entfernt werden.

Löscht man also beispielsweise eine ehemalige, verwaiste Freigabe „Daten“ mit sudo sharing -r Daten, kann anschließend in den Systemeinstellungen wieder eine Freigabe mit gleichem Namen erstellt werden.

Keine Videoausgabe bei VMWare Fusion 8.5 und macOS Sierra (10.12)

21.04.2017 / / Keine Kommentare

Nach einem Update auf die aktuellste VMWare Fusion Version kann es zu einer fehlenden/schwarzen Anzeige beim Video-Output kommen. Die VM startet und ist auch erreichbar, aber über Konsole nur „blind“ zu bedienen.

Der folgende Eintrag am Ende der zugehörigen .vmx-Datei schafft meist Abhilfe:

mks.enableGLBasicRenderer = "FALSE"

Zum editieren hilft der Link aus der KB von VMWare

Editing the .vmx file