Normalen (nicht root) Benutzer anlegen
Bevor wir uns um das Absichern/Härten des SSH Zugangs kümmer können ist es wichtig einen regulären Benutzer auf dem System anzulegen. Dies erledigt man auf der Kommandozeile mit folgendem Befehl:
adduser fragmichnicht Adding user `fragmichnicht' ... Adding new group `fragmichnicht' (1002) ... Adding new user `fragmichnicht' (1002) with group `fragmichnicht' ... Creating home directory `/home/fragmichnicht' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information for fragmichnicht Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y
SSH Schlüssel erzeugen und einbinden
Als nächsten Schritt legen wir uns einen private und einen public-key an um diesen für die Anmeldung via ssh verwenden zu können. Passwörter sind schon lange nicht mehr wirklich sicher und die Verwendung von solchen keys ist zudem deutlich praktischer als die Verwendung von vermeintlich sicheren Passwörtern. Die Schlüssel erstellen Sie entweder über die Linux Kommandozeile oder über das Windows tool Putty Key Generator.
Den Private-Key schützt man auf seinem lokalen System am besten weiterhin mit einem Passwort und speichert ihn an einem sicheren Ort. Der Schlüssel sollte nach Möglichkeit wirklich privat sein und nicht aus den Händen gegeben werden. Den Public-key zu veröffentlichen ist dagegen kein wirkliches Problem (wie der Name schon impliziert).
cd /home/fragmichnicht/ mkdir .ssh chmod 700 .ssh chown fragmichnicht:fragmichnicht .ssh cd .ssh vi authorized_keys
Hier fügen wir nun den public key zu dem Schlüsselpaar welches wir gerade erstellt haben ein.
Danach fügen wir den neu angelegten Benutzer der Gruppe sudo hinzu damit dieser sich jederzeit via sudo root Rechte besorgen kann.
usermod -a -G sudo fragmichnicht
Sollte sudo noch nicht installiert sein so erledigt dies ein:
apt-get install sudo
Wenn ihr für die Benutzer der Gruppe sudo nicht wollt, dass diese ein Passwort eingeben müssen um sich root Rechte zu besorgen, dann erreicht man dies über folgende Zeile in der /etc/sudoers (Änderungen an dem file über visudo!)
# Allow members of group sudo to execute any command %sudo ALL=(ALL) NOPASSWD: ALL
Härten der SSH-config
An sich sollte sich ein root-Benutzer nie direkt remote an einem System anmelden können und auf einem Server benötigt man auch keine grafische Oberfläche (X11). Ich poste nachfolgend meine sshd-config mit allen Werten (die geänderten fett gedruckt). Je nach System und Version müssen ggf. mehr Werte angepasst werden um zu dieser Konfiguration zu kommen. Die Änderungen an der Konfiguration müssen mit root-Rechten und folgendem Befehl durchgeführt werden:
vi /etc/ssh/sshd-config
# 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 HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 1024 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no 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 no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #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
Damit die Einstellungen wirksam werden muss der SSH Dienst neu gestartet werden. Dies erreicht man mit dem Befehl:
/etc/init.d/ssh restart
Damit sind die Grundlagen für einen sicheren SSH-Zugang zu dem eigenen Server gelegt.