Login › seeseekey.net

Unter Linux existieren eine Reihe von Nutzern. So nutzt der Nutzer des Systems einen Nutzer und auch viele andere Dienste legen Nutzer an, wie z.B. www-data. Wenn für einen Dienst ein Nutzer angelegt werden soll, so könnte der Nutzer wie folgt angelegt werden:

adduser example

Damit würde ein vollwertiger Nutzer mit einem Passwort erzeugt werden. Soll nun ein Nutzer ohne Passwort erzeugt werden, so muss der adduser-Befehl um eine Option erweitert werden:

adduser --disabled-password example

Damit wird ein Nutzer ohne Passwort angelegt. Trotzdem wäre es noch möglich sich über diesen Nutzer anzumelden. Wenn dies nicht gewünscht ist, kann der Nutzer dementsprechend angelegt werden:

adduser --disabled-login example

Dem Nutzer ist es damit nicht mehr möglich sich einzuloggen. Allerdings kann durchaus mittels su in den Kontext des Nutzers gewechselt werden, z.B. um im Kontext des Nutzers einen Dienst zu installieren.

Der Unterschied zwischen den beiden Optionen ist, dass die Option disabled-password nur das Passwort deaktiviert, aber Logins über ein SSH-Schlüsselpaar zulassen würde. Bei der Option disabled-login ist dies nicht der Fall. Hier ist kein Login mehr möglich. Rückgängig gemacht werden kann die Beschränkung des Nutzers, indem für den Nutzer ein Passwort gesetzt wird.

Im technischen Bereich wird des Öfteren von den Begriffen Authentisierung, Authentifizierung und Autorisierung geredet. Das Problem an diesen Begrifflichkeiten ist das sie gerne durcheinander gebracht werden. Doch was bedeuten die Begriffe nun konkret? Fangen wir mit dem Begriff Authentisierung an.

Der Prozess, bei dem eine Person einen Nachweis vorlegt, dass die dargestellte Identität korrekt ist, die Authentisierung. Im IT-Kontext kann dies z.B. durch einen Login mit einem Nutzernamen und einem Passwort bewerkstelligt werden. In der physischen Welt wäre für die Authentisierung z.B. ein Ausweis geeignet. Wenn die von der Person gelieferten Daten wie ein Login oder ein Ausweis geprüft werden, so stellt dies eine Authentifizierung dar.

Authentisierung und Authentifizierung am Beispiel der Kommunikation eines Nutzers mit einem Server

Nachdem die Identität bestätigt wurde, muss im letzten Schritt ermittelt werden, ob die Person die entsprechende Berechtigung besitzt. Dies ist die sogenannte Autorisierung. Erst wenn die Authentisierung, Authentifizierung und Autorisierung erfolgreich durchgeführt wurden, kann die entsprechende Aktion durchgeführt werden.

Um sich mit einem Rechner per SSH zu verbinden, kann ein Passwort oder ein kryptografisches Schlüsselpaar genutzt werden. Aus Gründen der Sicherheit sollte ein Login über SSH per Passwort im Normalfall nicht möglich sein. Stattdessen sollte sich immer über das Schlüsselpaar identifiziert werden. Dazu wird ein privater und ein öffentlicher Schlüssel generiert. Der öffentliche Schlüssel wird beim Zielserver in der Datei:

.ssh/authorized_keys

hinterlegt. Für die nötigen kryptografischen Operationen wird schließlich der private Schlüssel genutzt, welcher auf dem eigenen Rechner verbleibt. Normalerweise wird so nur ein Schlüsselpaar genutzt. Allerdings kann es durchaus vorkommen, das nicht nur ein Schlüssel, sondern mehrere unterschiedliche Schlüssel für die Verbindung zu unterschiedlichen Servern verwendet werden soll. Diese müssen dann auf dem eigenen Rechner vorgehalten werden. In diesem Fall muss der SSH-Client darüber informiert werden mit welchem Schlüssel die Anmeldung erfolgen soll. Normalerweise würde der Client wie folgt genutzt werden:

ssh root@example.com

In diesem Fall würde der Standardschlüssel aus dem ~/.ssh/-Verzeichnis genutzt werden. Soll nun ein bestimmter Schlüssel genutzt werden so muss der Parameter -i angegeben werden:

ssh -i .ssh/otherkey root@example.org

Damit kann der Schlüssel spezifiziert werden, welcher für die Verbindung genutzt werden soll. Eine andere Möglichkeit ist es für die einzelnen Server eine Konfiguration in der Datei ~/.ssh/config zu hinterlegen.

Host example.com
IdentityFile ~/.ssh/id_rsa

Host example.org
IdentityFile ~/.ssh/otherkey

So können unterschiedliche Schlüssel für unterschiedliche Server genutzt werden.

Wenn man sich auf einem Ubuntu-Server einloggt, bekommt man meist folgende Zeilen zu sehen:

Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-31-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Oct  3 11:23:01 CEST 2013

  System load:  0.0                Processes:           95
  Usage of /:   71.0% of 969.52GB  Users logged in:     0
  Memory usage: 1%                 IP address for eth0: 192.168.1.50
  Swap usage:   0%

  Graph this data and manage this system at https://landscape.canonical.com/

0 packages can be updated.
0 updates are security updates.

Last login: Sat Sep 28 15:26:35 2013 from localhost

Unter Umständen kann es aber auch passieren das man diese Meldung nicht sieht. Den auszugebenen Text findet man dabei in der Datei “/etc/motd”. Dort kann man das Verhalten beim Login allerdings nicht konfigurieren. Um die Meldung zu aktivieren, muss stattdessen die Datei “/etc/pam.d/login” im Editor angepasst werden. Dort findet man die Zeilen:

# Prints the message of the day upon succesful login.
# (Replaces the `MOTD_FILE' option in login.defs)
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional   pam_motd.so  motd=/run/motd.dynamic noupdate
session    optional   pam_motd.so

welche je nach Bedarf ein oder auskommentiert werden können. Sind diese Zeilen bereits einkommentiert, so liegt das Problem am Fehlen des Kommandos “landscape-sysinfo”. Sobald das passende Paket “landscape-common” nachinstalliert wurde, funktioniert das Anzeigen der Systeminformationen nach einem Login wieder.