Posts Tagged ‘UniFi’

Montag, 20. März 2017

UniFi Controller erkennen automatisch unerlaubte WiFi Access Points

Als ich gestern mit meinem TP-LINK TL-MR3020 am herumspielen war, tauchte plötzlich folgende E-Mail-Nachricht in meiner INBOX auf:

image-7226

Ein Feature, von dem ich nicht wusste, dass es existiert. Nett. Umkehrschluss: Da der UniFi Controller das erste Mal ausgeschlagen hat, hatte ich noch nie einen „Rogue Access Point“ im Netz.

PS: Und ja, bevor jemand fragt: Die Konfigurationsoption für den Domain-Namen des Systems habe ich mittlerweile auch entdeckt und der Realität angepasst …

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Januar 2017

Wenn Laien Entwicklunsgzeiten schätzen …

Wenn der Vollprofi sagt, dass die Entwicklung eines Features mit einer externen Schnittstelle 10 Personentage in Anspruch nimmt, muss es ja wohl stimmen …

SMS password for Guest Portal
Is a great idea , fast release this!
I think new guest authentication perfect , and give up sales unifi in the air!
Its a week job and week test … realy need unifi wifi.

by worksart
on ‎09-15-2015 12:38 AM

Quelle: SMS password for Guest Portal

Tags: , , , ,
Labels: Funny, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 13. November 2016

UniFi Access Points mittels IKEA-Hack in der Wohnung platzieren

Zur selben Zeit, als ich Brandmelder angeschafft habe und mir am Überlegen war, wie man diese Sensoren ohne Beschädigung der Decken in der Wohnung platzieren kann, habe ich mir auch zwei UniFi Access Point angeschafft.

Der IKEA-Hack mit den Variera Tellerhaltern für die Montage der Brandmelder liess sich 1:1 auch auf die Access Points übertragen, da IKEA Tellerhalter in zwei Grössen im Angebot führt (die UniFis hätten rein vom Durchmesser überhaupt nicht in die Brandmelder-Halterung gepasst). Für UniFi Access Points eignet sich das grössere der beiden Modelle, das Teller in der Grösse von 19cm bis 32cm aufnimmt:

VARIERA Tellerhalter, Buche hell, Edelstahl (IKEA Artikelnummer 802.404.16; 9.95 CHF)

Wieso dieser Aufwand? UniFi Access Points senden ihre Signale in Form eines „Donuts“ aus, wenn der Access Point horizontal aufliegt. Der „Donut“ ist aus der horizontalen Sicht aber nicht symmetrisch: Auf der Deckenseite des Access Point mit der Zuführung des Ethernet-Kabels ist die Abstrahlung weniger wulstig als auf der Luftseite (dort, wo das Logo prangt und die blaue LED leuchtet):

unifi-access-point-donut-horizontal
image-7049

NACHTRAG: Unter Antenna radiation pattern for UniFi AP (diagramm inside) habe ich weitere Diagramme gefunden:

unifi-horizontal-polarization-mounted-wall
image-7050

unifi-horizontal-polarization-mounted-roof
image-7051

unifi-vertical-polarization-mounted-wall
image-7052

unifi-vertical-polarization-mounted-roof
image-7053

Quelle: [Ervaringen/discussie] Ubiquiti-apparatuur

Dies ist einfach erklärbar: Die Macher der semi-professionellen Access Points gehen davon aus, dass die Dinger in der Regel an Decken montiert werden. Richtung Decke selber bringt eine WiFi-Durchdringung niemandem etwas, aber von der Decke weg (Richtung Zimmerboden) muss eine möglichst grosse Abdeckung erreicht werden.

Aus diesem Grund habe ich beide Access Points auf dem Tellerhalter montiert und in der Stube sowie im Büro möglichst an hoher Position aufgestellt. Das sieht dann so aus:

UniFi Access Point IKEA Variera Mount Living Room
image-7054

Tags: , , , , , , , , , ,
Labels: Uncategorized

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

UniFi Controller unter Debian installieren

Dank den .deb-Paketen, welche der Hersteller zur Verfügung stellt, eine Sache von wenigen Minuten.

/etc/apt/sources.list

Hier fügt man folgende Zeile ein:

...
deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti

Quelle: Updated UniFi Repo info/APT howto

Aktualisierung: stable mit unifi5 ersetzt (Juni 2016; Dank an Joachim, siehe Kommentar unten)

apt-get

Als erstes liest man die Paketlisten neu ein:

# apt-get update

Sollte es zu Probleme mit dem GPG-Schlüssel kommen, könnten folgende Befehle helfen:

# apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50
# apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10

Anschliessend installiert man das Paket:

# apt-get install unifi
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
 binutils ca-certificates-java default-jre-headless java-common jsvc libasyncns0 libboost-filesystem1.55.0 libboost-program-options1.55.0
 libboost-system1.55.0 libboost-thread1.55.0 libcommons-daemon-java libflac8 libgoogle-perftools4 libice6 libnspr4 libnss3 libogg0
 libpcrecpp0 libpcsclite1 libpulse0 libsctp1 libsm6 libsnappy1 libsndfile1 libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libvorbis0a
 libvorbisenc2 libx11-xcb1 libxtst6 lksctp-tools mongodb-clients mongodb-server openjdk-7-jre-headless tzdata-java x11-common
Suggested packages:
 binutils-doc default-jre equivs java-virtual-machine pcscd pulseaudio icedtea-7-jre-jamvm libnss-mdns sun-java6-fonts fonts-dejavu-extra
 fonts-ipafont-gothic fonts-ipafont-mincho ttf-wqy-microhei ttf-wqy-zenhei fonts-indic
The following NEW packages will be installed:
 binutils ca-certificates-java default-jre-headless java-common jsvc libasyncns0 libboost-filesystem1.55.0 libboost-program-options1.55.0
 libboost-system1.55.0 libboost-thread1.55.0 libcommons-daemon-java libflac8 libgoogle-perftools4 libice6 libnspr4 libnss3 libogg0
 libpcrecpp0 libpcsclite1 libpulse0 libsctp1 libsm6 libsnappy1 libsndfile1 libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libvorbis0a
 libvorbisenc2 libx11-xcb1 libxtst6 lksctp-tools mongodb-clients mongodb-server openjdk-7-jre-headless tzdata-java unifi x11-common
0 upgraded, 38 newly installed, 0 to remove and 5 not upgraded.
Need to get 305 MB of archives.
After this operation, 467 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Fertig!

UniFi Controller

Den Controller öffnet man nun, indem man folgende URL aufruft:

  • localhost:8443 (auf dem Server selber, aber wer von euch betreibt einen Linux-Server schon mit einem GUI?)
  • 192.168.44.44:8443 (oder welche IP der UniFi-Controller auch immer im heimischen LAN erhalten hat)

Nachtrag

Die PDF-Anleitung „Install and configure a Debian based UniFi controller“ findet sich bei einer Google-Suche zuoberst, sie ist aber veraltet. Insbesondere der Hinweis auf folgende Paketquelle funktionierte bei mir nicht mehr:

deb http://www.ubnt.com/downloads/unifi/distros/deb/debian debian ubiquiti

Die Fehlermeldung lautete:

W: Failed to fetch http://dl.ubnt.com/unifi/distros/deb/debian/dists/debian/ubiquiti/binary-amd64/Packages 404 Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

Tags: , ,
Labels: Linux

6 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

1 Kommentar | neuen Kommentar verfassen