Schlagwort-Archive: Linux

Unixähnliche Mehrbenutzer-Betriebssysteme, die auf dem Linux-Kernel und wesentlich auf GNU-Software basieren. Wie CentOS, Debian, Ubuntu Fedora.

Linux

Firefox Sync in Privat Cloud

26. Mai 2019 DonMatteo Schreibe einen Kommentar

Firefox Sync Server auf eigenem Host

Firefox Sync macht Lesezeichen auf jedem Gerät synchron verfügbar, auch die Chronik, Tabs, Add-ons, Einstellungen und die Zugangsdaten können auf wunsch verteilt werden.

Den bei Mozilla gehosteten Firefox-Account-Server kann problemlos in Kombination mit einem selbst gehosteten Synchronisierungs-speicherserver verwendet werden. Die Authentifizierungs- und Verschlüsselungsprotokolle sind so konzipiert, dass der Account-Server das Klartextkennwort des Benutzers nicht kennt und daher nicht auf die gespeicherten Synchronisierungsdaten zugreifen kann.

INHALT

Firefox Sync Server Installation
Firefox Sync Grundkonfiguration
Firefox Sync Apache Konfiguration
Firefox Sync HTTPS Let’s Encrypt
Firefox Browser Einstellung
Troubleshoting & Settings

In diesem Tutorial wird die Installation von Firefox Sync-1.5-Server auf Ubuntu 16.04.4 LTS aufgezeigt. Der Ubuntu Server, hier sync.server.net als Beispiel, ist über den Apache 2.4 Webserver im Internet erreichbar.

Firefox Sync Server Installation

Voraussetzung für Sync-1.5-Server ist Python 2.7 und Python Virtualenv, python-dev, make, git, sowie der C und C ++ Compiler. Zur sicherstellung werden folgende Pakte bereitgestellt:


$ sudo apt-get install apach2 libapache2-mod-wsgi python-dev python-virtualenv git-core g++ make

1 2	$ sudo apt-get install apach2 libapache2-mod-wsgi python-dev python-virtualenv git-core g++ make

Wir installieren den Sync-Server unter opt, es könnte auch /usr/local sein, dazu root werden und folgende Zeilen ausführen:


$ sudo su -
$ cd /opt
$ git clone https://github.com/mozilla-services/syncserver
$ cd syncserver
$ make build

$ sudo su -

$ cd /opt

$ git clone https://github.com/mozilla-services/syncserver

$ cd syncserver

$ make build

Um zu überprüfen, ob die Installation korrekt war, kann folgendes make aufschluss geben:


$ make test

1 2	$ make test

Firefox Sync Grundkonfiguration

Erst erstellen wir ein Benutzer mit zuweisung der Berechtigung:


$ useradd -d /opt/syncserver/ -l -r -U ffsync
$ chown -R ffsync:www-data /opt/syncserver/

$ useradd -d /opt/syncserver/ -l -r -U ffsync

$ chown -R ffsync:www-data /opt/syncserver/

Der Sync-Server wird mithilfe der ini-Datei konfiguriert, um verschiedene Laufzeiteinstellungen zu übergeben. Die Datei syncserver.ini dient als Ausgangspunkt.

Die meisten Einstellungen können übernommen werden, bevor der Sync-Server ausgeführt wird, muss die für die Clients erreichbare URL zum Sync-Server angepasst werden. Für den produktiven Einsatz öffnen wir die Datei syncserver.ini und editieren die public_url:


$ vi /opt/syncserver/syncserver.ini

[syncserver]
public_url = https://sync.server.net/

$ vi /opt/syncserver/syncserver.ini

[syncserver]

public_url = https://sync.server.net/

Die public_url von localhost:5000 auf unser sync.server.net ändern. In einem weiteren Abschnitt wird die Konfiguration auf das HTTPS Protokoll eingerichtet.

Dann noch die sqluri für unsere Datenbak anpassen:


sqluri = sqlite:////opt/syncserver/syncserver.db

1 2	sqluri = sqlite:////opt/syncserver/syncserver.db

Aus einem Terminal wird ein Secret Key mit dem Zufallsgenerator erzeugt, dazu folgende Zeile ausführen:


$ head -c 20 /dev/urandom | sha1sum
60bev0b7bd2f56dxea3794fb97f03c824e70e21d

$ head -c 20 /dev/urandom | sha1sum

60bev0b7bd2f56dxea3794fb97f03c824e70e21d

Diesen so erzeugten Schlüssel in der Konfigurationsdatei syncserver.ini eintragen:


secret = 60bev0b7bd2f56dxea3794fb97f03c824e70e21d

1 2	secret = 60bev0b7bd2f56dxea3794fb97f03c824e70e21d

Der Datenbank Datei ausreichend rechte zuweisen:


$ chmod 660 /opt/syncserver/syncserver.db

1 2	$ chmod 660 /opt/syncserver/syncserver.db

Firefox Sync Apache Konfiguration

Ein Apache Virtualhost wie folgt in diesem Beispiel erstellen:


$ vi /etc/apache2/sites-available/sync.server.net.conf

<VirtualHost *:80>
ServerName sync.server.net
DocumentRoot /opt/syncserver

CustomLog /var/log/apache2/access_sync.server.net.log combined
ErrorLog /var/log/apache2/error_sync.server.net.log
LogLevel warn

<Directory /opt/syncserver>
        Require all granted
        Options -Indexes
</Directory>
</VirtualHost>

$ vi /etc/apache2/sites-available/sync.server.net.conf

ServerName sync.server.net

DocumentRoot /opt/syncserver

CustomLog /var/log/apache2/access_sync.server.net.log combined

ErrorLog /var/log/apache2/error_sync.server.net.log

LogLevel warn

Require all granted

Options -Indexes

</Directory>

</VirtualHost>

Den Apache Virtualhost aktivieren und restarten:


$ a2ensite sync.server.net.conf
$ sudo systemctl restart apache2.service

$ a2ensite sync.server.net.conf

$ sudo systemctl restart apache2.service

Firefox Sync HTTPS Let’s Encrypt

Let’s Encrypt für unser Sync-Server bereitstellen, dazu wird das Repository hinzugefügt und die acme Pakete installiert:


$ add-apt-repository ppa:certbot/certbot
$ apt-get update
$ apt-get install python-certbot-apache

$ add-apt-repository ppa:certbot/certbot

$ apt-get update

$ apt-get install python-certbot-apache

Nun kann das Let’s Encrypt Zertifikat erstellt werden, certbot macht es uns einfach, die für unser Virtualhost erforderliche SSL-Konfiguration wird automatisch erstellt.


$ certbot --apache -d sync.server.net

1 2	$ certbot --apache -d sync.server.net

Unter /etc/apache2/sites-enabled ist nun der Symlink dieser zur Datei sync.server.net-le-ssl.conf zeigt, diese unter
/etc/apache2/sites-available gespeichert ist.


$ ls /etc/apache2/sites-enabled/sync.server.net-le-ssl.conf
/etc/apache2/sites-enabled/sync.server.net-le-ssl.conf

$ ls /etc/apache2/sites-enabled/sync.server.net-le-ssl.conf

/etc/apache2/sites-enabled/sync.server.net-le-ssl.conf

In der Datei sync.server.net-le-ssl.conf muss noch die WSGI Konfiguration hinzugefügt werden, wir editieren wieder
sync.server.net-le-ssl.conf, die danach den folgenden Inhalt zeigt:


<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName sync.server.net
DocumentRoot /opt/syncserver

        WSGIProcessGroup ffsync
        WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25 python-path=/opt/syncserver/local/lib/python2.7/site-packages/
        WSGIPassAuthorization On
        WSGIScriptAlias / /opt/syncserver/syncserver.wsgi

        CustomLog /var/log/apache2/access_sync.server.net.log combined
        ErrorLog /var/log/apache2/error_sync.server.net.log
        LogLevel warn
<Directory /opt/syncserver>
        Require all granted
        Options -Indexes
</Directory>
SSLCertificateFile /etc/letsencrypt/live/sync.server.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sync.server.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

ServerName sync.server.net

DocumentRoot /opt/syncserver

WSGIProcessGroup ffsync

WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25 python-path=/opt/syncserver/local/lib/python2.7/site-packages/

WSGIPassAuthorization On

WSGIScriptAlias / /opt/syncserver/syncserver.wsgi

CustomLog /var/log/apache2/access_sync.server.net.log combined

ErrorLog /var/log/apache2/error_sync.server.net.log

LogLevel warn

Require all granted

Options -Indexes

</Directory>

SSLCertificateFile /etc/letsencrypt/live/sync.server.net/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/sync.server.net/privkey.pem

Include /etc/letsencrypt/options-ssl-apache.conf

</VirtualHost>

</IfModule>

Jetzt muss der Apache Webserver noch einmal neu gestartet werden:


$ sudo systemctl restart apache2.service

1 2	$ sudo systemctl restart apache2.service

Firefox Browser Einstellung

Damit Firefox über den eignen Sync-Server synchronisieren kann, muss die URL geändert werden, hierzu gibt man in der Adressleiste about:config ein und bestätigt mit der Eingabetaste.

Nach dem bestätigen des Warnhinweis, gibt man
identity.sync.tokenserver.uri in das Suchfeld ein.

Mit Doppelklick ändert man den Wert zum eignen Sync-Server
https://sync.server.net/token/1.0/sync/1.5

Als letztes wird das Mozilla Konto über folgende URL angelegt:


https://accounts.firefox.com

1 2	https://accounts.firefox.com

Das Konto selbst liegt auf den Mozilla Server, die Daten werden auf dem eigenen Sync-Server gespeichert.

Wichtig ist, das die synchronisierung erst nach dem Eintrag zum eignen Sync-Server in Firefox gemacht wurde. Sollten Lesezeichen und Daten auf dem Sync-Server bei Mozilla liegen, können die Daten gelöscht werden, mit folgenden Befehlszeilen:


$ apt install python-pip 
$ sudo pip install PyFxA
$ python ./bin/delete_user_data.py email.konto@server.net

$ apt install python-pip

$ sudo pip install PyFxA

$ python ./bin/delete_user_data.py email.konto@server.net

email.konto@server.net mit tatsächlicher Konto-E-Mail ändern.

Troubleshoting & Settings

Zur überprüfung ob die Firefox Sync synchronisierung korrekt läuft, öffnet man die Log-Datei /var/log/apache2/access_sync.server.net.log:


$ sudo tail -f /var/log/apache2/access_sync.server.net.log

1 2	$ sudo tail -f /var/log/apache2/access_sync.server.net.log

Zu beachten ist, das der Let’s Encrypt certbot zur validierung, der host über Port 80 erreichbar sein muss, für die bei Ubuntu im Standard enthaltene Firewall ist das Command wie folgt:


$ sudo ufw allow http

1 2	$ sudo ufw allow http

Mit dem Aufruf der Sync Server URL, oder https://sync.server.net im Browser sollte folgende Ausgabe erscheinen:


$ curl -k https://sync.server.ent
it works!

$ curl -k https://sync.server.ent

it works!

Startet der Apache Webserver nicht, kann die Syntax der Konfiguration validiert werden:


$ apache2ctl configtest
Syntax OK

$ apache2ctl configtest

Syntax OK

Nachdem alle Konten angelegt sind, kann in der Datei syncserver.ini der Zugriff für weitere Benutzer gesperrt werden:


$ allow_new_users = false

1 2	$ allow_new_users = false

Quellen Link:
Run your own Sync-1.5 Server
Github mozilla-services/syncserver

Linux

Mit SSH-KEYGEN Schlüssel erzeugen

20. Mai 2019 DonMatteo Schreibe einen Kommentar

SSH-KEYGEN zum Erstellen der SSH Public-Key-Authentifizierung

Die Public-Key-Authentifizierung, oder auch Asymmetrisches Kryptosystem genannt, ist eine Authentifizierungsmethode, die von OpenSSH und OpenSSL verwendet wird, um Benutzer mit Hilfe eines Schlüsselpaars, bestehend aus digitalen Signaturen, privatem und öffentlichem Schlüssel, an einem Server anzumelden. Ein solches Schlüsselpaar ist wesentlich schwerer zu kompromittieren als ein Kennwort.

OpenSSH RSA-Key generieren

Der einfachste Weg ein Schlüsselpaar im OpenSSH Format zu generieren, ist die Ausführung von ssh-keygen ohne Argumente in der Shell. In diesem Fall wird nach der Datei gefragt, in der die Schlüssel gespeichert werden sollen. Wie hier in diesem Beispiel:


$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:TZ+isKhohYE6wOcKuqWxElclsdZw4UxJwFtnB9txEC8 user@debian.localdomain
The key's randomart image is:
+---[RSA 3072]----+
|   .+.o...+o.    |
|    oOo.oo.+     |
|o   o=*o..E .    |
|oo oo. . o o .   |
|o =.  . S o o    |
|=..o   . . .     |
|+++   . .        |
|oO   . .         |
|B.... .          |
+----[SHA256]-----+

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/user/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/user/.ssh/id_rsa.

Your public key has been saved in /home/user/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:TZ+isKhohYE6wOcKuqWxElclsdZw4UxJwFtnB9txEC8 user@debian.localdomain

The key's randomart image is:

+---[RSA 3072]----+

| .+.o...+o. |

| oOo.oo.+ |

|o o=*o..E . |

|oo oo. . o o . |

|o =. . S o o |

|=..o . . . |

|+++ . . |

|oO . . |

|B.... . |

+----[SHA256]-----+

SSH-Schlüssel für die Benutzerauthentifizierung werden normalerweise in der Benutzerbasis unter dem Verzeichnis .ssh gespeichert.

Das Schlüsselpaar kann auch mit der übergabe von Parameter generiert werden.


$ ssh-keygen -f ~/.ssh/key_rsa -t rsa -b 4096

1 2	$ ssh-keygen -f ~/.ssh/key_rsa -t rsa -b 4096

Die Parameter haben folgende Bedeutung:
-f die Schlüsseldatei
-t der Algorithmus
-b die Schlüssellänge
Der längste Schlüssel ist 4096. Wird kein Algorithmus übergeben, ist der Standard ein RSA Key.

Bei der Frage nach der Passphrase für den privaten Schlüssel, kann eine Passphrase eingegeben werden, im übernächsten Abschnitt wird gezeigt, wie diese generiert werden kann, durch drücken der Eingabetaste, ohne eine Passphrase wird der Schlüssel ohne Passwortschutz erstellt.

Der Zweck der Passphrase besteht normalerweise darin, den Schlüssel zu schützen. Es handelt sich um einen zweiten Authentifizierungsfaktor. Dies macht die Schlüsseldatei ohne öffentlichen Schlüssel für Angreifer unbrauchbar. Es kommt nicht selten vor das Hacker nach Dateien von kompromittierten Systemen filtern, auch aus Backups und stillgelegter Hardware.

Eine sichere Passphrase kann automatisch generiert werden, mit folgender Eingabe wird eine 32 Zeichen lange Passphrase erzeugt.


$ date +%s | sha256sum | base64 | head -c 32 ; echo

1 2	$ date +%s \| sha256sum \| base64 \| head -c 32 ; echo

Auch kann OpenSSL genutzt werden, um mit dem eingebauten Zufallsgenerator (rand) eine Passphrase zu generieren, diese wie folgt ausgegeben wird.


$ openssl rand -base64 32

1 2	$ openssl rand -base64 32

Zum privaten Schlüssel und die dazugehörende Passphrase dürfen nicht autorisierte kein Zugang haben, wird der private Schlüssel entwendet, muss ein neuer generiert werden, daraufhin der öffentliche Schlüssel ebenfalls ausgetauscht wird.

Geht nur der öffentliche Schlüssel verloren, zeigt folgende Eingabe wie der öffentliche Schlüssel mit der Option -y aus dem privaten OpenSSH Schlüssel wieder erzeugt werden kann, dazu wird die Passphrase benötigt.


$ ssh-keygen -y -f ~/.ssh/key_rsa > ~/.ssh/key_rsa.pub

1 2	$ ssh-keygen -y -f ~/.ssh/key_rsa > ~/.ssh/key_rsa.pub

Zu beachten ist, das am Ende der Datei key_rsa.pub der Kommentar (key comment) wieder hinzugefügt werden muss, nach einem Leerzeichen, wie in diesem Beispiel user@host.localdomain:


$ ssh-rsa AAAA...HPCQ== user@host.localdomain

1 2	$ ssh-rsa AAAA...HPCQ== user@host.localdomain

Die Datei key_rsa.pub darf an keiner weiteren stelle verändert werden.

ECDSA-Key generieren

Als nächstes wird ein ECDSA Schlüsselpaar mit der Schlüssellänge 521 Bit erzeugt, und unter der Benutzerbasis ~/.ssh gespeichert. Gültige längen sind 256, 384 or 521 bits.


$ ssh-keygen -f ~/.ssh/key-ecdsa -t ecdsa -b 521

1 2	$ ssh-keygen -f ~/.ssh/key-ecdsa -t ecdsa -b 521

ECDSA ist ein neuer Algorithmus für digitale Signaturen, der von der US-Regierung unter Verwendung elliptischer Kurven standardisiert wurde. Es ist wahrscheinlich aktuell der beste Algorithmus. Die meisten SSH-Clients unterstützen heute ECDSA.

Im Verzeichnis Pfad ~/.ssh wurden nun zwei Dateien erstellt. Die Datei mit der Erweiterung .pub ist der öffentliche Schlüssel. Die Datei key-ecdsa in diesem Beispiel, ist der private Schlüssel und ist nur für den Besitzer lesbar.


-rw-------.  1 user user  801 20. Mai 20:33 key-ecdsa
-rw-r--r--.  1 user user  279 20. Mai 20:33 key-ecdsa.pub

-rw-------. 1 user user 801 20. Mai 20:33 key-ecdsa

-rw-r--r--. 1 user user 279 20. Mai 20:33 key-ecdsa.pub

Der öffentliche Schlüssel key-ecdsa.pub als SHA2 Hash wird nun in der Datei authorized_keys auf dem Server im Home Verzeichnis des Benutzers unter .ssh gespeichert.


$ cat ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2vjZHNhLXNoYTItbmlzdHA1MjEFASBIbml
zdHA1MjEAfACFBAHnx0uIYUprY7D7myKMf1H+6NjCIV9U2GhZ69/oRE546i
QsvqSnSBs6SyL2ekvSe2JO3WXkrQ4gGpdLr9+XcLxfbAD79Oc8Z/Gcpr8mN
uKabOc4V/Seyr6AQ3l2KC+k8Wp0SBWG2ZofN0QYsPND8yIUL8Y7bS+t2tH9
dhSmeVwnLHUQNoktbVPoVDHw== user@host.localdomain

$ cat ~/.ssh/authorized_keys

ecdsa-sha2-nistp521 AAAAE2vjZHNhLXNoYTItbmlzdHA1MjEFASBIbml

zdHA1MjEAfACFBAHnx0uIYUprY7D7myKMf1H+6NjCIV9U2GhZ69/oRE546i

QsvqSnSBs6SyL2ekvSe2JO3WXkrQ4gGpdLr9+XcLxfbAD79Oc8Z/Gcpr8mN

uKabOc4V/Seyr6AQ3l2KC+k8Wp0SBWG2ZofN0QYsPND8yIUL8Y7bS+t2tH9

dhSmeVwnLHUQNoktbVPoVDHw== user@host.localdomain

Public-Key Transfer mit ssh-copy-id

Um die Authentifizierung mit öffentlichem Schlüssel zu verwenden, muss der öffentliche Schlüssel auf den Server kopiert und in der Datei authorized_keys gespeichert werden. Dies kann bequem mit dem Tool ssh-copy-id durchgeführt werden.


$ ssh-copy-id -i ~/.ssh/key-ecdsa user@host.foo.bar

1 2	$ ssh-copy-id -i ~/.ssh/key-ecdsa user@host.foo.bar

Nun kann man sich am Server Anmelden ohne das ein Passwort eingegeben werden muss, auch für automatisierte Aufgaben und für Anmeldungen aus Scripts ist diese Methode geeignet.


$ ssh user@host.foo.bar
Last login: Mon May 20 21:53:46 2019 from 192.168.7.85

$ ssh user@host.foo.bar

Last login: Mon May 20 21:53:46 2019 from 192.168.7.85

Bei der Fehlersuche kann der Verbose Modus hilfreich sein, dabei werden zahlreiche Debugging-Meldungen über den Fortschritt ausgegeben, wie Verbindungs-, Authentifizierungs- und Konfigurationsprobleme.


$ ssh -v user@host.foo.bar

1 2	$ ssh -v user@host.foo.bar

Mehrere -v Optionen erhöhen die Ausführlichkeit, maximal ist -vvv möglich.

OpenSSH config

Hat man unterschiedliche Hosts und Schlüsselpaare, kann in der Datei config unter ~/.ssh dies definiert werden.


$ vi ~/.ssh/config
Host *.foo.bar
  User user
  Port 22
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa
  IdentityFile key-ecdsa

Host host.fooo.bar
  User user
  Port 22
  HostKeyAlgorithms +ssh-dss
  PubkeyAcceptedKeyTypes +ssh-dss
  IdentityFile id_dss

$ vi ~/.ssh/config

Host *.foo.bar

User user

Port 22

HostKeyAlgorithms +ssh-rsa

PubkeyAcceptedKeyTypes +ssh-rsa

IdentityFile key-ecdsa

Host host.fooo.bar

User user

Port 22

HostKeyAlgorithms +ssh-dss

PubkeyAcceptedKeyTypes +ssh-dss

IdentityFile id_dss

Linux

Run Nano as root in vnc session

12. Mai 2019 DonMatteo Schreibe einen Kommentar

How to Run Nano File Manager as root in a VNC Session

In this post I show how to run Nano file manager as root in a VNC session. I’m using a Fedora Cinnamon Spin to this logged in as an common user via VNC viewer.

Fire up a terminal and insert the command below at the end of .bashrc by hit nano ~/.bashrc


export XAUTHORITY=/home/vncuser/.Xauthority

1 2	export XAUTHORITY=/home/vncuser/.Xauthority

this example use vncuser, enter your username instead.

close the terminal and re-open again, hit the command line below to run nemo as root:


~]$ sudo pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nemo

1 2	~]$ sudo pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nemo

As the video shows below.