Den Zugriff auf SSH über das Internet freizugeben ist sicher keine gute Idee.
Besser wäre die Lösung über ein VPN.
Wer jedoch das Risiko in Kauf nehmen möchte dem wird hier gezeigt wie man den SSH Daemon härten kann um das Risiko zu minimieren.
OpenSSL Heartbleed fixen
Ist mitlerweile in den Repro's gefixet, ich lass es mal stehen.
Achtung die Version ist aus dem Testing Zweig von Jessie
Display Spoiler
Der PI hat auch nach dem letzten Update wohl noch eine verwundbare Version von OpenSSL.
Ich kann nicht mit Sicherheit sagen ob diese version gefixed ist oder nicht.
Laut OpenSSL ist die 1.0.1e verwundbar.
Vorher :
root@pi-wz:/home/pi# openssl version
OpenSSL 1.0.1e 11 Feb 2013Nachher :
root@pi-wz:/home/pi# openssl version
OpenSSL 1.0.1k 8 Jan 2015Damit diese auf die aktuelle Version gebracht werden kann einfach folgende Schritte ausführen :
sudo nano /etc/apt/sources.list
folgende Zeilen anfügen
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
deb http://archive.raspbian.org/raspbian jessie main contrib non-free rpidann mal einmal die Listen aktialisieren
sudo apt-get updateUnd jetzt openssl aktualisieren, aus dem jessie Zweig.
Wenn wir dabei sind, SSH direkt mit.
apt-get -t jessie install openssl libssl1.0.0 openssh-client openssh-server sshDanach die Repro's aus der sources.list wieder entfernen oder Auskommentieren
SSH härten
1. einen extra User für den SSH Zugriff erstellen
*****
Dieser Schritt ist Optional. Es kann sich nachher nur dieser User, auch aus dem lokalen Netzwerk am PI per SSH anmelden. Wer das nicht möchte kann diesen Schritt überspringen und ab 2) mit dem User PI weitermachen.
*****
Warum ?
Der User PI hat das Recht mittels sudo root Befehle auszuführen.
Dies ist natürlich übel, sollte der User einmal kompromittiert werden.
Daher erstellen wir einen Benutzer für den SSH Zugriff welcher dieses Recht nicht besitzt.
sudo adduser sshuserund folgen den Anweisungen.
Jetzt werden wir zum sshuser um weiter zu arbeiten.
su sshuser2. Authentifizierung mittels Keys statt Passwort
Wir wechseln in das Home Verzeichnis des User und erstellen ein Verzeichnis .ssh
cd ~
mkdir .ssh
cd .sshJetzt erstellen wir das Schlüsselpaar.
( Das geht auch mit PuTTy, siehe >>hier )
Hier sollte unbedingt eine passpharse vergeben werden. Dieses schützt den Key zusätzlich.
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsaIm Verzeichnis befinden sich jetzt zwei Dateien.
id_rsa = Der Key des Benutzers
id_rsa.pub = DerPublic Key des Benutzer
Den Public Key kommt nun in das authorized_keys file des PI
cat id_rsa.pub >>authorized_keys
chmod 600 authorized_keysDie Datei id_rsa beinhaltet den Privaten Schlüssel welchen wir für den SSH Zugriff des Klienten benötigen und muss auf den Rechner kopiert werden welcher dann auf den PI zugreift. Das könnt ihr am besten per SCP machen.
Nun bringen wir dem SSH Daemon bei nur noch Key Auth zu akzepieren.
Dazu müssen wir die Config Datei bearbeiten.
Da der sshuser keine Rechte hat wechseln wir erst mal wieder zum User PI und öffnen die Config Datei des SSH Daemon
su pi
und wir werden PI.
als erstes sichern wir uns die Config Datei :
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Damit können wir alles wieder zurücksetzen falls wir uns irgendwo vertun.
Es ist immer eine gute Idee Dateien for der Änderung zu sichern 
"Zurücksetzen"
sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_configDort ändern wir folgende Zeilen :
Protocol 2
PermitRootLogin No
AuthorizedKeysFile %h/.ssh/authorized_keys
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
!!!! ACHTUNG !!!!
Nach einen Neustart des Daemon ist es nur noch möglich sich als sshuser mit dem Key einzuloggen !!!
Den Daemon neustarten
sudo /etc/init.d/ssh restartJETZT DIE AKTUELLE CONSOLE NICHT BEENDEN
Mit der zur Zeit aktiven Konsole könnt ihr noch die Änderungen rückgängig machen falls etwas nicht funktioniert.
Macht eine neue Verbindung auf und versucht euch anzumelden.
Nach dem Einloggen als sshuser könnt ihr mit
su pi
zum User PI wechseln und wie gewohnt weiterarbeiten.
3. Den Daemon paranoider einstellen
Wir stellen jetzt den SSH Daemon ein wenig paranoider ein.
Dazu öffnen wir wieder die Config Datei.
sudo nano /etc/ssh/sshd_configAllowUsers sshuser
Beschränkt den SSH Zugriff auf den User sshuser
LoginGraceTime 30
Gibt dir 30 Sekunden Zeit nach Aufbau der Verbindung zum Anmelden.
Wird in der Zeit nix gemacht trennt der PI die verbindung
MaxAuthTries 3
Nur drei Anmeldeversuche
MaxStartups 3:30:10
Ist sehr schwer zu erklären aber eine sehr effektive Einstellung.
"Aus der Man Page"
Specifies the maximum number of concurrent unauthenticated con-
nections to the sshd daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10.
Alternatively, random early drop can be enabled by specifying the
three colon separated values "start:rate:full" (e.g.,
"10:30:60"). sshd will refuse connection attempts with a proba-
bility of "rate/100" (30%) if there are currently "start" (10)
unauthenticated connections. The probability increases linearly
and all connection attempts are refused if the number of unau-
thenticated connections reaches "full" (60)
4. Fail2Ban installieren
Fail2ban ist ein Program was die Logfiles überwacht und nach X ungültigen Anmeldeversuchen die IP des Clienten per IPTables für xx Minuten aussperrt.
Ein sehr wirkungsvolles Program was nicht fehlen sollte.
Es kann nicht nur den SSHD überwachen sondern u.a. auch FTP und den Webserver.
Fail2ban installieren :
sudo apt-get install fail2banWir sichern die Konfiguratiion :
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf,bak"Zurücksetzen"
sudo cp /etc/fail2ban/jail.conf,bak /etc/fail2ban/jail.conf
Die Konfiguration :
sudo nano /etc/fail2ban/jail.conf
Die wichtigsten Einstellungen :
ignoreip = 127.0.0.1/8 192.168.0.1/24 #Hier sollte unbedingt euer Lokales Netzwerk mit eingetragen werden.
bantime = 600 # Wie lange bleibt die IP gesperrt
maxretry = 3 # Wieviele Fehlversuche ?
Die Voreinstellungen sind so OK.
Wessen PI Email versenden kann sollte folgende Zeile wie folgt ändern :
action = %(action_mwl)s
Jetzt zum SSH "Jail"
[ssh]
enabled = true # true schaltet den "Jail" ein
port = ssh # Der Port, wer seinen SSH Clienten auf einen anderen als Port 22 hören lässt muss diesen hier eintragen, z.B. 9922
filter = sshd # der Filter für das Log
logpath = /var/log/auth.log # Das Log in dem die Anmeoldeversuche protokolliert werden.
maxretry = 3 # Drei anmelde Versuche erlaubt
Wenn ihr euch in der Datei umseht dann findet ihr einige vorgefertigte Jails für die unterschiedlichsten Dienste.
ein
/etc/init.d/fail2ban restart
Übernimmt die Änderungen.
Dieses setzt auch alle Blocks zurück !
Damit sollte euer PI Fit für das Internet sein.
Behaltet nur immer in Hinterkopf das NICHTS 100% Sicher ist.
Wem die permanenten Meldungen jetzt auf den Sack gehen der kann seinen SSH Port noch verschleiern.
Dieses würde ich jedoch im Router machen und den PI weiterhin auf Port 22 lauschen lassen.
Im Router würde dann eine Freigabe eingreichtet welche vom öffentlichen Port 33322 auf den lokalen Port 22 zeigt.
Damit kommt dann etwas Ruhe rein, ist aber bei weitem nicht so interessant
Fragen ? Bitte hier stellen, niicht per PN oder Mail.
Fehler gefunden ? Bitte per PN und nicht den Thread flooden.
Rechtschreibfehler ? Ich hab ne Rechtschreibschwäche ( ehrlich ), von daher geht mir das am Popo vorbei