Wechseln zu: Navigation, Inhalt, Suche
Permalink

1

HowTo: OpenSSH-Server konfigurieren (mit Authentifizierung über öffentliche Schlüssel)

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.

Ubuntu Home-Server

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 sudo-Gruppe hinzufügen

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

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

oder

service 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 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

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 RSA-Schlüsselpaar

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.

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

mkdir $HOME/.ssh
touch $HOME/.ssh/authorized_keys
cat $HOME/id_rsa.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_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

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-rsa
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
#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.

# 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_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

/etc/init.d/ssh restart

oder

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.

sudo vi /etc/motd

Linux NetServer 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686

1 Kommentar

Schreibe einen Kommentar