Bei SSH handelt es sich um ein Netzwerkprotokoll, mit dem über eine verschlüsselte Verbindung die Konsole eines entfernten Computers bedienen kann. Außerdem gibt es die Möglichkeit Port-Weiterleitungen einzurichten und über SFTP Dateien zu übertragen. Spätestens, wenn man einen Server betreibt wird man diese Vorteile zu schätzen wissen, sollte diesen aber auch absichern, damit Hacker erst gar keine Chance haben.
Login über einen anderen Benutzer
Zu aller Anfang sollte man den Login von root komplett verbieten. Dazu legt man zunächst einen neuen Benutzer unter Ubuntu an, mit dem man sich in Zukunft über SSH einloggt. Von diesem Zugang aus kann man dann immer noch mittels sudo su zum Superuser root werden. Man legt zuerst einen neuen Benutzer mit einem Benutzernamen und einem Kennwort an
sudo adduser benutzername
Geben Sie ein neues UNIX Passwort ein: benutzerpasswort
Geben Sie das neue UNIX Passwort erneut ein: benutzerpasswort
passwd: Kennwort erfolgreich geändert
Ändere Benutzerinformationen für benutzername
Geben Sie einen neuen Wert an oder ENTER für den Standardwert
Name []: Benutzer Name
Raumnummer []:
Telefon geschäftlich []:
Telefon privat []:
Sonstiges []:
Sind die Informationen korrekt? [j/N] j
Da der neu angelegte Benutzer später den Befehl sudo ausführen soll, muss man ihn noch zur admin-Gruppe hinzufügen
sudo adduser benutzername admin
Nun sollte man sich einmal mit dem neuen Benutzer einloggen und testen, ob es auch geht. Hat alles geklappt, wird man root und bearbeitet die Konfigurationsdatei von sshd
sudo su
vi /etc/ssh/sshd_config
Die Zeile
PermitRootLogin yes
wird geändert zu
#PermitRootLogin yes
PermitRootLogin no
Dann wird die Datei abgespeichert und wieder geschlossen. Damit die Änderungen übernommen werden, muss entweder der komplette Rechner oder, was wesentlich praktischer ist, der ssh-Dienst neugestartet werden. Jetzt sollte man sich nicht mehr als root einloggen können.
Hinweis: Der ssh-Dienst erhält bestehende Verbindungen weiterhin aufrecht, selbst wenn er neu gestartet wurde. Man kann also zur Sicherheit die bestehende Verbindung geöffnet lassen, um im Notfall die Konfigurationsdatei noch erreichen zu können. Wenn alles geklappt hat, kann man die Verbindung schließen.
/etc/init.d/ssh restart
Ab jetzt kann man nur noch per
sudo su
zum Superuser werden.
Authentifizierung über öffentliche Schlüssel
Zunächst ein Schlüsselpaar (öffentlicher & privater Schlüssel) erstellt werden.
Erstellung eines Schlüsselpaares unter Windows mit Putty
Als Erstes startet man das Programm PuttyGen. Dann wählt man unter dem Punkt Parameters den Schlüsseltyp SSH2 DSA aus. Mit einem Klick auf Generate wird das Schlüsselpaar erzeugt. Da PuttyGen Mausbewegungen nutzt, um einen Zufälligkeitsfaktor zu generieren, muss man die Maus solange über die graue Fläche bewegen, bis der Balken 100% erreicht hat.
Als Key Comment sollte man eine Beschreibung des Schlüssels eingeben (z.B. benutzername@servername) und als Passphrase ein sicheres Kennwort für den privaten Schlüssel. Zum Schluss werden privater und öffentlicher Schlüssel abgespeichert.
Man loggt sich nun auf dem Server ein ohne root zu werden und erstellt im Home-Verzeichnis des Benutzers ein neues Verzeichnis mit dem Namen .ssh und darin eine neue Datei authorized_keys
mkdir $HOME/.ssh
vi $HOME/.ssh/authorized_keys
Anschließend kopiert man den Inhalt aus dem Fenster im Bereich Public key for pasting ... in die erstellte Datei.
Wichtig: Der gesamte Inhalt muss in der ersten Zeile der Datei stehen. Danach werden noch die Rechte für die Datei gesetzt.
chmod g-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys
Um das Schlüsselpaar unter Putty zu verwenden läd man dort die gespeicherte Sitzung für den Server. Anschließend geht man in den Optionen zu "Connection" > "SSH" und wählt unter Preferred SSH Version den Eintrag 2 only aus. Unter "Connection" > "SSH" > "Auth" wählt man unter Private key file for authentication den entsprechenden privaten Schlüssel (Dateiendung: .ppk) aus. Unter "Options" > "Session" und speichert man die veränderten Einstellungen der Sitzung ab.
Beim Einloggen gibt man als Benutzer den Namen des Benutzers an, in dessen Home-Verzeichnis der öffentlichen Schlüssel gespeichert ist. Das zugehörige Passwort ist das bei der Erstellung des Schlüsselpaares angegebene (nicht das Passwort des Benutzers auf dem Server). Es dient nur dazu den privaten Schlüssel vor Missbrauch zu schützen.
Erstellung eines Schlüsselpaares unter Linux mit OpenSSH
Man öffnet eine Kommandozeile und erstellt ein neues DSA-Schlüsselpaar
ssh-keygen -d
Dabei wird man dazu aufgefordert einen Verzeichnisnamen anzugeben, in dem das Schlüsselpaar erstellt werden soll. Mit Eingabetaste bestätigt man den Standardwert. Anschließend muss das Kennwort eingegeben werden, das dazu dient den privaten Schlüssel vor Missbrauch zu schützen.
Im angegebenen Verzeichnis findet sich nun das neue Schlüsselpaar. Der private Schlüssel heißt id_dsa, der öffentliche id_dsa.pub. Man überträgt den öffentlichen Schlüssel ins Home-Verzeichnis auf dem Server. Dazu empfiehlt es sich eine verschlüsselte Übertragungstechnik wie SCP oder SFTP zu verwenden.
scp $HOME/.ssh/id_dsa.pub benutzername@192.168.178.150:id_dsa.pub
Als Nächstes wird der Schlüssel an die Datei authorized_keys im Verzeichnis .ssh angehängt und dem Server so als autorisierten Schlüssel übergeben. Man loggt sich dabei auf dem Server ein, ohne root zu werden
mkdir $HOME/.ssh
touch $HOME/.ssh/authorized_keys
cat $HOME/id_dsa.pub >> $HOME/.ssh/authorized_keys
Berechtigungen vergeben
chmod g-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys
Nun ist der Server konfiguriert und man kann eine Verbindung starten
mv $HOME/.ssh/id_dsa $HOME/.ssh/192.168.178.150-dsa
chmod g-r $HOME/.ssh/192.168.178.150-dsa
ssh 192.168.178.150 -p 22 -l benutzername -i $HOME/.ssh/192.168.178.150-dsa
Hat alles geklappt, können die Einstellungen in die eigene angepasste Client-Konfigurationsdatei (~/.ssh/config) eintragen werden
vi $HOME/.ssh/config
# Einstellungen für 192.168.178.150
Host homeserver
Hostname 192.168.178.150
IdentityFile2 /home/client-benutzername/.ssh/192.168.178.150-dsa
Port 22
PreferredAuthentications publickey
Protocol 2
User benutzername
Jetzt kann man sich ganz einfach mit dem Server verbinden
ssh homeserver
Laufzeitkonfiguration von ssh
In meiner Konfiguration habe ich einige Anpassungen zur Verbesserung der Sicherheit vorgenommen. Unter anderem verwende ich den Port 2222 anstatt den Standard-Port 22, damit Port-Scans ins Leere laufen.
# What ports, IPs and protocols we listen for
Port 2222
Außerdem soll nur das sichere SSH2 verwendet werden
# use ssh2 only
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Ein Benutzer hat nur 30 Sekunden Zeit, um sich einzuloggen. Ansonsten wird die Verbindung abgebrochen. Es kann sich zudem immer nur ein Benutzer gleichzeitig einloggen.
# Authentication:
LoginGraceTime 30
# allow one login at a time
MaxStartups 1
#PermitRootLogin yes
PermitRootLogin no
AllowUsers benutzername
StrictModes yes
Die Client-Konfiguration (z.B. in Putty oder der Konfigurationsdatei für OpenSSH) muss natürlich daraufhin noch angepasst werden.
Meine aktuelle Konfiguration als Beispiel (Download):
# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port 2222
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
# use ssh2 only
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
# Authentication:
LoginGraceTime 30
# allow one login at a time
MaxStartups 1
#PermitRootLogin yes
PermitRootLogin no
AllowUsers benutzername
StrictModes yes
# enable pubkey authentication
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# disable other authentications
RSAAuthentication no
PrintMotd no
KeepAlive yes
# 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_*
# enable sftp subsystem Subsystem
Subsystem sftp /usr/lib/openssh/sftp-server
# logging
SyslogFacility AUTH
LogLevel INFO
UsePAM yes
/etc/init.d/ssh restart
Die Konfiguration von sshd ist nun abgeschlossen.
SSH Begrüßungsnachricht ändern
Wer nicht daran interessiert ist, bei jedem Login darüber aufgeklärt zu werden, dass die Ubuntu-Entwickler für keinerlei Schaden haften, der kann in der Datei /etc/motd eine eigene Begrüßungsnachricht angeben oder den Inhalt einfach löschen. Dort steht nämlich, was dem Benutzer nach dem Login via ssh angezeigt wird.
sudo vi /etc/motd
Linux NetServer 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
Links
