Posts Tagged ‘SSH’

Sonntag, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

Tags: , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 3. April 2021

Ubiquiti UniFi UAP-AC-M zurücksetzen

Da heute um ungefähr 4 Uhr morgens mein Ubiquiti UniFi AP AC PRO plötzlich und ohne Vorwarnung verstorben ist (vermutlich, weil ich dessen Sendeleistung letzte Woche manuell auf High gesetzt habe …), musste ich ihn mit einem hier ungenutzt herumliegenden Ubiquiti UniFi UAP-AC-M ersetzen.

Leider klappte der Reset des noch für den vorherige Standort konfigurierten Access Points mit fünf Sekunden langem Druck auf den physischen Reset-Knopf nicht (wie im Handbuch auf Seite 7 beschrieben).

Schlussendlich loggte ich mich deshalb mittels SSH auf den Access Point ein (natürlich muss man dazu die Zugangsdaten der vorher genutzten Installation kennen, sonst hat man Pech), und führte folgenden Befehl aus:

# syswrapper.sh restore-default
Clearing CFG ... [%100] done!

Nach dem Neustart erschien der Access Point im Device Tab meines UniFi Controllers und konnte dort problemlos adoptiert werden.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Mit gehärtetem SSH-Client kann man sich nicht mehr auf UniFi-Geräte einloggen

$ ssh us-8-60w
Unable to negotiate with 10.1.2.3 port 22: no matching MAC found. Their offer: hmac-sha1

Bummer. Ich musste meine gehärtete ~/.ssh/config folgendermassen abschwächen, um mich per SSH wieder auf den Access Point einloggen zu können:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-sha1
...

Siehe auch SSH Into Ubiquiti Access Point

Die lokal verfügbaren MACs zeigt man folgendermassen an:

$ $ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 21. Februar 2018

SSH mit Benutzernamen und Passwort forcieren

Es gibt Momente, da möchte man nicht, dass der lokale ssh-agent alle vorhandenen Private Keys durchprobiert, um auf einen SSH-Server einzuloggen, sondern einem das Eingabefenster für das Passwort präsentiert.

Dies gelingt folgendermassen:

$ ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no 10.11.12.13

Via: SSH use only my password, Ignore my ssh key, don’t prompt me for a passphrase

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Normalen Benutzern den SSH-Login auf Synology DiskStations erlauben

Mit dem Synology DiskStation Manager DSM 6.0 kam es zu Sicherheitsanpassungen beim SSH-Login: Selbst wenn ein Administrator auf einem Synology NAS SSH aktiviert, können sich normale Benutzer per SSH nicht auf dem NAS einloggen. Dies ist nur mit Benutzern möglich, die der Administrator-Gruppe zugeteilt sind.

Um diese Anpassung im Namen der Sicherheit rückgängig zu machen, bin ich dem Blog-Artikel Howto: (re-)Enable SCP/SSH Login on Synology DSM 6.0 for non admin users [UPDATE] gefolgt. Der Grund ist trivial: Synology setzt für normale Benutzer in /etc/passwd ein unbrauchbares Login-Shell: /sbin/nologin

Die Lösung: Ein auf dem NAS hinterlegtes bash-Script wird mittels Cron-Job unter root laufend alle fünf Minuten ausgeführt und ersetzt die Login-Shell ausgewählter Benutzer mit /bin/sh.

/volume1/homes/admin/enable-ssh-logins.sh

#!/bin/bash
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dagobert\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^donald\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^daisy\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^huey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dewey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^louie\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd

exit 0

Cron-Job über DiskStation Manager Web-Oberfläche einrichten

  • Control Panel
  • Task Scheduler
  • Create
  • User-defined script
  • General
    • Task: „Enable Login Shell“
    • User: root
  • Schedule
    • [x] Run on the following days: Daily
    • Frequency: Every 5 minute(s)
  • Task Settings
    • Run command: User-defined script: /volume1/homes/admin/enable-ssh-logins.sh

Tags: , , , ,
Labels: Uncategorized

2 Kommentare | neuen Kommentar verfassen

Sonntag, 5. November 2017

SSH meldet „Bad SSH2 Mac spec“

Meine ~/.ssh/config habe ich gemäss den Empfehlungen von Mozilla konfiguriert.

Offenbar gab es Anpassungen am SSH-Client unter macOS, als ich zu Monatsbeginn (1. November) MacPorts aktualisiert habe.

Es waren keine Logins auf irgendwelche in config konfigurierten Server mehr möglich. Die Fehlermeldung lautete:

$ ssh sauron
/Users/mario/.ssh/config line 8: Bad SSH2 Mac spec 'hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96'.

Hmmm! Mit folgendem Befehl findet man raus, welche SSH2 Macs der SSH-Client mittlerweile nur noch unterstützt:

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Ich speicherte beide Werte in unterschiedlichen Textdateien, wobei ich die Werte aus der config von Hand auf einen Wert pro Zeile aufspaltete. Danach sortierte ich diese mit sort, um sie besser vergleichbar zu machen.

Ein Diff der beiden Listen zeigte mir schlussendlich klar auf, wo ich Hand anlegen musste:

$ diff ssh-enabled-sorted.txt ssh-available-sorted.txt 
3,4c3,4
< hmac-ripemd160
< hmac-ripemd160@openssh.com
---
> hmac-md5-96-etm@openssh.com
> hmac-md5-etm@openssh.com
6a7,8
> hmac-sha1-96-etm@openssh.com
> hmac-sha1-etm@openssh.com
12a15,16
> umac-64-etm@openssh.com
> umac-64@openssh.com

Damit konnte ich config anpassen. Vorher:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
...

Nachher (hmac-ripemd160,hmac-ripemd160@openssh.com entfernt):

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 31. August 2016

Server mit vergessenen SSH-Schlüsseln ausfindig machen

Vor einigen Tagen habe ich das Schlüsselmanagement für meine SSH-Zugänge völlig umgekrempelt.

Da ich auf Nummer sicher gehen wollte, dass ich den alten Private Key nicht auf bei mir in Vergessenheit geratenen Systemen übersehen hatte, analysierte ich in den Folgetagen die Log-Datei /var/log/auth.log auf meinem zentralen Linux-Server.

Sucht man mittels cat | grep nach „Failed“, erhält man Einträge in der folgenden Form:

...
Aug 25 22:37:09 ALPHA sshd[8539]: Failed publickey for %user% from 85.X.X.X
...

Dies ist aber nur der Beginn der Nachforschung — als nächstes muss man stark hirnen, auf welchem Server das betreffende Script laufen könnte — schliesslich gibt ssh nur eine öffentliche IP-Adresse aus (der verursachende Server steht hinter einem NAT-Router und besitzt eine private IP).

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 23. Mai 2016

Passwort eines Asus RT-AC66U per SSH zurücksetzen

Die Idee war rückblickend doch nicht so genial, das Benutzerpasswort meines Asus RT-AC66U mit Merlin-Firmware ein Sonderzeichen enthalten zu lassen.

Glücklicherweise hatte ich meinen öffentlichen SSH-Schlüssel auf dem Router hinterlegt und konnte mich so zumindest per SSH einloggen. Einmal auf der Kommandozeile, führte ich folgende Befehle aus:

# nvram show | grep http_passwd
http_passwd=?einganzlangespasswort
# nvram set http_passwd="12345678"
# nvram commit

Quelle: DD-WRT :: NVRAM

Anschliessend funktionierte der Login über die Web-Oberfläche wieder.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. April 2016

Den eigenen SSH Public Key auf einem UniFi Access Point hinterlegen

Um sich ohne Passwort auf einen UniFi Access Point einzuloggen, ist der SSH Public Key auf dem Access Point in folgender Datei zu hinterlegen:

Persistent

Folgende Anpassungen überlebt Reboots des Access Points und ist dementsprechend die einzig zuverlässige Variante ohne böse Überraschungen.

Auf dem Server, der als UniFi-Controller dient, legt man eine Datei namens config.properties an, die folgende Zeilen enthält:

config.system_cfg.1=sshd.auth.key.1.status=enabled
config.system_cfg.2=sshd.auth.key.1.value=AAA...== Beschreibung des Public Keys 1
config.system_cfg.3=sshd.auth.key.1.type=ssh-rsa

config.system_cfg.4=sshd.auth.key.2.status=enabled
config.system_cfg.5=sshd.auth.key.2.value=AAA...== Beschreibung des Public Keys 2
config.system_cfg.6=sshd.auth.key.2.type=ssh-rsa

config.system_cfg.7=sshd.auth.key.3.status=enabled
config.system_cfg.8=sshd.auth.key.3.value=AAA...== Beschreibung des Public Keys 3
config.system_cfg.9=sshd.auth.key.3.type=ssh-rsa

config.system_cfg.10=sshd.auth.key.4.status=enabled
config.system_cfg.11=sshd.auth.key.4.value=AAA...== Beschreibung des Public Keys 4
config.system_cfg.12=sshd.auth.key.4.type=ssh-rsa

Im obigen Beispiel konfiguriere ich insgesamt vier Public Keys (sshd.auth.key.1 bis sshd.auth.key.4). Wer nur einen Schlüssel hinterlegen muss, pflegt dementsprechend nur die ersten drei Zeilen in die Datei ein.

Dem Wert sshd.auth.key.1.value weist man den ganzen Public Key zu, ohne aber den Typ (bei mir ssh-rsa) zu erwähnen. Auch Anführungszeichen sind nicht nötig, wenn dem Public Key noch eine Beschreibung mit Leerschlägen folgt (ist bei mir der Fall).

Der Pfad zu dieser Datei hängt vom Betriebssystem und den im Controller definierten Site-Namen ab. Bei mir (Debian GNU/Linux, Site-Name „default“) lautet der Pfad /var/lib/unifi/sites/default/config.properties.

Die Inspiration für dieses Prozedere habe ich dem Artikel UniFi – Add Custom SSH Keys to Your UniFi Devices entnommen.

Den Site-Namen findet man mit folgender Anleitung heraus: UniFi – config.properties File Explanation. Weitere Optionen (bspw. Public Keys, die nur auf einzelne Access Points ausgerollt werden) findet man im Artikel UniFi – How to make persistent changes to UAP(s) system.cfg.

Nicht persistent

Folgende, je nach Firmware unterschiedliche Methoden, erlauben ebenfalls den passwortlosen Login. Nach dem nächsten Neustart des Access Points müssen die Schritte aber zwingend wiederholt werden — die Anpassungen sind nicht persistent.

Firmware 3.4.19

/etc/persistent/.ssh/authorized_keys

Via: ssh key based auth

Wie ich im Januar 2017 bemerken musste, konnte ich mich so nicht mehr mit meinen SSH-Schlüsseln auf die UniFi Access Points einloggen. Nach einer Stunde debuggen dann endlich die Erkenntnis:

Firmware 3.7.28.5442

/etc/dropbear/authorized_keys

Evtl. ist auch noch folgender Befehl nötig (das merke ich spätestens beim nächsten Reboot):

# cfgmtd -w -p /etc

Quelle: Unifi AP: Maintaining SSH access whilst disabling password logins (authorized_keys only) sowie Hacking the KanKun Smartplug – HowTo: Login to SSH on BusyBox (DropBear) Without a Password

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 5. Februar 2016

Einen UniFi Controller von einem Server auf einen anderen migrieren

Mit Blick auf den Mitte Januar 2016 bestellten Glasfaser-Anschluss von Fiber7 habe ich mich entschieden, das heimische WLAN aufzurüsten (nicht zuletzt, weil ich den Router wegen des Glasfaseranschlusses in der Stube nicht am selben Ort betreiben möchte wie den Wireless Access Point). Hierzu habe ich die WLAN-Funktionalität meines Asus RT-AC66U deaktiviert und mir danach einen Ubiquiti UniFi AP-Pro n450 angeschafft, mitsamt eines PoE-Switches von TP-Link.

Eine Besonderheit des UniFi-Access Points ist es, dass er selber keine Web-Oberfläche zur Konfiguration anbietet, wie es Consumer-Geräte sonst tun (auch eine Router-Funktionalität sucht man vergebens). Stattdessen benötigt man den sog. UniFi Controller, eine auf Java und MongoDB basierende Software, die auf einem Rechner im heimischen LAN installiert werden muss. Die Software muss übrigens nicht ständig laufen — wenn man die Konfiguration des APs abgeschlossen hat, benötigt der AP keine ständige Verbindung mehr zum Controller. Ich entschied mich gegen diese Lösung, da ich den Controller jederzeit zugriffsbereit und funktionstüchtig haben möchte — man weiss ja nie. Ausserdem zeichnet die Software in dem Modus Vitalparameter des APs und der WLAN-Netzwerke auf.

Zuerst hatte ich den UniFi Controller auf meiner „Workstation“, einem Mac mini, installiert, welcher ständig läuft. Da mir dabei nie wirklich wohl war, entschied ich mich, den alten Raspberry Pi 1 auszugraben und den Controller darauf zu installieren. Das ist insofern etwas weniger trivial als bei einem x86-Server, weil die ARM-CPU andere Softwarepakete benötigt (insbesondere MongoDB). Ich habe es dank Anleitungen im Internet trotzdem hingekriegt (das Material wird dereinst zu einem eigenständigen Blog-Artikel verwurstet). Da ich anschliessend auch Smokeping auf dem Raspberry Pi installierte und mir die Performance zur Generierung der RRDtool-Graphen überhaupt nicht mehr reichte, entschied ich mich diese Woche, auf einen (gebrauchten) Intel Next Unit of Computing NUC DC3217IYE zu migrieren. Mitkommen sollte auch der UniFi Controller.

Da ich das Spielchen bereits einmal gemacht hatte, hier die im Grunde recht triviale Anleitung (Kurzfassung):

  1. In den alten UniFi-Controller einloggen und unter Settings > Maintenance > Backup > Download Backup ein aktuelles Backup herunterladen
  2. Den neuen UniFi-Controller auf dem neuen Server installieren (Anleitungen für Raspberry Pi und Debian folgen dereinst)
  3. Mit dem Browser auf den neuen UniFi-Controller verbinden
  4. Auf dem Homescreen des neuen UniFi-Controllers im Abschnitt „Alternatively you can restore from a previous backup“ die soeben generierte Backup-Datei auf „Choose File“ ablegen und warten (auf dem Raspberry Pi dauerte das Einlesen des Backups mehrere Minuten, unter dem NUC wenige Sekunden)
  5. Login auf den neuen UniFi-Controller — WLAN sollte Rot leuchten
  6. Login auf den Server des alten UniFi-Controllers und diesen Controller stoppen (service stop unifi)

UniFi Controller Import Backup
image-6517

Soweit so gut. Als nächstes muss man sich per SSH auf den Access Point verbinden — bei mir völlig ohne Interaktion, da ich den Access Point mit meinem SSH Public Key ausgestattet habe:

$ ssh unifi

Anschliessend startet man das CLI des lokalen Management Utility:

# mca-cli

Dort gibt man folgenden Befehl ein:

$ set-inform http://10.0.1.12:8080/inform

Wechselt man nun in den Browser zur Web-Oberfläche des neuen UniFi-Controllers, leuchtet WLAN grün — der Access Point wurde in der Zwischenzeit erkannt.

Voila, that’s it!

PS Eins: In Anleitungen im Netz liest man gelegentlich, dass man den AP im Web-GUI noch „adoptieren“ und danach noch einmal den set-inform-Befehl ausführen müsse — bei mir klappte dies auch ohne.

PS Zwei: Der alte UniFi-Controller lief unter 4.7.6, der neue läuft unter 4.8.12. Beim Import der Backup-Konfiguration gab es keine Probleme.

Tags: , , , , , , , ,
Labels: IT

5 Kommentare | neuen Kommentar verfassen