VServer aufsetzen Teil 1: OpenSSH Publickey Auth

So Leute ich habe mir einen neuen VServer gegönnt auf dem ich Owncloud zum laufen bringen möchte. Mich stört es halt das Dropbox seine Server in den USA stehen hat, mir nur 2GB kostenlos gibt und es seit Jahren nicht schafft einen Sync Client für ARM basierte Geräte wie die Seagate Dockstar oder beliebiege NAS Systeme raus zu bringen.

Was macht man da? Man mietet sich günstig einen Server (habe einen für knapp 4€/Mtl. mit 30GB HDD Speicher) und setzt es selbst auf.

Aber vorher sollte man sich darum kümmern das der neu angeschafft VServer ein bisschen abgesichert wird. Dafür schaut man sich zuerst einmal an was so alles auf dem Server läuft:

root@vserver:~# ps ax
PID TTY      STAT   TIME COMMAND
1 ?        Ss     2:32 init [2]
14664 ?        Sl     0:00 /usr/sbin/rsyslogd -c4
14690 ?        Ss     0:00 /usr/sbin/cron
25809 ?        Ss     0:00 /usr/sbin/sshd
26036 pts/5    R+     0:00 ps ax
26192 ?        Ss     0:00 sshd: root@pts/5
26234 pts/5    Ss     0:00 -bash

Das sieht schonmal sehr gut aus, der Hoster hat Wort gehalten und das verwendete Debian ist wirklich sehr minimal. Wir sehen das hier nur rsyslog, cron und der SSH Daemon laufen. So sollte es sein, das heisst nämlich das wir kein überflüssiges Zeug deinstallieren oder absichern müssen.

Da naheliegenste Einfallstor ist bei diesem System natürlich der SSH Daemon, hat man Ihn überwunden hat man vollen Zugriff auf den VServer. Schneller als man sich umschauen kann wird der eigene VServer dann zur Spam- Schleuder oder nimmt an DDoS Angriffen teil, und das wollen wir ja nicht. Nur mal so, mein VServer lieg nach dem Aufsetzen durch den Hoster gerade mal eine Stunde und in dieser Zeit konnte ich schon acht fehlgeschlagene Login Versuche zählen, die meisten aus China.

Solange man ein gutes Passwort für seinen SSH Account vergeben hat ist das kein großes Problem, sicherer ist es jedoch auf die Zertifikats basierte PubKey Authentifizierung zu nutzen. Da hat zwar den Nachteil das man für die Einwahl zum Server immer die geheime Key Datei griffbereit haben muss, aber da man Verwaltungsaufgaben meistens eh vom gleichen Rechner ausführt sehe ich das nicht als Problem an.

Die Umstellung auf das PublicKey Verfahren ist auf Unix (wie Mac OS) bzw. Linux Rechner mit installiertem OpenSSH schnell erledigt.

Folgender Befehl erstellt die benötigten Zertifikate:

macbookpro:.ssh user$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/user/.ssh/id_rsa): /Users/user/.ssh/vserver
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/user/.ssh/vserver.
Your public key has been saved in /Users/user/.ssh/vserver.pub.
The key fingerprint is:
64:03:9a:ca:3f:d4:33:a5:29:fb:3b:b6:40:ce:55:c5 user@macbookpro.local
The key's randomart image is:
+--[ RSA 2048]----+
|      .  ..      |
|     o . .E      |
|    o   *        |
| . . . B .       |
|  o + B S        |
|   * + o         |
|    B            |
|     +o          |
|     .++         |
+-----------------+

Es müssen nicht viele Fragen nach dem Aufruf von ssh-keygen beantwortet werden. Im ersten Schritt habe ich nur den Namen geändert unter dem das neue Schlüsselpaar gesichert wird, so kann ich am Ende der Laufzeit die Schlüssel problemlos löschen und komm nicht in die versuchung die Schlüssel für den nächsten Server wieder zu verwenden. Wenn Ihr bei jedem Verbindungsaufbau ein Passwort zum unlocken des Schlüsselpaares eingeben wollt dann könnt Ihr das natürlich tun. Es erhöht die Sicherheit fall auch euer privater Schlüssel abhanden kommt.

Anschließen habt Ihr euer neues Schlüsselpaar in dem von euch gewählten Ordner.

Nun muss euer öffentlicher Schlüssel auf den Server, das geht besonders einfach mithilfe des ssh-copy-id Befehls der bei Linux installationen vorhanden ist. Leider fehlt das Script unter Mac OS X. Man kann es sich entweder von einem Linux System besorgen, oder hier downloaden https://gist.github.com/1639381

Das Skript muss danach nur noch in den Ordner /usr/bin kopiert und via chmod +x /usr/bin/ssh-copy-id ausführbar gemacht werden.

Mit der foldenden Kommandozeile kopiert man die Public ID dann auf den Server:

ssh-copy-id -i /Users/user/.ssh/vserver root@euervserver.com

Danach könnt Ihr direkt ausprobieren ob der Login per Zertifikat nun klappt:

ssh -i /Users/user/.ssh/vserver root@euervserver.com

Hat das funktioniert dann könnt Ihr direkt eingeloggt bleiben denn die nächsten Schritte finden auf dem VServer statt. Jetzt müssen wir die Passwortauthentifizierung abschalten so das man sich nur noch mit dem richtigen Zertifikat anmelden kann.

Dazu öffnen wir mit unserem Lieblingseditor auf der Kommandozeile (ich nehme nano) die Datei /etc/ssh/sshd_config.

Dort müssen wir nur sicher stellen das PubkeyAuthentication auf yes und PasswordAuthentication auf no stehen. Bei PasswordAuthetication muss auch noch die führende # entfernt werdern.

Die gesamte Config sieht dann folgendermaßen aus:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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'.
UsePAM yes

So nun nur noch den SSH Daemon die neuen einstellungen laden lassen:

/etc/init.d/ssh reload

und beim nächsten verusch euch nur mit einem Password anzumelden solltet ihr eine Fehlermeldung sehen

macbookpro:.ssh user$ ssh root@euervserver.com
Permission denied (publickey).

Somit haben wir das größte Problem schon einmal beseitigt.

Übrigens gibt es auch noch eine andere einfache Maßnahme um Angreifern das Leben schwerer zu machen. Ändert in der sshd.conf einfach den SSH Port von 22 auf irgendeinen anderen ungenutzten Port. So werdet Ihr aus dem Fokus der meisten Angreifer verschwinden.