Category Archives: Opensuse 12.3

Erfahrungen mit OS 12.3

Opensuse 12.3-Upgrade – lvmetad-Warnung nach grub2-mkconfig

Posted on by

Ich bin ja gerade beim Upgraden diverser Seitensysteme (von Kunden wie im eigenen Netz) auf Opensuse Leap 42.2. Dabei kam mir auch ein unter KVM/qemu virtualisierter LAMP-Testserver unter Opensuse 12.3 unter die Finger. Beim Upgrade dieses KVM-Gastes waren zunächst die üblichen Hürden zu überwinden:
– Notwendige Abänderungen der Apache2-Konfiguration auf die aktuelle Syntax bzgl. des Zugangs zu Verzeichnissen (Wechsel zu Apache2-Versionen > 2.4)
– Manuelles Nacharbeiten des Upgrades der Mysql DB bzw. Maria DB zur Version 5.6 bzw. 10.0.30 mittels “mysql_upgrade -u root -p”.

Meldung zu lvmetad

Dann aber stolperte ich im Rahmen der Upgrades über eine mir bislang unbekannte Warnung im Zusammenhang mit der grub2-Konfiguration während der Upgrades:

/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

Das verhinderte zwar keinen Neustart der Zwischenversionen Opensuse 13.1, 13.2 Leap 42.1; aber sauber erschien mir das dann doch nicht. Ein manueller Test unter Leap 42.2 mittels “grub2-mkconfig -o /boot/grub2/grub.cfg” ergab dieselbe Meldung.

Was ist lvmetad?

lvm2-lvmetad ist offenbar ein Caching-Service für Metadaten (“central metadata cache”), die aus physikalischen Volumes [PV] einer LVM-Volume-Group ausgelesen werden. Siehe hierzu:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/metadatadaemon.html

Das Caching führt zu einer Beschleunigung der Ausführung von LVM bzw. LVM-Kommandos.

Dieser Service bzw. ein zugehöriger Socket sollten auf moderneren Opensuse-Systemen offenbar immer aktiviert sein. Ein Statuscheck auf von Scratch installierten Opensuse-Systemen der Versionen 13.1, 42.1, 42.2-Systemen ergab, dass diese Services/Sockets dort laufen – unabhängig davon, ob tatsächlich “Logical Volume Groups” und ” Logical Volumes [LV]” genutzt werden oder nicht.

Auf meinem alten 12.3-System waren die entsprechenden Services aber offenbar nicht aktiviert (“enabled”). (Oder aber der Upgrade hat da was verbockt.)

Dass ein laufender lvmetad-Dienst/Socket vorausgesetzt wird, gilt offenbar selbst dann, wenn das Opensuse-System – wie in meinem Fall – virtualisiert ist und selbst gar kein LV auf den vom Host per virtio-(blk)-Treiber durchgereichten Blockdevices nutzt (also auch kein sog. “nested” LVM für den Fall, dass das Blockdevice selbst auf einem LV des Hostes beruht).

Problemlösung: Aktivieren von lvmetad

Die Lösung war jedenfalls trivial; es half die Durchführung folgender Kommandos 

systemctl enable lvm2-lvmetad.socket
systemctl enable lvm2-lvmetad.service
systemctl start lvm2-lvmetad.socket
systemctl start lvm2-lvmetad.service

auf dem von OS 12.3 auf Leap 42.2 upgegradetem System. Ein “grub2-mkconfig -o /boot/grub2/grub.cfg” lief danach ohne jede Warnung oder Fehlermeldung durch.

Fühlbare Performance-Vorteile habe ich auf dem unter KVM virtualisierten System erwartungsgemäß nicht feststellen können; das nutzt zwar ein LV einer LVM Volume Group des KVM-Hostes als Raw-Device über virtio-(blk)-Treiber. In dieser Situation ist es viel wichtiger, dass lvmetad auf dem KVM-Host selbst läuft.

Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication

Posted on by

Im letzten Beitrag dieser Serie

Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login

hatten wir den SSH-Zugang über einen bereits verschobenen Port nur noch einem bestimmten unpriviligierten User [Bsp: “xtarjax”] zugestanden und den SSH-Zugang für root deaktiviert.

In diesem Beitrag ersetzen wir den normalen SSH-Login mit passwort-basierter Authentisierung durch eine Authentifizierung, bei der asymmetrische SSH-Schlüssel benutzt werden. Der Sicherheitsgewinn, den wir uns dadurch versprechen ist der, dass ein Login ab jetzt nur noch personalisiert und von Systemen aus möglich ist, auf denen

  • ein File mit dem privaten Schlüssel existiert,
  • eine Passphrase zur Aktivierung des Schlüssels bekannt ist.

Der verschobene SSH-Port ist dann auf dem Server zwar noch offen, aber ein Zugang geht nicht mehr von überall her und nicht mehr über die Angabe einer User-Id und eines Passworts. Wir zeigen die erforderlichen Schritte auf einem Linux-Client und dem Server.

Schlüsselgenerierung auf einem Opensuse-Client

Als normaler User erzeugen wir uns ein SSH-Schlüsselpaar mittels des Befehls “ssh-keygen”. Ohne Parameter aufgerufen, wird durch ssh-keygen ein RSA-Schlüsselpaar mit je 2048 Bit Länge für SSH2 erzeugt: 

mysystem:~> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/myself/.ssh/id_rsa): /home/myself/.ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 
Your identification has been saved in /home/myself/.ssh/id_rsa.
Your public key has been saved in /home/myself/.ssh/id_rsa.pub.
The key fingerprint is:
77:1a:cb:72:6b:00:5a:22:7d:34:85:11:a4:5e:28:ea myself@mysystem.mydomain.de
The key's randomart image is:
+--[ RSA 2048]----+<br>
|         .++     |<br>
|         ....    |<br>
|        . +.     |<br>
|  .   .o o..     |<br>
|   o .o.S.       |<br>
|    +..*  .      |<br>
|    .+= S.      |<br>
|     oo..        |<br>
|     ...         |<br>
+-----------------+<br>
mysystem:~>

Bei höheren Ansprüchen kann man die Schlüssellänge (z.B. 4096 Bit) entsprechend vorgeben. Man benutzt dazu die Option “-b” (s. die man-Seite).

Hinweis 1:
Hat man bereits mehrere private SSH-Schlüssel für unterschiedliche Zwecke generiert, so muss man die Key-Files natürlich unter anderen Namen anlegen lassen, um ein Überschreiben des vorhandenen Keys zu vermeiden. Abweichende Namen setzen dann ggf. beim Aufnehmen der SSH-Verbindung die Option “-i” und die Angabe des richtigen privaten Key-Files voraus.

Hinweis 2:
Die Passphrase muss man sich unbedingt merken. Sie sollte hinreichend lang (deutlich länger als bei einem Passwort) sein und Sonderzeichen beinhalten. Von dieser Passphrase hängt die die Einsetzbarkeit und im Kompromittierungsfall auch die Sicherheit künftiger key-basierter SSH-Verbindungen ab. Die private Schlüssel-Datei wird mit dieser Passphrase verschlüsselt (!) im oben gewählten Verzeichnis hinterlegt. Ohne Kenntnis der Passphrase ist der Schlüssel nicht im Rahmen der SSH-Authentifizierung einsetzbar.

Kopieren des öffentlichen Schlüssels auf den Remote Server – hier den Strato-V-Server

Von einem anderen Terminalfenster loggen wir uns nun auf dem Strato-Server ein:

mysystem:~> ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx
xtarjax@hxxxxx:~>mkdir .ssh 
xtarjax@hxxxxx:~>cd .ssh
xtarjax@hxxxxx:~/.ssh>touch 600 
authorized_keys

Vom anderen lokalen Terminal kopieren wir nun das File mit dem öffentlichen (public) key auf den Server:

mysystem:~> scp -P 6xxxx ./.ssh/id_rsa.pub xtarjax@hxxxxx.stratoserver.net:/home/xtarjax/.ssh
Password: 
id_rsa.pub

Man beachte das großgeschriebene “P” in der Option für die Portangabe.

Wir wechseln wieder zu unserem Terminal mit der Remote-Verbindung: 

xtarjax@hxxxxx:~/.ssh>cat id_rsa.pub >> authorized_keys
xtarjax@hxxxxx:~/.ssh>cat authorized_keys
xtarjax@hxxxxx:~/.ssh>rm id_rsa.pub
xtarjax@hxxxxx:~/.ssh>exit

Test der key-basierten Authentifizierung

Nun testen wir den Login mit den asymmetrischen Keys: 

mysystem:~>ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx 
Enter passphrase for key '/home/myself/.ssh/id_rsa': 
Last login: Mon Nov  4 17:10:34 2013 from mysystem.mydomain.de
Have a lot of fun...
xtarjax@hxxxxxxx:~>

Bei der Rückfrage nach der Passphrase ist natürlich die Passphrase für den privaten Key anzugeben.

Hinweis:
Hat man einen von “id_rsa” abweichenden Namen bei der Generierung verwendet (oder mehrere private Key Files im Einsatz oder ein anderes verzeichnis zur Ablage gewählt) so muss man die Option “-i” verwenden: 

mysystem:~>ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx  -i  PFAD/KEY_FILE 
Enter passphrase for key 'PFAD/KEY_FILE': 
Last login: Mon Nov  4 17:10:34 2013 from mysystem.mydomain.de
Have a lot of fun...
xtarjax@hxxxxxxx:~>

PFAD/KEY_FILE geben dabei den Pfad zu dem zu verwendenden File mit dem privaten SSH-Key an.

Wichtig – Sicherung der Keyfiles :
Auf unserem lokalen System sichern wir die generierten Schlüssel an einem sicheren (verschlüsselten) Ort. Es ist entscheidend, dass wir den privaten Key bei Bedarf aus einer gesicherten Datei rekonstruieren können. Sonst ist später je nach Einstellung für den SSH-Dämon ggf. kein Zugang mehr zum Server möglich.

Im lokalen “~/.ssh”-Verzeichnis können wir danach den public key auch löschen. Benötigt wird die Datei für den privaten Key. Die Rechte am entsprechenden File kontrollieren wir und setzen sie bei Abweichungen ggf. auf “600”.

Änderung der SSHD-Konfiguration auf dem Server

Hat der zertifikatsbasierte SSH-Zugang zum Server einwandfrei funktioniert, können wir nun die passwortbasierte Authentifizierung in der SSH-Konfiguration des Servers abschalten. Dazu editieren bzw. ergänzen wir als root die Datei “/etc/ssh/sshd_cofig” auf dem Server bzgl. folgender Einträge : 

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys<br>
&
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

UsePAM no

Hinweis:
UsePAM kann man in der oben angegebenen Konfiguration auch auf “yes”setzen. Man beachte hierzu aber die Hinweise in der Datei: 

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.

Wem das alles immer noch nicht reicht – oder wenn man seinen Usern hinsichtlich der Komplexität der selbst gewählten Passphrase für ihre Key-Dateien nicht traut – der kann zusätzlich ein Passwort setzen und dessen Eingabe verlangen. Dies geht dann mit 

AuthenticationMethods publickey,password

in der sshd.conf. Siehe auch
https://access.redhat.com/site/ documentation/en-US/ Red_Hat_Enterprise_Linux/6/html/ Deployment_Guide/s2-ssh-configuration-keypairs.html

SSH unter Windows

Will man SSH von einem Windos-Client aus einsetzen, benutzt man das Opensource-Programm Putty – sowohl um Keys zu generieren als auch um die SSH-Verbindung auf dem Client zu parametrieren.

Achtung:
Ein direkter Einsatz einer ggf. auf einem Linux-Client erzeugten privaten SSH-Key-Datei – wie unsere obige “id_rsa”-Datei – ist unter PUTTY nicht möglich. Dennoch kann man die Datei verwenden: Das erfordert jedoch erst einen Import und dann ein Abspeichern in dem für PUTTY geeigneten Format. Man lese sich hierzu die ausführlichen Hilfeseiten von PUTTY durch.

ACHTUNG – Nachtrag Okt. 2016: Erheblich veränderte Sicherheitslage seit 2015

Diese kleine Artikelserie zur Einrichtung eines gehosteten Servers ist nun schon etwas älter. Wer meint, durch die obigen Maßnahmen bereits ein sicheres System zu haben, irrt deshalb. Durch die heutigen Möglichkeiten sind u.a. bestimmte Algorithmen der initialen Schlüsselbestimmung über das in SSH eingebaute Diffie-Hellman-Merkle-Verfahren nicht mehr als sicher einzustufen.

OpenSSH sollte daher unbedingt in der aktuellsten Variante 7.2p eingesetzt werden. Das entsprechende Paket findet sich im den SuSE “network”-Repository für aktuelle Opensuse Versionen (ab 13.1 bis Leap 42.2 und Tumbleweed). Siehe die Repos unter http://download.opensuse.org/ repositories/ network/

Zudem sollten auf dem Server in der “/etc/ssh/sshd_config” sowie auf den Client-Systemen in der “/etc/ssh/ssh_config” etliche weitere Einstellungen zur Härtung des SSH-Systems vorgenommen werden. Lesen Sie sich hierzu bitte den folgenden Artikel sorgfältig durch:
https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html

Die meisten der dortigen Anweisungen sind einfach umzusetzen und schaden zumindest nicht, wenn man die Konfiguration der SSH-Clients unter seiner eigenen Kontrolle hat. Davon gehe ich bei gehosteten Servern aus.

Ich werde mich bemühen, an passender Stelle mal ein Update zu einer SSH-Konfiguration nachzuliefern, die aktuellen Anforderungen gerecht wird.

Links

https://help.ubuntu.com/community/ SSH/OpenSSH/Keys

http://en.wikibooks.org/wiki/OpenSSH/ Cookbook/Authentication_Keys

http://www.linuxproblem.org/ art_9.html

https://access.redhat.com/site/ documentation/ en-US/Red_Hat_Enterprise_Linux/ 6/html/ Deployment_Guide/s2-ssh-configuration-keypairs.html

http://kaotickreation.com/ 2008/05/21/ disable-ssh-password-authentication-for-added-security/

http://support.hostgator.com/ articles/ specialized-help/technical/how-to-disable-password-authentication-for-ssh

http://wiki.centos.org/HowTos/ Network/SecuringSSH

http://askubuntu.com/ questions/ 101670/ how-can-i-allow-ssh-password-authentication-from-only-certain-ip-addresses

http://superuser.com/ questions/ 303358/ why-is-ssh-key-authentication-better-than-password-authentication

http://forums.opensuse.org/ english/ get-technical-help-here/ network-internet/ 489448-sshd-password-authentication-still-working.html

https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html

 

Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login

Posted on by

Im letzten Beitrag zur Konfiguration unseres Strato-Servers
Strato-V-Server mit Opensuse 12.3 – II
hatten wir uns ein wenig mit dem SSH-Zugang befasst und als erste Maßnahme den SSH-Port verschoben. Wir hatten gleichzeitig aber festgestellt, dass das keine ausreichend sichere Lösung ist. Einer der Gründe war u.a. der, dass “root” immer noch Zugang zu dem Server hat. Dies ist ein Sicherheitsrisiko, das wir im nächsten Schritt ausschalten wollen. Es ist ja auch gar nicht erforderlich, sich direkt als root auf dem Server einzuloggen. Vielmehr sollte der Zugang über einen unprivilogierten User vorgenommen werden. Von dessen Account wechselt man dann auf der Shell zum Root-Account.

Anlegen eines normalen, unpriviligierten Users

Bevor wir den direkten root-Zugang beenden können, müssen wir erst einen normalen User anlegen. Den User nenne ich nachfolgend der Einfachheit halber “xtarjax”. Generell gilt auch hier, dass man einen Namen wählen sollte der nicht leicht zu erraten ist.

Die Erzeugung des user-Accounts nehmen wir z.B. mittels “yast >> Sicherheit und Benutzer >> User- und Gruppenverwaltung” vor. Oder wir checken auf der Shell per “useradd -D” kurz die Standardeinstellungen für die Useranlage und benutzen dann das Shell-Kommando

hxxxxxxx:~# useradd -m xtarjax

Das Passwort für den User setzen wir mit

hxxxxxxx:~# passwd xtarjax

“passwd” checkt das zu verwendende Passwort nach vorgegebenen Kriterien. Mit einem weiteren “passwd -S xtarjax” fragen wir dann den Zustand des angelegten Users ab. Ich gehe auf Details der Useranlage nicht weiter ein. Wir prüfen noch, dass unter “/home” das Homeverzeichnis “/home/xtarjax” angelegt wurde.

Nun weiß ich, dass einige Leute gerne mit der grafischen Version “yast2” von YaST arbeiten. Ich rate bei der Arbeit auf einem Remoteserver aus drei Gründen davon ab:

  • Es birgt Sicherheitsrisiken (auch wenn man das X-Protokoll unter ssh tunnelt).
  • Es erhöht den Datentransfer zwischen Server und Client doch beträchtlich und die Antwortzeiten sind nicht berauschend.
  • Es ist überflüssig, weil das ASCII yast für die Shell praktisch alle erforderlichen Möglichkeiten bietet.

Wenn man temporär doch mit grafischer Unterstützung arbeiten will, gilt:
Man muss SSH so konfigurieren, dass X-Forwarding erlaubt wird. Standardmäßig ist das abgeschaltet. Man muss dazu in der Datei “/etc/ssh/sshd-config” folgenden Eintrag von “no” auf “yes” ändern.

X11Forwarding yes

Dies macht man am besten mit “vi” oder “emacs”. Danach

hxxxxxxx:~# rcsshd restart

oder

hxxxxxxx:~# systemctl restart sshd.service

ausführen und testen, dass ein Einloggen vom eigenen Client-System aus mittels

mylinux:~ # ssh -X root@xxxxxxx.stratoserver.net -p nnnnn

unter dem im letzten Beitrag definierten Port funktioniert. Danach kann man

hxxxxxxx:~# yast2 &

ausprobieren und die Antwortzeiten für seine Internetverbindung bzw. die 100MBit Anbindung des Stratoservers testen. Berauschend ist das nicht – aber es funktioniert zur Not. Wie gesagt: Ich rate vom Einsatz grafischer Tools ab. Will oder muss man zwischenzeitlich mit X11-Forwarding arbeiten, sollte man es danach durch Setzen von “X11Forwarding no” in der “sshd_config” wieder rückgängig machen.

Abschalten des ssh-Zugangs für root

Wir schalten nun den SSH-Zugang für den priviligierten User “root” in 2 Schritten ab. Zunächst editieren wir die Datei “/etc/ssh/sshd_config” und fügen folgende Zeile ein – z.B. nach dem Statement “Port 6XXXXX”:

Port 6XXXX
AllowUsers xtarjax root

Dann starten wir den ssh-Service neu mittels

hxxxxxxx:~# rcsshd restart

Wir loggen uns aus dem Strato-server aus und versuchen einen Login per

mylinux:~ # ssh xtarjax@xxxxxxx.stratoserver.net -p nnnnn

Dies sollte anstandslos gelingen. Ist das sichergestellt wechseln wir zum root-Account mittels

mylinux:~ #su –

und editieren als root dann erneut “/etc/ssh/sshd_config”. Dort entfernen wir root aus der Liste der AllowedUsers und fügen ein Zusatzstatement ein – bzw. editieren die im File ggf. auskommentierte Zeile in folgender Form

Port 6xxxx
AllowUsers xtarjax
…
…
PermitRootLogin no

Danach starten wir den ssh Service erneut und beten, dass wir über den normalen User reinkommen. Dann machen wir den Gegencheck und versuchen

mylinux:~ # ssh root@xxxxxxx.stratoserver.net -p nnnnn

Das sollte zum Scheitern verurteilt sein. Interessanterweise wird das Passwort mit zwischenzeitlicher Zeitverzögerung 3 mal abgefragt – – auch bei Eingabe des korrekten Passwords. Danach erfolgt ein zwischenzeitlicher Abbruch des Zugangsversuchs.

Mit diesem Schritt haben wir unsere Grundsicherheit wieder etwas erhöht. Root hat keinen direkten Serverzugang per SSH mehr. Im nächsten Beitrag stellen wir den SSH-Zugang zusätzlich auf ein schlüssel- bzw. zertifikats-basiertes Zugangsverfahren um:
Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication