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
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 
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.
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,bakDie 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