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
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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 sudo-Gruppe hinzufügen
|
1 |
sudo adduser benutzername sudo |
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
|
1 2 |
sudo su vi /etc/ssh/sshd_config |
Die Zeile
|
1 |
PermitRootLogin yes |
wird geändert zu
|
1 2 |
#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.
|
1 |
/etc/init.d/ssh restart |
oder
|
1 |
service ssh restart |
Ab jetzt kann man nur noch per
|
1 |
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 RSA aus und gibt als Schlüssellänge 4096 Bits an. 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
|
1 2 |
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.
|
1 |
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 RSA-Schlüsselpaar
|
1 |
ssh-keygen -t rsa -b 4096 |
Man wird dazu aufgefordert, einen Verzeichnisnamen anzugeben, in dem das Schlüsselpaar erstellt werden soll. Mit Eingabetaste kann man den Standardwert bestätigen. Alternativ besteht die Möglichkeit, durch anhängen von -f client-rsa direkt einen besseren Namen zu vergeben. Anschließend muss das Kennwort eingegeben werden, um den privaten Schlüssel zu schützen.
Im angegebenen Verzeichnis findet sich nun das neue Schlüsselpaar. Der private Schlüssel heißt standardmäßig id_rsa, der öffentliche id_rsa.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.
|
1 |
scp $HOME/.ssh/id_rsa.pub benutzername@192.168.178.150:id_rsa.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
|
1 2 3 |
mkdir $HOME/.ssh touch $HOME/.ssh/authorized_keys cat $HOME/id_rsa.pub >> $HOME/.ssh/authorized_keys |
Berechtigungen vergeben
|
1 |
chmod g-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys |
Nun ist der Server konfiguriert und man kann eine Verbindung starten
|
1 2 3 |
mv $HOME/.ssh/id_rsa $HOME/.ssh/192.168.178.150-rsa chmod g-r $HOME/.ssh/192.168.178.150-rsa ssh 192.168.178.150 -p 22 -l benutzername -i $HOME/.ssh/192.168.178.150-rsa |
Hat alles geklappt, können die Einstellungen in die eigene angepasste Client-Konfigurationsdatei (~/.ssh/config) eintragen werden
|
1 |
vi $HOME/.ssh/config |
|
1 2 3 4 5 6 7 8 |
# Einstellungen für 192.168.178.150 Host homeserver Hostname 192.168.178.150 IdentityFile2 /home/client-benutzername/.ssh/192.168.178.150-rsa Port 22 PreferredAuthentications publickey Protocol 2 User benutzername |
Jetzt kann man sich ganz einfach mit dem Server verbinden
|
1 |
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.
|
1 2 |
# What ports, IPs and protocols we listen for Port 2222 |
Außerdem soll nur das sichere SSH2 verwendet werden
|
1 2 3 4 5 6 |
# use ssh2 only Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_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.
|
1 2 3 4 5 6 7 8 |
# 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):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 |
# Package generated configuration file # See the sshd_config(5) 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 #HostKey /etc/ssh/ssh_host_ecdsa_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 30 # allow one login at a time MaxStartups 1 PermitRootLogin no # or 'without-password' to allow SSH key based login 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 # Cipher selection Ciphers aes256-ctr,aes128-ctr MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 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 # 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 |
|
1 |
/etc/init.d/ssh restart |
oder
|
1 |
service 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.
|
1 |
sudo vi /etc/motd |
|
1 |
Linux NetServer 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 |
Links
- Patrick Fey: Den Secure Shell Dämon sicher einrichten
- Hetzner DokuWiki: SSH richtig einrichten
- ubuntuusers.de Wiki: Benutzer und Gruppen
- BetterCrypto.org: Applied Crypto Hardening [PDF]
Pingback: Anonymous