Ich trage mich schon lange mit dem Gedanken einen virtuellen Server mit vollem Root-Zugriff zu mieten. Da ich schon einen Hostingvertrag bei 1&1 habe (shared Host), bietet es sich an auch für dieses Projekt eine Lösung bei 1&1 zu suchen. Ich habe mich für die zweit kleinste zur Zeit angebotene Konfiguration, den Cloud Server M, entschieden. Der erste Monat ist kostenfrei, zum probieren. Der Vertrag ist monatlich kündbar, damit ist das Risiko für eine größere Fehlinvestition gering.
Als Betriebssystem kommt nur Linux in Frage, ich habe Ubuntu 14.04 gewählt. Der Server wird wirklich sehr schnell, innerhalb einer Minute, eingerichtet und man kann im Anschluss über das 1&1 Cloudpanel darauf zugreifen.
Eine erste Entäuschung kann ich nicht verhehlen, es gibt nur eine IPv4 Adresse, kein IPv6. Das ist eigentlich unverständlich. An IPv6 Adressen herrscht kein Mangel und sie kosten die grossen Provider so gut wie nichts.
Doch beginnen wir jetzt einfach mal mit der Basiskonfiguration des Servers. Die IP-Adresse und das initiale Passwort für den Server findet man im Cloudpanel, siehe oben. Nach dem Einloggen begrüßt uns der Server mit einer Statusmeldung, die eine Reihe an Systeminformationen bereithält.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-77-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Wed Feb 17 17:56:47 UTC 2016 System load: 0.0 Processes: 248 Usage of /: 4.9% of 36.90GB Users logged in: 0 Memory usage: 16% IP address for eth0: xxx.xxx.xxx.xxx 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. |
Das sieht schon einmal gut aus. Als erstes wollen wir nun die public key authentication für unseren ssh Zugriff auf den Server einrichten. Hierzu wäre es interessant zu wissen, welche sshd version installiert ist.
1 2 | $ dpkg -l | grep openssh-server ii openssh-server 1:6.6p1-2ubuntu2.6 amd64 secure shell (SSH) server, for secure access from remote machines |
Die Version 6.6p1 ist installiert. Diese Version unterstützt ED25519 keys, welche ich für meine Schlüssel benutzen möchte und moderne Algorithmen. Zunächst passe ich meine ssh client Konfiguration auf meinem lokalen Rechner an, damit möglichst sichere, moderne Verschlüsselungsverfahren genutzt werden. Sehr praxisbezogene, nützliche Informationen hierzu findet man im mozilla wiki auf den folgenden beiden Seiten:
Security/Guidelines/Key Management
Meine ssh client Konfiguration ~/.ssh/config sieht dann wie folgt aus:
1 2 3 4 5 6 7 8 | # Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to. HashKnownHosts yes # Host keys the client accepts - order here is honored by OpenSSH HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,ssh-dss KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr |
Der HostKey Algorithmus ssh-dss, und die beiden MACs hmac-md5 und hmac-sha1 sind hier nur enthalten, um mit der gleichen Konfiguration zu meinem shared Host account verbinden zu können. Dort hat 1&1 offensichtlich noch sehr alte ssh Server Versionen im Einsatz, die moderne Verfahren noch nicht unterstützen.
Nun erstellen wir eine Schlüsselpaar mit dem in OpenSSH enthaltenen ssh-keygen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_test -C "cloud" Generating public/private ed25519 key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rainer/.ssh/id_ed25519_test. Your public key has been saved in /home/rainer/.ssh/id_ed25519_test.pub. The key fingerprint is: SHA256:zY1PpbSvybSmmSyl6A4z+qmfb83LqEf6kRPUPT+XYLY cloud The key's randomart image is: +--[ED25519 256]--+ | | | . . | | . . o = . | | . o O * . | | . S + E o | | .o .o + | | +o++ o o . | | ..*+==. =.+ | | o+*O* oo=o= | +----[SHA256]-----+ |
Da ich lokal keinen ssh-agent benutze, verzichte ich hier auf eine Passphrase. Das bedeutet aber, dass der private Schlüssel keinem Unberechtigten in die Hände fallen darf. Derjenige könnte sich damit bei allen mit dem zugehörigen public key konfigurierten Rechnern verbinden.
Anschließend müssen wir noch den öffentlichen Schlüssel, den Inhalt der Datei id_ed25519_test.pub, auf dem Server in ~/.ssh/authorized_keys eintragen. Am bequemsten erfolgt dies mit ssh-copy-id, ebenfalls aus dem OpenSSH Paket. Die IP-Adresse ist durch xxx.xxx.xxx.xxx ersetzt.
1 2 3 4 5 6 7 8 9 | $ ssh-copy-id -i ~/.ssh/id_ed25519_test root@xxx.xxx.xxx.xxx /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@xxx.xxx.xxx.xxx's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'root@xxx.xxx.xxx.xxx'" and check to make sure that only the key(s) you wanted were added. |
Jetzt können wir uns ohne Passwort mit dem folgenden Befehl auf dem Server einloggen:
1 | $ ssh -i ~/.ssh/id_ed25519_test root@xxx.xxx.xxx.xxx |
Voilà, jetzt können wir unseren Server über ssh verwalten ohne ein Passwort eingeben zu müssen. In einem zweiten Schritt wollen wir die Authentifizierung mit einem Passwort über ssh komplett unterbinden. Hierzu müssen wir die Konfiguration des sshd auf unserem Server anpassen.
In der Datei /etc/ssh/sshd_config finden wir die folgende Zeile:
1 | #PasswordAuthentication yes |
Diese Zeile ändern wir in:
1 | PasswordAuthentication no |
Anschließend müssen wir dem sshd noch mitteilen, dass er seine Konfiguration neu laden soll. Dies tun wir mit dem folgenden Befehl:
1 | $ service ssh reload |
Nun kontrollieren wir noch, ob unsere Änderung die gewünscht Wirkung zeigt. Vor unserer Änderung wurde bei falschem Schlüssel nach dem Passwort gefragt:
1 2 | $ ssh root@xxx.xxx.xxx.xxx root@xxx.xxx.xxx.xxx's password: |
Nach unserer Änderung wird der Zugang bei falschem Schlüssel konsequent verwehrt:
1 2 | $ ssh root@xxx.xxx.xxx.xxx Permission denied (publickey). |
Zum Ende diesen ersten Teils, erstelle ich im Cloudpanel noch einen Snapshot unseres Servers. Dazu sollten wir den Server zunächst anhalten.
Wenn wir hier Ausschalten wählen erscheint ein der folgende Dialog:
Hier bestätigen wir mit ja und nach ein paar Sekunden erhalten wir eine Rückmeldung, dass der Server ausgeschaltet wurde. Jetzt können wir einen Snapshot erstellen.
Wenn wir hier Snapshot erstellen wählen erscheint der folgende Dialog:
Wie in diesem Dialog angegeben, wird ein Snapshot nach 3 Tagen wieder gelöscht. Hier bestätigen wir ebenfalls mit ja und nach wenigen Sekunden erhalten wir eine Bestätigung, dass der Snapshot angelegt wurde. Anschließend können wir den Server wieder starten.
Im 2. Teil meiner Artikelreihe werden wir uns mit Backup, Netzwerk und Firewall beschäftigen.