nubecula.org https://blog.nubecula.org Blog Fri, 31 May 2019 11:55:15 +0000 de-DE hourly 1 https://wordpress.org/?v=5.3.2 https://blog.nubecula.org/wp-content/uploads/2018/10/cropped-icon-32x32.png nubecula.org https://blog.nubecula.org 32 32 Gitea Commits mit OpenPGP Key signieren https://blog.nubecula.org/index.php/2019/05/31/gitea-commits-mit-opengpg-key-signieren/ https://blog.nubecula.org/index.php/2019/05/31/gitea-commits-mit-opengpg-key-signieren/#comments Fri, 31 May 2019 11:54:23 +0000 https://blog.nubecula.org/?p=585 In diesem Tutorial beschreibe ich euch, wie Ihr mit Gitea Commits mit einem OpenPGP Key signieren könnt. Damit könnt Ihr einfach bestätigen, dass Ihr wirklich der Urheber seit. Das Commit wird dann auch entsprechend in...

Der Beitrag Gitea Commits mit OpenPGP Key signieren erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial beschreibe ich euch, wie Ihr mit Gitea Commits mit einem OpenPGP Key signieren könnt. Damit könnt Ihr einfach bestätigen, dass Ihr wirklich der Urheber seit. Das Commit wird dann auch entsprechend in Gitea als signiert angezeigt.

Ich gehe jetzt mal davon aus, dass Ihr bereits ein OpenPGP Key erzeugt habt. Ansonst könnt Ihr im Netz nach einer Anleitung suchen, oder euch das Notwendige aus meinem Tutorial zum Nitrokey Pro 2 herausholen.

Ebenso setze ich voraus, dass Ihr eine Gitea Instanz laufen habt. Eine Anleitung hierfür gibt es hier.

OpenPGP Public Schlüssel ermitteln

In der Konsole können wir mit folgendem Befehl die vorhanden Key anzeigen lassen:

gpg --keyid-format long --list-keys

Das sollte euch alle vorhanden Schlüsseln anzeigen:

pub   rsa2048/AA10842DB9E8432A 2019-05-29 [SC]
      BF63605C4D5AF4F03D2E05CDAA10842DB9E8432A
uid              [ ultimativ ] Hans Wurst <hans.wurst@example.org>
sub   rsa2048/FAE183B64746EEEE 2019-05-29 [E]

Kopiert euch die KeyID, in meinem Fall wäre das „AA10842DB9E8432A„. Nun geben wir mit folgendem Befehl den Public Key aus, wobei Ihr eure KeyID eintragen müsst:

gpg --armor --export AA10842DB9E8432A

Nun Kopiert man sich die Ausgabe komplett und geht in Gitea in die Benutzereinstellungen unter „SSH- / GPG Schlüssel“. Dort fügt man einen neuen GPG Schlüssel hinzu und kopiert den eben ausgegebene Publiy Key in das entsprechende Feld. Auf Gitea Seite sind wir damit nun fertig.

GIT konfigurieren

Damit GIT die Commits signiert müssen wir ein paar Einstellungen auf dem Benutzersystem machen. Mit folgendem Befehl könnt Ihr GIT mittelen, welcher Key benutzt werden soll:

git config --global user.signingkey AA10842DB9E8432A

Hier ist auch wieder eure KeyID zu einzusetzen. Wenn man automatisch alle Commits signieren will muss man noch folgenden Befehl ausführen:

git config --global commit.gpgsign true

Und zuletzt noch:

echo 'export GPG_TTY=$(tty)' >> ~/.profile

Nun kann man Commits anfangen zu signieren (wenn nicht automatisch):

git commit -S -m TEXT
git push

Wenn alles funktioniert hat sollte Ihr in der Gitea Weboberfläche das Commit als signiert sehen.

Signiertes Commit

Abschluss

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag Gitea Commits mit OpenPGP Key signieren erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/05/31/gitea-commits-mit-opengpg-key-signieren/feed/ 1
Gitea auf einem Linux Server installieren https://blog.nubecula.org/index.php/2019/05/31/gitea-auf-einem-linux-server-installieren/ https://blog.nubecula.org/index.php/2019/05/31/gitea-auf-einem-linux-server-installieren/#respond Fri, 31 May 2019 11:02:32 +0000 https://blog.nubecula.org/?p=562 In diesem Tutorial erkläre ich euch wie Ihr Gitea auf einem Linux Server installieren könnt. Gitea ist eine in GO geschriebene Anwendung die versucht die gesamte Funktionalität von Github nachzubilden. Die Übernahme von Githubdurch Microsoft...

Der Beitrag Gitea auf einem Linux Server installieren erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial erkläre ich euch wie Ihr Gitea auf einem Linux Server installieren könnt. Gitea ist eine in GO geschriebene Anwendung die versucht die gesamte Funktionalität von Github nachzubilden. Die Übernahme von Githubdurch Microsoft veranlasste bei mir eine Suche nach Alternative. Dabei schien mir Gitea als die perfekte Lösung, um nicht auf Drittanbieter angewiesen zu sein.

Die Installation in diesem Tutorial erfolgte unter Ubuntu 18.04. LTS sollte aber auf jeder Distribution genau so funktionieren. Zum Zeitpunkt der Erstellung dieses Tutorials habe ich Gitea in der Version 1.8.2 benutzt.

System vorbereiten

Nun beginnen wir mit der Vorbereitung unseres System für die Benutzung von Gitea. Zuallererst sollten wir natürlich dafür Sorge tragen, dass GIT installiert ist.

sudo apt-get install git

Als nächstes legen wir einen Benutzer „git“ an, unter dem später Gitea ausgeführt wird.

sudo useradd -m -s /bin/bash git

Für diejenigen, die es nicht wissen; der Parameter „-m“ sorgt dafür das ein „home“ Verzeichnis für den Benutzer angelegt wird. Die ganzen Repositorien will ich später dort ablegen. Ein Passwort wird nicht vergeben, da wir kein Login haben wollen.

Nun erzeugen wir alle notwendigen Verzeichnisse und ändern die entsprechenden Berechtigungen.

sudo mkdir /etc/gitea
sudo chown -R git:git /etc/gitea
sudo mkdir /var/lib/gitea
sudo chwon -R git:git /var/lib/gitea

Gitea installieren

Als nächstes werden wir Gitea installieren, welches aktuell nicht in den Paketquellen ist. Die Installation werde ich im Verzeichnis „/opt“ machen. Das könnt Ihr natürlich an beliebiger stelle machen, nur müsst Ihr dann den Pfad im Laufe des Tutorials mit eurem ersetzen.

sudo mkdir /opt/gitea
sudo chown -R git:git /opt/gitea
cd /opt/gitea
sudo su git

Nun sollten wir uns im richtigen Verzeichnis befinden und als Benutzer „git“ unterwegs sein.

Als nächste laden wir uns hier die aktuelle Version von Gitea herunter und machen die Datei ausführbar und erzeugen einen Link.

wget https://dl.gitea.io/gitea/1.8.2/gitea-1.8.2-linux-amd64
chmod +x gitea-1.8.2-linux-amd64
ln -s gitea-1.8.2-linux-amd64 gitea

In meinem Fall ist das die Version für AMD64 Systeme. Ihr müsst natürlich das richtige Paket für euer System auswählen. Bei einem Update müsst ihr dann einfach die neue Version herunterladen, ausführbar machen und den Link neu erstellen. Den Link brauchen wir für das Start-Script.

Damit ist erst einmal die Installation von Gitea abgeschlossen, die Einrichtung erfolgt später in diesem Tutorial.

Gitea mit dem Systemstart starten

Nun müssen wir uns um die Start von Gitea kümmern. Da Ubuntu Systemd benutzt erstellen wir und einfach einen Service. Wir erzeugen uns die Datei „/etc/systemd/system/gitea.service“ mit folgendem Inhalt:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
Requires=mysql.service
#Requires=mariadb.service
#Requires=postgresql.service
#Requires=memcached.service
#Requires=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/opt/gitea/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Solltet Ihr euch bis hierin nicht an die gleichen Pfade und Benutzernamen gehalten haben, solltet Ihr in der Datei natürlich die Angaben entsprechend anpassen.

Nun aktivieren wir den Service und starten Gitea:

sudo systemctl enable gitea
sudo systemctl start gitea

(Optional) Datenbank erstellen

Gitea unterstützt verschiedene Datenbanksysteme wie MySQL, PostgreSQL und MSSQL. Wer nur eine kleine Installation plant, der kann auch auf eine SQLite3 Datenbank benutzen. In diesem Fall kann man direkt mit der Konfiguration von Gitea loslegen.

Wer größeres plant, oder einfach eine der genannten Datenbanken nutzen möchte, sollte sich nun einen Datenbankbenutzer und die Datenbank selbst erzeugen. Die Schritte hierfür sollen kein Bestandteil dieses Tutorials sein. Hierfür gibt es genug Anleitungen im Netz.

Je nachdem für welche Datenbank entschieden hat, sollte man im obigen Startscript die entsprechende Datenbank aktivieren z.B. „Requires=mysql.service“. Einfach die Zeile ein/auskommentieren. Damit wartet Gitea beim Start auf die Datenbank.

Gitea konfigurieren

Sobald Gitea gestartet wurde, kann man im Browser auf die Instanz zugreifen z.B. „http://localhost:3000„. Port 3000 ist der Standard Port von Gitea, den man natürlich ändern kann.

Sobald man auf der Gitea Seite ist, klickt man oben rechts auf „Anmelden“ und man kommt direkt in die Installationsroutine. Hier spare ich mir einen Screenshot. Das ganze sollte selbsterklärend sein. Bei Datenbank wählt man die gewünschte aus und trägt alle Daten ein.
Im letzten Punkt muss man noch einen Administrator Account anlegen. Der Rest kann man auch später über die Datei „/etc/gitea/app.ini“ anpassen.

Sobald man alles konfiguriert hat, werden die notwendigen Tabellen in den Datenbanken erzeugt und die Konfigurationsdatei wird erzeugt. Danach befindet man sich als Administrator auf der Weboberfläche.
Die grundlegende Einrichtung von Gitea ist damit abgeschlossen.

Im Nachgang sollte man sich aber noch um das Fine-Tuning kümmern, was aber kein Bestandteil dieses Tutorials sein soll.

(Optional) SSH Zugriff auf Repositories

Um per SSH auf die Repositories Zugriff zu bekommen muss natürlich SSH in Gitea aktiviert werden. Das geschieht in der Datei „/etc/gitea/app.ini“.
Der Einfachheit halber ein Auszug aus meiner Konfiguration:

[server]
SSH_DOMAIN       = example.org
DOMAIN           = example.org
HTTP_PORT        = 3000
ROOT_URL         = http://example.org:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = false
OFFLINE_MODE     = false

Danach sollte man Gitea neu starten, damit die Änderungen aktiv werden.
Ein sehr wichtiger Punkt ist, dass man die SSH Schlüssel ausschließlich über die Gitea Weboberfläche hinzufügen darf. Das geht einfach in den Einstellungen des Benutzers.

Ein „ssh-copy-id“ und sonstiges helfen nicht weiter und führen nur zum nicht funktionieren von der SSH Verbindung. Man muss unbedingt kontrollieren, das die Datein „/home/git/.ssh/authorized_keys“ leer ist, bevor man anfängt mit dem Hinzufügen von SSH Schlüsseln.

(Optional) Gitea SSL Verbindung über Apache Reverse Proxy

Die Weboberfläche läuft aktuell nur im „HTTP“ Modus, was ja nicht mehr zeitgemäß ist. Ich habe auf meinem Server eine Subdomain für Gitea erzeugt und mit einem Let’s Encrypt Zertifikat versehen. Zusätzlich habe ich eine Zwangsumleitung auf „HTTPS“ gemacht.
Auf die Details möchte ich hier nicht eingehen, da es genügen Anleitungen im Netz dafür gibt.

In Apache müssen die Module „proxy“ und „proxy_http“ aktiviert sein. Wichtig sind folgende Einträge in der Konfiguration der Domain in Apache:

ProxyPreserveHost On
ProxyRequests off
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/

Apache neu durchstarten und dann müssen wir noch in der Konfigurationsdatei von Gitea „/etc/gitea/app.ini“ den Domainnamen ändern:

[server]
ROOT_URL         = http://git.example.org/
HTTP_ADDR        = 127.0.0.1

Es reicht die Anpassung der „ROOT_URL“. Die sorgt dafür das die Links zu den Repositories richtig angezeigt werden. Zusätzlich habe ich den Parameter „HTTP_ADDR“ hinzugefügt und den Localhost reingeschrieben.
Somit ist Gitea nur noch über die erzeugte Subdomain zu erreichen z.B. „http://git.example.org“ und nicht mehr über „http://example.org:3000“.
Somit zwinge ich jeden eine verschlüsselte Verbindung zu benutzen.

Abschluss

Das waren nun alle notwendigen Schritte um Gitea auf einem Linux Server zu installieren. In weiteren Tutorials werde ich auf die Konfiguration von Gitea eingehen:

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag Gitea auf einem Linux Server installieren erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/05/31/gitea-auf-einem-linux-server-installieren/feed/ 0
SSH Login mit Nitrokey Pro 2 unter Linux https://blog.nubecula.org/index.php/2019/05/19/ssh-login-mit-nitrokey-pro-2/ https://blog.nubecula.org/index.php/2019/05/19/ssh-login-mit-nitrokey-pro-2/#respond Sun, 19 May 2019 14:33:42 +0000 https://blog.nubecula.org/?p=559 In diesem Tutorial beschreibe ich euch, wie Ihr einen SSH Login mit dem Nitrokey Pro 2 hinbekommt. Voraussetzung ist, dass Ihr bereits OpenPGP Schlüssel auf dem Nitrokey Pro 2 erzeugt habt. Eine Anleitung hierfür findet...

Der Beitrag SSH Login mit Nitrokey Pro 2 unter Linux erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial beschreibe ich euch, wie Ihr einen SSH Login mit dem Nitrokey Pro 2 hinbekommt. Voraussetzung ist, dass Ihr bereits OpenPGP Schlüssel auf dem Nitrokey Pro 2 erzeugt habt. Eine Anleitung hierfür findet Ihr hier.

Die Einrichtung habe ich auf einem Desktop / Server mit Gentoo Linux gemacht. Prinzipiell sollte das Ganze aber mit jeglicher Distribution funktionieren. Den Gentoo spezifischen Kram werden ich entsprechend markieren.

Voraussetzungen

Einrichtung OpenPGP Schlüssel als SSH Key

Sind auf dem Nitrokey Pro 2 die OpenPGP Schlüssel eingerichtet muss man in der Konsole (Benutzer / Client) den Schlüssel zu SSH hinzufügen. Die geschieht mit dem Kommando:

ssh-add

Mit dem folgenden Befehl könnt ihr kontrollieren, ob der Schlüssel benutzt wird:

ssh-add -l

Der Output sollte dann in etwa so aussehen:

2048 SHA256:1Ttk8NzJ4BTr9xUqCI2y91ZFUQfUGvWuDpkPMn/JN9k cardno:000500001234 (RSA)

Diesen Schlüssel müssen wir nun in die „authorized_keys“ Datei auf dem SSH Server platzieren. Das geht am einfachsten mit:

ssh-copy-id username@server

„Username“ und „server“ müsst Ihr natürlich mit euren Daten ersetzen! Danach sollte der Key auf dem Server in der Datei vorhanden sein.

GPG Agent einrichten

Damit der ganze Zauber funktioniert müssen wir nun noch in der Datei „~/.gnupg/gpg.conf“ folgendes einfügen:

use-agent

Wenn die Datei nicht vorhanden ist, erzeugt diese einfach. Als nächstes müssen wir die Datei „~/.gnupg/gpg-agent.conf“ editieren. Fügt Folgendes hinzu:

enable-ssh-support

In der Datei ~/.bashrc fügen wir Folgendes hinzu:

unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi

Nun startet am besten euren Rechner neu durch, damit alle Einstellungen übernommen werden. Sobald das geschehen ist, könnt Ihr versuchen auch auf dem SSH Server einzuloggen.

Sollte beim Einloggen dennoch ein Passwort abgefragt werden (nicht PIN), läuft vermutlich der GPG Agent nicht, das war zumindest bei mir der Fall. Ihr könnt ihn mit diesem Befehl starten:

 gpg-connect-agent updatestartuptty /bye

Damit ist der unvierselle Teil des Tutorials vorbei. Im Anschluss erkläre ich noch, wie ich das ganze unter Gentoo optimiert habe.

Pinentry für SSH Login einrichten

Um GnuPG mit Pinentry zu benutzen muss man Folgendes in die Datei „~/.gnupg/gpg-agent.conf“ hinzufügen:

pinentry-program /usr/bin/pinentry
no-grab
default-cache-ttl 1800

Pinentry sorgt für die PIN Abfrage und kann in verschieden Modi betrieben werden (GUI / Konsole). Die verfügbaren Modi bekommt man mit dem Befehl (als „root“):

eselect pinentry list

Standardmäßig sollte „pinentry-curses“ ausgewählt sein. Mit dem folgenden Befehl könnt ihr das ändern z.B.:

eselect pinentry set pinentry-qt

Zu guter Letzt fügen wir noch folgende Zeilen in die Datei „~/.bashrc“ des Benutzers:

export GPG_TTY=$(tty)
if [[ -n "$SSH_CONNECTION" ]] ;then
    export PINENTRY_USER_DATA="USE_CURSES=1"
fi

Auch hier ist ein Rechnerneustart ratsam. Alternativ einmal kurz in der Konsole aus- und einloggen sollte auch funktionieren. Nun sollte die entsprechende Abfrage bei einer PIN Eingabe kommen.

GPG Agent Start mit KDE 5 automatisieren

Wie bereit erwähnt startet der GPG Agent nicht automatisch beim Systemstart. Der Agent muss auch für jeden spezifischen Nutzer mit entsprechenden Rechten gestartet werden.

In meinem Fall benutze ich KDE 5. Um den Agent automatisiert zu starten editieren wir die Datei „/etc/plasma/startup/10-agent-startup.sh“. Die Datei sollte danach in etwa so aussehen:

GPG_AGENT=true
SSH_AGENT=true
SSH_AGENT=gpg # use gpg-agent for ssh instead of ssh-agent

if [ "${GPG_AGENT}" = true ]; then
        if [ -x /usr/bin/gpgconf ]; then
                gpgconf --launch gpg-agent >/dev/null 2>&1
                if [ $? = 2 ]; then
                        eval "$(/usr/bin/gpg-agent --enable-ssh-support --daemon)"
                fi
        fi
fi

if [ "${SSH_AGENT}" = true ]; then
        if [ -x /usr/bin/ssh-agent ]; then
                eval "$(/usr/bin/ssh-agent -s)"
        fi
elif [ "${SSH_AGENT}" = gpg ] && [ "${GPG_AGENT}" = true ]; then
        if [ -e /run/user/$(id -ru)/gnupg/S.gpg-agent.ssh ]; then
                export SSH_AUTH_SOCK=/run/user/$(id -ru)/gnupg/S.gpg-agent.ssh
        elif [ -e "${HOME}/.gnupg/S.gpg-agent.ssh" ]; then
                export SSH_AUTH_SOCK=${HOME}/.gnupg/S.gpg-agent.ssh
        fi
fi

Zum automatisierten Beenden editieren wir die Datei „/etc/plasma/shutdown/10-agent-shutdown.sh“

# gnupg 2.0.x
#if [ -n "${GPG_AGENT_INFO}" ]; then
#       kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) >/dev/null 2>&1
#fi

# gnupg 2.1.x
gpgconf --kill gpg-agent >/dev/null 2>&1

if [ -n "${SSH_AGENT_PID}" ]; then
        eval "$(ssh-agent -s -k)"
fi

Nun sollte der Agent nach einem Neustart des Systems automatisch starten.

Abschluss

Damit sollte nun eine einloggen auf einen SSH Server mit dem Nitrokey Pro 2 möglich sein.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag SSH Login mit Nitrokey Pro 2 unter Linux erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/05/19/ssh-login-mit-nitrokey-pro-2/feed/ 0
Nitrokey Pro 2 unter Gentoo einrichten https://blog.nubecula.org/index.php/2019/05/19/nitrokey-pro-2-unter-gentoo-einrichten/ https://blog.nubecula.org/index.php/2019/05/19/nitrokey-pro-2-unter-gentoo-einrichten/#respond Sun, 19 May 2019 09:44:19 +0000 https://blog.nubecula.org/?p=536 In diesem Tutorial beschreibe ich euch alle notwendigen Schritte für die Einrichtung des Nitrokey Pro 2 unter Gentoo Linux. Nitrokey App installieren Die Nitrokey App dient der Konfiguration des Nitrokeys. Diese ist in Portage enthalten...

Der Beitrag Nitrokey Pro 2 unter Gentoo einrichten erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial beschreibe ich euch alle notwendigen Schritte für die Einrichtung des Nitrokey Pro 2 unter Gentoo Linux.

Nitrokey App installieren

Die Nitrokey App dient der Konfiguration des Nitrokeys. Diese ist in Portage enthalten (Stand 05/2019) und kann einfach installiert werden.

emerge -a app-crypt/nitrokey-app

UDEV Rules anlegen

Damit der Nitrokey Pro 2 richtig erkannt wird muss noch eine UDEV Rule angelegt werden. Erzeugt die Datei „/etc/udev/rules.d/41-nitrokey.rules“ mit folgendem Inhalt:

#
# Copyright (c) 2015-2019 Nitrokey UG
#
# This file is part of libnitrokey.
#
# libnitrokey is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# any later version.
#
# libnitrokey is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with libnitrokey. If not, see <http://www.gnu.org/licenses/>.
#
# SPDX-License-Identifier: LGPL-3.0
#

# Here rules in new style should be provided. Matching devices should be tagged with 'uaccess'.
# File prefix number should be lower than 73, to be correctly processed by the Udev.
# Recommended udev version: >= 188.
#
ACTION!="add|change", GOTO="u2f_end"

# Nitrokey U2F
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", TAG+="uaccess"
# Nitrokey FIDO U2F
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="20a0", ATTRS{idProduct}=="4287", TAG+="uaccess"

LABEL="u2f_end"


SUBSYSTEM!="usb", GOTO="gnupg_rules_end"
ACTION!="add", GOTO="gnupg_rules_end"

# USB SmartCard Readers
## Crypto Stick 1.2
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4107", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", TAG+="uaccess"
## Nitrokey Pro
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4108", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", TAG+="uaccess"
## Nitrokey Storage
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4109", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", TAG+="uaccess"
## Nitrokey Start
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4211", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", TAG+="uaccess"
## Nitrokey HSM
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4230", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", TAG+="uaccess"

LABEL="gnupg_rules_end"


# Nitrokey Storage dev Entry
KERNEL=="sd?1", ATTRS{idVendor}=="20a0", ATTRS{idProduct}=="4109", SYMLINK+="nitrospace"

Nun müssen wir nur noch UDEV neu starten:

/etc/init.d/udev restart

Abschluss

Ich plane zukünftig weitere Tutorials zu verfassen, die sich mit der Verwendung des Nitrokey Pro2 beschäftigen. Aktuell sind folgende Tutorials vorhanden:

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag Nitrokey Pro 2 unter Gentoo einrichten erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/05/19/nitrokey-pro-2-unter-gentoo-einrichten/feed/ 0
OpenPGP Schlüssel auf Nitrokey Pro 2 erzeugen https://blog.nubecula.org/index.php/2019/05/19/openpgp-schluessel-auf-nitrokey-pro-2-erzeugen/ https://blog.nubecula.org/index.php/2019/05/19/openpgp-schluessel-auf-nitrokey-pro-2-erzeugen/#respond Sun, 19 May 2019 09:43:56 +0000 https://blog.nubecula.org/?p=541 In diesem Tutorial erkläre ich euch, wie Ihr auf dem Nitrokey Pro 2 einen OpenPGP Schlüssel mit GnuPG (Version 2.2.15) erzeugt. Voraussetzung für dieses Tutorial ist, dass Ihr schon die Nitrokey App installiert habt.Eine Anleitung,...

Der Beitrag OpenPGP Schlüssel auf Nitrokey Pro 2 erzeugen erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial erkläre ich euch, wie Ihr auf dem Nitrokey Pro 2 einen OpenPGP Schlüssel mit GnuPG (Version 2.2.15) erzeugt. Voraussetzung für dieses Tutorial ist, dass Ihr schon die Nitrokey App installiert habt.
Eine Anleitung, wie Ihr das unter Gentoo macht findet Ihr hier.

Vorbereitung

Der Nitrokey Pro 2 funktioniert in Verbindung mit GnuPG wie eine Samrtcard, er ist quasi eine. Um zu überprüfen ob der Zugriff auf diese gegeben ist geben wir als Normaler Nutzer (Besitzer Nitrokey) in der Konsole folgendes ein:

gpg2 --card-status

Ist der Nitrokey verfügbar sollte eine Ausgabe wie folgt erfolgen:

Reader ...........: 20A0:4108:000000000000000000001234:0
Application ID ...: D1234567890123456789012345678901
Version ..........: 3.3
Manufacturer .....: ZeitControl
Serial number ....: 00001234
Name of cardholder: [nicht gesetzt]
Language prefs ...: de
Sex ..............: unbestimmt
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 64 64 64
PIN retry counter : 3 0 3
Signature counter : 0
KDF setting ......: on
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Sollte folgende Fehlermeldung auftauchen, kontrolliert ob der Nitrokey überhaupt eingesteckt ist oder ob die UDEV Rules richtig eingerichtet sind.

gpg: selecting openpgp failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Nitrokey / Smartcard personalisieren

Als nächstes personalisieren wir den Nitrokey. Wie wir bereits im Karten Status gesehen haben ist z.B. der „Kartenhalter“ nicht eingetragen. Um die Daten zu ändern geben wir folgendes in der Konsole ein:

gpg2 --card-edit

Nun sollten wieder die Karteninformationen auftauchen die wir zuvor gesehen haben und es ist ein neuer Command Prompt verfügbar (gpg/card>). Um jetzt ein Parameter wie den Namen des Kartenhalters gibt man nun folgende Befehle ein:

admin
name

Danach sollte man nach den notwendigen Daten gefragt werden, die man dann einfach eintippt. Beim ersten Editieren wird man nach dem Admin PIN gefragt. Mit den Befehl „admin -> help“ bekommt man eine Liste aller möglichen Befehle. Ich habe noch zusätzlich das Geschlecht angegeben. Hier sollten man darüber hinwegsehen, dass es zumindest für Deutschland keine komplett politisch korrekte Auswahlmöglichkeit gibt.

Meine Daten sehen nun wie folgt aus:

...
Name of cardholder: Max Mustermann
Language prefs ...: de
Sex ..............: männlich
...

OpenPGP Schlüssel erzeugen

Nun geht es daran die OpenPGP Schlüssel auf dem Nitrokey zu erzeugen.
In diesem Tutorial benutze ich die Standardeinstellungen die von GnuPG vorgeschlagen werden. Diese kann man natürlich anpassen, das sollte aber kein Teil dieses Tutorials sein.

Wir starten die Schlüsselgenerierung in der GPG Konsole (gpg2 –card-edit):

admin
generate

Nun werden wir Schritt für Schritt durch den Prozess geleitet. Während der Erzeugung der Schlüssel stürzt zumindest bei mir die Nitrokey App ab. Also nicht wundern wenn das passiert, auf jeden Fall funktioniert danach wieder alles.

  • Sicherung des Schlüssels auf dem Rechner ablegen (J/n)
    Das ist nicht zwingend notwendig in meinem Fall habe ich das aber getan.
  • Wie lange bleibt der Schlüssel gültig?
    Hier legt man die Gültigkeit des Schlüssels fest. Mit z.B. „1y“ ist der Schlüssel ein Jahr ab dem heutigen Tag gültig. Mit „0“ ist dieser unbegrenzt gültig.
  • Name eingeben
  • Email Adresse eingeben
  • Kommentar eingeben
    Hier kann man ein Kommentar zur Identität eingeben. Das ist aber optional.
  • Identitätsdaten bestätigen
    Mit „F“ bestätigt man alle Daten.
  • Schlüssel werden generiert
    Das keine einige Zeit dauern!
  • Passwort für Sicherung vergeben (optional)
    Hat man sich zuvor für die Sicherung des Schlüssels entschieden wird man nun nach einem Passwort gefragt, um diesen zu sichern.

Danach sollten die Kartendaten in etwa wie folgt aussehen:

...
Signature key ....: B05E 7E73 CD40 19D2 A067  2F4E 2CFC 1FDF E1A9 EC37
      created ....: 2019-05-19 09:29:12
Encryption key....: 0821 7AB9 0C7C 7780 1DC9  C2F4 1EFE 31FB B5D9 47EF
      created ....: 2019-05-19 09:29:12
Authentication key: 0C9E 2AA2 F397 8FD9 9C1F  8BE8 6F3E A2B4 7B5C 9005
      created ....: 2019-05-19 09:29:12
General key info..: 
pub  rsa2048/2FFC1CCFE1A9EC37 2019-05-19 Max Mustermann <max.mustermann@example.org>
sec>  rsa2048/2EEC1FDFE1A9EC37  erzeugt: 2019-05-19  verfällt: niemals   
                                Kartennummer:0001 00001234
ssb>  rsa2048/6F3EA2B4FF5C9005  erzeugt: 2019-05-19  verfällt: niemals   
                                Kartennummer:0001 00001234
ssb>  rsa2048/1EFEABFBB5D947EF  erzeugt: 2019-05-19  verfällt: niemals   
                                Kartennummer:0001 00001234

Damit haben wurde der OpenPGP Schlüssel auf dem Nitrokey Pro 2 erzeugt.

Abschluss

In weiteren Tutorials erkläre ich, wie man den OpenPGP Schlüssel verwenden kann.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag OpenPGP Schlüssel auf Nitrokey Pro 2 erzeugen erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/05/19/openpgp-schluessel-auf-nitrokey-pro-2-erzeugen/feed/ 0
Homematic IP Geräte von Lidl https://blog.nubecula.org/index.php/2019/01/10/homematic-ip-geraete-von-lidl/ https://blog.nubecula.org/index.php/2019/01/10/homematic-ip-geraete-von-lidl/#respond Thu, 10 Jan 2019 20:47:30 +0000 https://blog.nubecula.org/?p=486 Am 10.01.19 gab Homatic IP Geräte bei Lidl zu kaufen. Die Geräte sind lediglich teilweise mit „Silvercrest“ gebrandet, sind aber eigentlich Homematic IP Geräte von eQ-3 und zu 100% kompatibel. Im Lidl Online Shop gab...

Der Beitrag Homematic IP Geräte von Lidl erschien zuerst auf nubecula.org.

]]>
Am 10.01.19 gab Homatic IP Geräte bei Lidl zu kaufen. Die Geräte sind lediglich teilweise mit „Silvercrest“ gebrandet, sind aber eigentlich Homematic IP Geräte von eQ-3 und zu 100% kompatibel. Im Lidl Online Shop gab es die zwar schon vorher, waren aber überwiegend auf Grund der hohen Nachfrage ausverkauft.

Im Vorfeld hatte ich schon im Online Shop das Starter-Set „Heizen“ bestellt. Es besteht aus einem Homematic IP Access Point, einem Heizkörperthermostat und einem magnetischen Tür- und Fensterkontakt. Nach langem warten kam es auch dann einen Tag vor dem Verkauf in den Filialen bei mir an. Mein Plan war es, meine bestehenden „unsmarten“ Thermostate gegen „smarte“ zu ersetzen.

Mit der Vermutung das die Geräte auch in der Filiale schnell vergriffen sein werden, war ich morgens als einer der ersten in der Filiale. Ich sollte recht behalten! Ich hatte das Glück, dass ich nicht wie die Anderen direkt zu den Auslagentischen gerannt bin, sondern die Kasse angesteuert habe. Dort hatte die Verkäuferin den armseligen Bestand in einer Kiste stehen (Kannte ich schon von früher mal). Es gab lediglich fünf Heizkörperthermostate, zwei Tür- /Fensterkontakte und zwei Starter-Sets. Ich kaufte also auf einen Schlag das komplette Angebot an Thermostaten und Kontakten auf, zum Unmut der Anderen. Bei dem Preis war mir das aber auch herzlich egal

Access Point

Der Access Point aus dem Starter Set ist ein HmIP-HAP-B1, der im Grunde dem Homematic IP Access Point (140887A0) entspricht. Wie bei Homematic IP üblich und oft bemängelt gibt es kein lokales Webinterface zum konfigurieren der heimische Installation. Es läuft alles über einen Cloud Dienst. Ist dieser außer Funktion oder wird irgendwann einmal abgeschaltet, kann man die Geräte nicht mehr nutzen. Das daraus entstehende Risiko sollte jeder selbst abwegen.

Die Funkreichweite in meiner Wohnung ist in Ordnung. Ich musste keinen besonderen Platz für den Access Point wählen. Wir wohnen in einem Altbau mit ca 40 – 50 cm dicken Wänden zwischen den Zimmer. Mit WLAN habe ich hier meine Probleme, aber das System von Homematic IP auf 868 MHz-Basis macht das nicht zu schaffen.

Was mich an dem Access Point unglaublich nervt, ist die dauerhaft leuchtende blaue LED an der Vorderseite (Knopf). Normal klebe ich so etwas ab, aber hier geht es funktionsbedingt leider nicht.

Heizkörper Thermostat

Das Heizkörperthermostat hat die Bezeichnung HmIP eTRV-B1. Dieses entspricht wieder dem aus dem original Starter Set.

Das Thermostat wird mit zwei AA Batterien betrieben. Gegenüber meinen alten Thermostaten sind diese wirklich leise. Die Temperatur kann man direkt am Thermostat mit zwei Tasten einstellen „+/-„. Ein Drehrad wie beim Homematic IP Heizkörperthermostat (140280) fehlt. Da die Temperatur später sowieso automatisch, per Sprachbefehl oder App eingestellt wird, ist mir die Bedienung am Thermostat selbst relativ egal.

Tür- und Fensterkontakt

Bei dem Tür- und Fensterkontakt handelt es sich um einen magnetischen Kontakt mit der Bezeichnung HmIP-SWDM-B2. Das ist auch wieder der gleiche aus dem original Starter Set von Homematic IP.

Man hat einmal den eigentlichen Kontakt und einen Magnet in einem separaten kleinen Gehäuse. Der Kontakt wird mit zwei AAA Batterien betrieben.

Mit dem Kontakt ist es möglich, automatisch die Heizungsthermostate herunterzufahren, um nicht unnötig die Straße zu heizen, wenn mal ein Fenster oder Tür aufsteht. Ebenso kann man ihn mit der Homematic IP Alarmsirene koppeln.

Software

In den App-Stores gibt es eine Silvercrest Smart Home App. Den Link hierzu findet man in den Beipackzetteln im Startset. Ich selbst habe direkt die original Homematic IP App benutzt, die auch mit dem Silvercrest Access Point funktioniert. Ich vermute mal das es sich auch bei der App nur um ein gebrandete Version handelt.

Da ich das System mit Alexa und mit Home Assistant verbinden wollte, dachte ich ist das die bessere Wahl.

Fazit

Mit diesem Angebot war es verhältnismäßig preiswert ein Homematic IP System auf- oder auszubauen.

Im Bereich „Homematic IP“ und „Smart Home“ pflege ich diverse Tutorials. Vielleicht schaust Du dir sie mal an!

Wenn Ihr Fragen habt, benutzt bitte die Kommentarfunktion!

Der Beitrag Homematic IP Geräte von Lidl erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/01/10/homematic-ip-geraete-von-lidl/feed/ 0
Gentoo von no-multilib in multilib umwandeln https://blog.nubecula.org/index.php/2019/01/05/gentoo-von-no-multilib-in-multilib-umwandeln/ https://blog.nubecula.org/index.php/2019/01/05/gentoo-von-no-multilib-in-multilib-umwandeln/#respond Sat, 05 Jan 2019 05:25:07 +0000 https://blog.nubecula.org/?p=465 In diesem Tutorial beschreibe ich euch alle nötigen Schritte um ein Gentoo von „no-multilib“ System in ein „multilib“ System umzuwandeln. Auf meinem Server hatte ich ein „no-multilib“ Gentoo laufen, kam aber in die Bredouille eine...

Der Beitrag Gentoo von no-multilib in multilib umwandeln erschien zuerst auf nubecula.org.

]]>
In diesem Tutorial beschreibe ich euch alle nötigen Schritte um ein Gentoo von „no-multilib“ System in ein „multilib“ System umzuwandeln.

Auf meinem Server hatte ich ein „no-multilib“ Gentoo laufen, kam aber in die Bredouille eine 32-Bit Anwendung irgendwie zum Laufen zu bringen. Ein einfaches wechseln des Profils ist leider nicht ausreichend. Da für mich eine Neuinstallation zu aufwendig war, habe ich mich für einen anderen Weg entschieden, den ich euch hier erläutere.

Ich benutze ein aktuelles Stage 3 Archiv mit dem ich in einer Chroot einfach die notwendigen Pakete kompiliere.

Vorbereitung

Bevor Ihr anfangt, solltet Ihr unbedingt ein Backup des bestehenden Systems machen! Falls etwas schief läuft will ich nicht der Bösewicht sein, der euer System gekillt hat.

Kernel konfigurieren

Wir aktivieren in unserem Kernel folgende Parameter um eine 32-Bit Unterstützung zu aktivieren:

Binary Emulations  --->
    [*] IA32 Emulation
    < >   IA32 a.out support
    [*] x32 ABI for 64-bit mode  

Danach den Kernel neu kompilieren und installieren.

Stage3 Chroot erstellen

Zuerst legen wir uns einen Ordner für das Stage3 System an. Ich habe mich für „/chroot“ entschieden. Nachdem man den Ordner erstellt hat, wechselt man in diesen.

mkdir /chroot
ch /chroot

Solltet Ihr euch für einen anderen Ordner entschieden haben, müsst Ihr „/chroot“ im Laufe dieses Tutorials mit eurem ersetzen!

Nun laden wir das aktuelle Stage3 Archiv runter:

wget http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/stage3-amd64-*.tar.xz

Das „*“ in „stage3-amd64-*.tar.xz“ müsst Ihr mit dem aktuellen Release ersetzen!

Nun entpacken wir das Stage3 Archiv:

tar xvpf stage3-amd64-*.tar.xz

Verzeichnisse erstellen und mounten

Zuerst mounten wir unserer Portage Verzeichnis in den Stage3 Ordner:

mkdir /chroot/usr/portage
mount --bind /usr/portage /chroot/usr/portage

Als nächstes binden wir das Root Dateisystem des Hauptsystems ein:

mkdir /chroot/system_root
mount --bind / /chroot/system_root

Danach folgen die üblichen Schritte die man auch aus dem Gentoo Handbuch kennt:

cp /etc/resolv.conf /chroot/etc/
mount -t proc none /chroot/proc

Nun können wir in die Chroot wechseln:

chroot /chroot /bin/bash
env-update
source /etc/profile

Chroot System konfigurieren

Nun befinden wir uns in unser Chroot. Wir wählen zuerst ein passendes Profil aus. Eine Liste bekommt man mit:

eselect profile list

Ein Profil setzen geht über:

eselect profile set [Nummer]

In der „/etc/portage/make.conf“ trägt man am Besten die gleichen CFLAGS ein wie beim Hauptsystem.

Pakete kompilieren

Nun müssen wir „GCC“ und „glibc“ kompilieren. Es ist wichtig das hier unbedingt die gleichen Versionen wie im Hauptsystem zu benutzen sind! Kontrolliert dies bitte genau!

emerge -a --root=/system_root --root-deps=rdeps gcc glibc

Damit werden „GCC“ und „glibc“ in der Chroot kompiliert aber im Hauptsystem installiert. Achtet darauf, dass wenn Ihr einen anderen Ordner als „system_root“ benutzt, diesen unbedingt anpasst!

Sind die beiden Pakete erfolgreich installiert verlassen wir wieder die Chroot.

Chroot verlassen und aufräumen

Nachdem wir „GCC“ und „glibc“ im Hauptsystem installiert haben, verlassen wir die Chroot und räumen auf:

exit
umount /chroot/proc
umount /chroot/usr/portage
umount /chroot/system_root

Wenn man die Chroot nicht mehr braucht, kann man diese auch einfach wieder löschen:

rm -R /chroot

Hauptsystem fertigstellen

Da wir nun im Hauptsystem „GCC“ und „glibc“ in der „multilib“ Variante haben, können wir nun unser Profil wechseln. Wechselt also nun auf das gewünschte „multilib“ Profil:

eselect profile set [Nummer]

Danach führen wir zum Schluss noch ein World Update aus:

emerge -a -u --deep --newuse @world

Das sollte zumindest „sys-apps/sandbox“ mit der ABI_X86 Flag für 32- und 64-Bit installieren.

Fazit

Mit den beschrieben Schritten habt Ihr euer „no-multilib“ System in ein „multilib“ System gewandelt. Sollte irgendetwas nicht funktionieren, spielt euer Backup zurück, dass Ihr selbstverständlich am Anfang gemacht habt.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag Gentoo von no-multilib in multilib umwandeln erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/01/05/gentoo-von-no-multilib-in-multilib-umwandeln/feed/ 0
SSH Tunnel erstellen https://blog.nubecula.org/index.php/2019/01/03/ssh-tunnel-erstellen/ https://blog.nubecula.org/index.php/2019/01/03/ssh-tunnel-erstellen/#respond Thu, 03 Jan 2019 12:40:13 +0000 https://blog.nubecula.org/?p=436 Mit Hilfe eines SSH Tunnels kann der Zugriff auf Netzwerkdienste auf einem Server verschlüsselt stattfinden. Hierfür wird ein Port auf dem Server auf dem Client zur Verfügung gestellt. Der Zugriff auf dem Client erfolgt dann, als würde der getunnelte Dienst lokal laufen.

Der Beitrag SSH Tunnel erstellen erschien zuerst auf nubecula.org.

]]>
Ein SSH Tunnel dient dazu, einen verschlüsselten Zugriff auf Netzwerkdienste auf einem Server zu ermöglichen. Hierfür wird ein Port auf dem Server auf dem Client zur Verfügung gestellt. Der Zugriff auf dem Client erfolgt dann, als würde der getunnelte Dienst lokal laufen.

Dieses Tutorial beschreibt euch alle notwendigen Schritte um einen solchen SSH Tunnel einzurichten.

Alle Schritte dieses Tutorials habe ich auf zwei Gentoo Systemen durchgeführt. Die Befehle sollten aber generell auf alle Distributionen anwendbar sein.

Client – Benutzer anlegen und Public Key erzeugen

Um einen SSH Tunnel zu erstellen braucht man einen Nutzer. Das ROOT für so etwas ungeeignet ist, sollte jedem klar sein. Man kann einen bestehenden Benutzer nehmen oder man erstellt einen Neuen:

useradd -m -G users -s /bin/bash tunnel

In meinem Fall habe ich mich für den Benutzer „tunnel“ entschieden, den ich im Laufe des Tutorials benutzen werde.

Als Nächstes erzeugen wir einen Public Key für diesen Benutzer. Wenn Ihr bereits einen für euren Benutzer habt, könnt Ihr diesen Teil einfach überspringen.

Wir wechseln in einer Konsole zu unserem Benutzer:

su tunnel

Nun erzeugen wir uns einen Private Key. Bei der Schlüssel Länge sollte man sich mindestens für 2048 Bit entscheiden. In meinem Beispiel nutze ich 4096 Bit.

ssh-keygen -b 4096

Für unseren Bedarf sollten wir auf ein Passwort für den Public Key verzichten, da wir nicht jedes mal ein Passwort bei einer Verbindung eingeben wollen oder können. Alle Abfragen werden einfach mit ENTER bestätigt. Danach solltet Ihr Folgendes sehen:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tunnel/.ssh/id_rsa): 
Created directory '/home/tunnel/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/tunnel/.ssh/id_rsa.
Your public key has been saved in /home/tunnel/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:20THOyO+FfisaLZb1vdqyTnODnmb4lKNDw3enTiyzxg tunnel@local.net
The key's randomart image is:
+---[RSA 4096]----+
|                 |
|           .     |
|          . o    |
|         . o..   |
|        S +.=*...|
|         = *=B+..|
|        . =EX++o |
|        o+.===B+ |
|       o+oo+oBBo.|
+----[SHA256]-----+

Weiter geht es nun mit der Einrichtung der Server Seite.

Server – Benutzer anlegen

Auch auf der Server Seite sollte ein Benutzer für den Aufbau des SSH Tunnels gewählt werden. Wenn man keinen hat, legt man einfach einen an:

useradd -m -G users -s /bin/bash tunnel

Hier nenne ich meinen Benutzer auch „tunnel“. Man kann aber einen beliebigen Namen haben. Benutzernamen müssen auch Client und Server Seite nicht identisch sein.

Public Key von Client auf Server übertragen

Auf der Client Maschine loggen wir uns als Benutzer „tunnel“ ein und übertragen den Public Key auf den Server.

ssh-copy-id -i ~/.ssh/id_rsa.pub tunnel@example.org

Ihr solltet hier natürlich euren Benutzernamen verwenden, sowie den Hostnamen eures Servers. Ihr werdet dann nach dem Passwort für den Benutzer auf dem Server gefragt. Gebt dieses ein und Ihr solltet dann sehen, dass der Key korrekt übertragen wurde.

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'tunnel@example.org'"
and check to make sure that only the key(s) you wanted were added.

Also probieren wir kurzerhand uns per SSH vom Client auf den Server zu verbinden:

ssh tunnel@example.org

Nun sollte das Anmelden ohne Passwort funktionieren. Wenn dies nicht funktionieren sollte, überprüft auf dem Server die „/etc/ssh/sshd_config“, ob folgender Eintrag enthalten ist:

PubkeyAuthentication yes

Nun ist alles bereit einen SSH Tunnel zu erstellen.

SSH Tunnel erstellen

Auf der Client Maschine können wir nun mit folgendem Befehl einen Tunnel erstellen. Ihr solltet natürlich als entsprechender Nutzer („tunnel“) angemeldet sein.

ssh tunnel@example.org -L 2234:localhost:1234 -N -f -C

Der Benutzer „tunnel“ meldet sich auf dem Server (example.org) an und erstellt dann einen SSH Tunnel der Port 1234 auf dem Server als Port 2234 auf dem Client (localhost) verfügbar macht. Angenommen auf dem Server läuft auf Port 1234 ein Webserver, dann sollte nun auf dem Client dieser im Webbrowser mit „http://localhost:2234“ erreichbar sein.

Am Ende des Befehls habe ich noch ein paar Parameter gesetzt, die ich kurz erläutern will:

  • Mit der Option -N wird die SSH-Verbindung auf ihre Tunnelfunktion beschränkt und es erfolgt kein Login auf eine Shell.
  • Mit der Option -f wird der SSH-Tunnel als Hintergrunddienst ausgeführt.
  • Mit der Option -C können wir zusätzlich die Datenübertragung komprimieren, um diese zu beschleunigen.

Fazit

Damit ist es uns nun möglich, beliebige Anwendungen über einen SSH Tunnel weiterzuleiten. Es sei aber angemerkt, dass bei dem Neustart der Systeme (Client / Server) die Tunnel immer wieder neu erstellt werden müssen. Sinnvoll ist es sicher, wenn man dies beim Systemstart automatisiert. Das soll jedoch kein Bestandteil dieses Tutorials sein.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag SSH Tunnel erstellen erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2019/01/03/ssh-tunnel-erstellen/feed/ 0
OwnTracks mit Mosquitto MQTT Broker in Home Assistant nutzen https://blog.nubecula.org/index.php/2018/12/26/owntracks-mit-mosquitto-mqtt-broker-in-home-assistant-nutzen/ https://blog.nubecula.org/index.php/2018/12/26/owntracks-mit-mosquitto-mqtt-broker-in-home-assistant-nutzen/#respond Wed, 26 Dec 2018 19:13:14 +0000 https://blog.nubecula.org/?p=393 Dieses Tutorial beschreibt euch alle notwendigen Schritte, wie Ihr die App OwnTracks mit Mosquitto MQTT Broker und Home Assistant als Device Tracker nutzten könnt. Da ich mein Home Assistant nicht über das Internet erreichbar gemacht...

Der Beitrag OwnTracks mit Mosquitto MQTT Broker in Home Assistant nutzen erschien zuerst auf nubecula.org.

]]>
Dieses Tutorial beschreibt euch alle notwendigen Schritte, wie Ihr die App OwnTracks mit Mosquitto MQTT Broker und Home Assistant als Device Tracker nutzten könnt. Da ich mein Home Assistant nicht über das Internet erreichbar gemacht habe, gehe ich den Weg über den Mosquitto MQTT Broker. Wenn man eine direkte Verbindung zu Home Assistant hat, kann man auch direkt die OwnTracks Komponente benutzen.

Es wird folgendes vorausgesetzt:

Die in dem Tutorial benutzen Befehle sind teilweise Gentoo Linux spezifisch. Jene müsst ihr entsprechend auf eure verwendeten Distribution anpassen.

Mosquitto Benutzer anlegen

Wir müssen einen Benutzer für Home Assistant im Mosquitto Broker anlegen:

mosquitto_passwd /etc/mosquitto/pwfile hass

Meinen Benutzer nenn ich „hass“. Ihr könnt natürlich jeden beliebigen Namen benutzen.

Im Anschluss müssen wir noch die Benutzer für alle OwnTracks Clients anlegen. Für dieses Tutorial lege ich den Benutzer „otclient“ an.

mosquitto_passwd /etc/mosquitto/pwfile otclient

Sind alle Benutzer angelegt muss man Mosquitto neu starten:

/etc/init.d/mosquitto restart

OwnTracks mit Mosquitto verbinden

Nachdem wir OwnTracks auf unserem Smartphone installiert haben, müssen wir noch die Verbindungsdaten zu unserem Mosquitto Broker einstellen. Hier gehe ich ausgehend von diesem Tutorial davon aus, dass Mosquitto mit SSL Verschlüsselung über Port 8883 aus dem Internet erreichbar ist. Solltet Ihr andere Ports verwenden sind diese entsprechend anzupassen.

Wir öffnen die OwnTracks App und gehen in die Einstellungen unter „Verbindungen“. Das sollte dann in etwa so aussehen (Android):

OwnTracks – Verbindungen

Bei „Mode“ stellt die Verbindung auf „MQTT Privat“. Weiter geht es mit der Einrichtung des „Hosts“:

OwnTracks – Hos

Bei „Host“ tragt ihr die Adresse eures Mosquitto Brokers ein. Bei Port tragt ihr euren ein, in meinem Fall 8883. „WebSockets“ werden deaktiviert.

Danach ändern wir unsere „Identifikation“:

OwnTracks – Identifikation

Hier tragen wir den Benutzer ein, den wir zuvor in Mosquitto eingerichtet haben. In meinem Fall ist das „otclient“. Bei der „Device ID“ trägt man einen beliebigen Namen ein, unter dem das Gerät zu finden ist. Unter Tracker ID können wir zwei Buchstaben eintragen z.B. die eigenen Initialen. Diese werden letztlich aber nur in OwnTracks auf der Karte angezeigt.

Zum Schluss aktivieren wir noch die verschlüsselte Verbindung unter „Sicherheit“:

OwnTracks – Sicherheit

Um zu überprüfen ob wir alles richtig eingestellt haben, drücken wir auf das Info-Symbol oben rechts, um den Verbindungsstatus zu sehen. Wenn alles in Ordnung ist, sollte es in etwa so aussehen:

OwnTracks – Verbindungsstatus

Sollte keine Verbindung möglich sein, überprüft noch einmal eure Daten auf Richtigkeit.

OwnTracks für Home Assistant anpassen

In der Standard Konfiguration von OwnTracks (Android) funktionierte bei mir die Einrichtung unter Home Assistant zuerst nicht. Auf der Suche im OwnTracks Manual wurde ich dann fündig. Unter „Einstellungen -> Konfigurationsverwaltung“ muss „mqttProtocolLevel“ auf 4 gesetzt werden.

OwnTracks – MQTT Protocol Level

Danach noch Owntracks neustarten! Das geht bequem im Konfigurationseditor.

Verbindung zu Mosquitto Broker testen

Nun überprüfen wir, ob wir auch in der Lage sind mit OwnTracks den aktuellen Standort an unseren Mosquitto Broker zu schicken. Dafür starten wir einen Mosquitto Sub:

mosquitto_sub -h localhost -p 1883 -t "owntracks/#" -v -u USERNAME -P PASSWORD

Das Kommando führe ich bei mir auf dem System aus, auf dem der Broker läuft. Sollte sich der Broker auf einem anderen System befinden müsst Ihr anstatt „localhost“ euren Hostnamen/IP eintragen. Der Port für die lokale unverschlüsselte Verbindung ist bei mir 1883. „USERNAME“ und „PASSWORD“ ersetzt Ihr mit euren Login Daten. Ich habe einfach den Benutzer „hass“ genommen, den wir zuvor angelegt haben. Sollten alle Angaben korrekt sein, können wir einkommende Nachrichten sehen. Um von OwnTracks eine Nachricht auszulösen drücken wir im Hauptfenster der App auf den Upload-Button.

OwnTracks – Position Upload

Dann sollte in der Konsole in der wir den Sub gestartet haben ein Nachricht ähnlich dieser auftauchen:

owntracks/otclient/androidphone1 {"_type":"location","acc":1787,"alt":0,"batt":62,"conn":"w","lat":49.635325,"lon":7.6567407,"t":"u","tid":"e1","tst":1545787405,"vac":0,"vel":0}

Wenn alles bis hier hin funktioniert hat können wir mit der Einbindung in Home Assistant fortfahren.

OwnTracks in Home Assistant einrichten

In diesem Schritt werden wir in Home Assistant eine Verbindung mit unserem Mosquitto Broker einrichten. Hierfür tragen wir in der „configuration.yaml“ Folgendes ein:

mqtt:
  broker: localhost
  port: 1883
  username: USERNAME
  password: PASSWORD
  client_id: "hass"
  

Die oberen Daten sind entsprechend auf eure Belange anzupassen. Damit haben wir unseren Mosquitto MQTT Broker in Home Assistant eingerichtet.


Nun fügen wir OwnTracks zu unserer „configuration.yaml“ hinzu:

owntracks:
  max_gps_accuracy: 200
  waypoints: true
  mqtt_topic: "owntracks/#"
  events_only: true

Nachdem wir Home Assistant neu gestartet haben, sollte in der Datei „known_devices.yaml“ unseren OwnTracks Geräte auftauchen:

otclient_androidphone1:
  hide_if_away: false
  icon:
  mac:
  name: otclient
  picture:
  track: false

Damit das Gerät auch getrackt wird, ändern wir den Eintrag entsprechend ab und setzten den Parameter „track“ auf „true“.

otclient_androidphone1:
  hide_if_away: false
  icon:
  mac:
  name: otclient
  picture:
  track: true

Damit haben wir die Einrichtung von OwnTracks in Verbindung mit einem Mosquitto MQTT Broker und Home Assistant erfolgreich beendet.

Fazit

Damit habe wir zumindest die grundlegende Funktionen von OwnTracks nutzbar gemacht, nämlich das Tracken von Geräten. Man kann aber auch noch weitere Dinge in Verbindung mit Home Assistant und OwnTracks machen, wie z.B. die Zonen / Orte in beiden Systemen abgleichen. Hier hilft einem die Home Assisant bzw. OwnTracks Hilfe weiter.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag OwnTracks mit Mosquitto MQTT Broker in Home Assistant nutzen erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2018/12/26/owntracks-mit-mosquitto-mqtt-broker-in-home-assistant-nutzen/feed/ 0
Mosquitto MQTT Broker unter Gentoo einrichten https://blog.nubecula.org/index.php/2018/12/24/mosquitto-mqtt-broker-unter-gentoo-einrichten/ https://blog.nubecula.org/index.php/2018/12/24/mosquitto-mqtt-broker-unter-gentoo-einrichten/#respond Mon, 24 Dec 2018 12:51:43 +0000 https://blog.nubecula.org/?p=378 Mosquitto ist ein Open Source MQTT Broker. Den Broker kann man dann nutzen, um z. B. Owntracks mit Home Assistant zu nutzen. Diese Tutorial beschreibt, wie Ihr einen Mosquitto Server unter Gentoo einrichtet.

Der Beitrag Mosquitto MQTT Broker unter Gentoo einrichten erschien zuerst auf nubecula.org.

]]>
Mosquitto ist ein Open Source MQTT Broker. Den Broker kann man dann nutzen, um z. B. Owntracks mit Home Assistant zu nutzen. Diese Tutorial beschreibt, wie Ihr einen Mosquitto Server unter Gentoo einrichtet.

Installation

Zum Zeitpunkt der Erstellung dieses Tutorials war Mosquitto in Version 1.5.4 in Portage verfügbar.

Wir installieren Mosquitto:

emerge -a app-misc/mosquitto

Mosquitto Benutzer anlegen

Um euch mit dem Mosquitto Broker zu verbinden müsst Ihr einen Benutzer anlegen und eine Passwort Datei erstellen. Dies geschieht mit folgenden Befehl:

mosquitto_passwd -c /etc/mosquitto/pwfile USERNAME

Mit dem Parameter „-c“ wird eine neue Datei erstellt. Existiert bereits eine wird diese überschrieben. Soll der Benutzer zusätzlich angelegt werden, lasst den Parameter „-c“ einfach weg. „USERNAME“ ist mit eurem Benutzernamen zu ersetzen. Wenn Ihr diesen Befehl ausführt müsst Ihr ein Passwort festlegen und dieses im Anschluss bestätigen.

Mosquitto konfigurieren

Nun müssen wir noch die eigentliche Konfiguration von Mosquitto vornehmen. Dies geschieht in der Datei „/etc/mosquitto/mosquitto.conf“. Der Einfachheit halber ist hier meine Konfiguration:

autosave_interval 1800
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto/
log_dest syslog
log_type error
log_type warning
log_type notice
log_type information
connection_messages true
log_timestamp true
allow_anonymous false
password_file /etc/mosquitto/pwfile

listener 1883 localhost

Nun starten wir unseren Mosquitto Broker und fügen ihn zum Default Runlevel hinzu:

/etc/init.d/mosquitto start
rc-update add mosquitto default

Mosquitto testen

Um zu überprüfen, ob unser Broker funktioniert, richten wir einen sogenannten „Sub“ ein.

mosquitto_sub -h BROKERHOST -p PORT -t "owntracks/#" -v -u USERNAME -P PASSWORD

In diesem Befehl müsst Ihr die Platzhalter entsprechend mit euren Daten ersetzen. In meinem Fall benutze ich Owntracks auf meinen Android Smartphone um Nachrichten zu schicken (deswegen -t „owntracks/#“).

Wenn kein Fehler beim Ausführen des Befehls kommt, solltet Ihr einkommende Nachrichten sehen können. Die Antwort sieht dann in etwa so aus:

owntracks/user/androidphone {"_type":"location","acc":1800,"alt":0,"batt":65,"conn":"w","lat":46.8359704,"lon":7.5705195,"t":"u","tid":"us","tst":1545653489,"vac":0,"vel":0}

Mosquitto mit SSL sichern

In der aktuellen Konfiguration sollte man den Broker nur im lokalen Netzwerk nutzen. Es ist selbstredend, dass man bei einer Nutzung über das Internet eine Verschlüsselung der Übertragung in Erwägung ziehen sollte.

Hierfür benötigt man SSL Zertifikate. Deren Erstellung soll kein Bestandteil dieses Tutorial sein. Ich nutze in meinem Fall einfach die bestehenden Let’s Encrypt Zertifikate auf meinem Home Server.

Um die SSL Verschlüsselung zu nutzen fügt folgendes zur „/etc/mosquitto/mosquitto.conf“ hinzu:

listener 8883
certfile /etc/letsencrypt/live/subdomain.example.com/cert.pem
cafile /etc/letsencrypt/live/subdomain.example.com/chain.pem
keyfile /etc/letsencrypt/live/subdomain.example.com/privkey.pem

Falls Ihr auch Let’s Encrypt benutzt müsst Ihr im Pfad „subdomain.example.com“ mit eurem eigenen Domainnamen ersetzen. Nutz ihr selbstsignierte SSL Zertifikate tragt entsprechend die Pfade zu diesen richtig ein.

Wichtig ist das Ihr den bisherigen „listener 1883 localhost“ in der Konfigurationsdatei behaltet. So könnt Ihr ohne SSL Verschlüsselung im lokalen Netz auf den Broker verbinden. Für externe Verbindungen wird dann Port 8883 benutzt. Diesen müsst Ihr natürlich in euer Firewall / Router freigeben.

Danach den Mosquitto Broker neu starten:

/etc/init.d/mosquitto restart

Fazit

Mit Mosquitto könnt ihr relativ einfach einen effizienten MQTT Broker realisieren.

Hiermit ist dieses Tutorial abgeschlossen. Ich hoffe es war hilfreich für euch! Wenn Ihr mich unterstützen wollt, könnt ihr das sehr gerne hier tun.

Der Beitrag Mosquitto MQTT Broker unter Gentoo einrichten erschien zuerst auf nubecula.org.

]]>
https://blog.nubecula.org/index.php/2018/12/24/mosquitto-mqtt-broker-unter-gentoo-einrichten/feed/ 0