Benutzer-Werkzeuge

Webseiten-Werkzeuge


thoschwiki:linux:ssh

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
Letzte Überarbeitung Beide Seiten, nächste Überarbeitung
thoschwiki:linux:ssh [12.04.2021 12:22]
thosch 'Sicherung des ssh-Zugangs' und 'root-Remote-Zugriff unterbinden' ergänzt.
thoschwiki:linux:ssh [12.04.2021 16:57]
thosch Quellen verschoben und erweitert
Zeile 9: Zeile 9:
 Per Default wird nach dem Aufbau des ssh-Verbindung eine interaktive Login-Session für den entsprechenden User aufgebaut. In manchen Fallgestaltungen ist ein eingeschränkterer Zugriff gewünscht. Mittels //Forced Commands// können die verfügbaren Befehle durch Vorgaben in der ''~/.ssh/authorized_keys'' eingeschränkt werden. Per Default wird nach dem Aufbau des ssh-Verbindung eine interaktive Login-Session für den entsprechenden User aufgebaut. In manchen Fallgestaltungen ist ein eingeschränkterer Zugriff gewünscht. Mittels //Forced Commands// können die verfügbaren Befehle durch Vorgaben in der ''~/.ssh/authorized_keys'' eingeschränkt werden.
  
-**Quellen zu Forced Commands**: 
- 
-  * [[https://www.thomas-krenn.com/de/wiki/Ausführbare_SSH-Kommandos_per_authorized_keys_einschränken|Thomas-Krenn-Wiki - Ausführbare SSH-Kommandos per authorized keys einschränken ]] 
-  * [[http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/|Guy Rutenberg - Restricting SSH Access to rsync]] 
-  * [[https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/|#!/bin/blog - OpenSSH: Going Flexible With Forced Commands]] 
  
 ===== Sicherung des ssh-Zugangs ===== ===== Sicherung des ssh-Zugangs =====
Zeile 21: Zeile 16:
 ==== root-Remote-Zugriff unterbinden ==== ==== root-Remote-Zugriff unterbinden ====
  
-Auf vielen Systmen ist //root// der einzige Account mit Remote-Zugriff und einem bekannten Benutzernamen. Damit ist er ein gutes Ziel für Brute-Force-Angriffe((99% aller Login-Versuche aus dem Internet, die ich auf meinen Systemen beobachtet habe, richteten sich gegen //root//)). Wenn dieser Account gehackt wird, ist er aufgrund der umfassenden Benutzerrechte eine besonders lohnender Beute. Auf anderen Systemen ist der Account bereits "deaktiviert".((Nach meiner Erfahrung auf allen //debianösen// (Desktop)Systemen. Nach meiner Erfahrung ist er aber gerade auf Cloud-/VPS-Instanzen aktiv.))+Auf vielen Systmen ist //root// der einzige Account mit Remote-Zugriff und einem bekannten Benutzernamen. Damit ist er ein gutes Ziel für Brute-Force-Angriffe((99% aller Login-Versuche aus dem Internet, die ich auf meinen Systemen beobachtet habe, richteten sich gegen //root//)). Wenn dieser Account gehackt wird, ist er aufgrund der umfassenden Benutzerrechte eine besonders lohnender Beute. Auf anderen Systemen ist der Account bereits "deaktiviert".((Nach meiner Erfahrung auf allen //debianösen// (Desktop)Systemen. Aber gerade auf Cloud-/VPS-Instanzen ist dieser Account oft aktiv.))
  
-Dort, wo der //root//-Account noch aktiv ist, sollte man für diese Benutzerkennung den Remote-Zugriff unterbinden.((…oder den Account //root// gleich ganz zu deaktivieren.)) Die notwendigen administrativen Aufgaben können mit einem "normalen" Account unter Verwendung von ''sudo'' erledigt werden.((Das sollte man aus Sicherheitsgründen sowieso machen…))+Dort, wo der //root//-Account noch aktiv ist, sollte für diese Benutzerkennung den Remote-Zugriff unterbunden werden.((…oder der Account //root// gleich ganz deaktiviert werden.)) Die notwendigen administrativen Aufgaben können mit einem "normalen" Account unter Verwendung von ''sudo'' erledigt werden.((Das sollte man aus Sicherheitsgründen sowieso machen…))
  
-Um den //ssh//-Remote-Zugang für //root// zu sperren, setzt man in der Datei ''/etc/ssh/sshd_config'' den Eintrag ''PermitRootLogin'' auf ''no''+Um den //ssh//-Remote-Zugang für //root// zu sperren, setzt wird in der Datei ''/etc/ssh/sshd_config'' den Eintrag ''PermitRootLogin'' auf ''no'' gesetzt.
  
 <code> <code>
Zeile 31: Zeile 26:
 </code> </code>
  
-Anschließend startet man den //ssh//-Daemon neu((Wie der Restart erfolgt, variiert je nach dem technischen Umfeld.)) (oder rebootet ersatzweise den Rechner).+<note important> 
 +Bevor der Remote-Zugriff für //root// gesperrt wird, sollte ausreichend getestet werden, ob das Administrieren mit ''sudo'' tatsächlich funktioniert. 
 +</note> 
 + 
 +Die Änderung wird erst mit dem Restart des //ssh//-Daemons ((Wie der Restart erfolgt, variiert je nach dem technischen Umfeld.)) (oder ersatzweisem Reboot des Rechnersaktiv. 
 + 
 +==== ssh-Zugriff mit Passwort unterbinden ==== 
 + 
 +Die [[ubuntuusers>SSH/#PubKeys|Authentifizierung über Public-Keys]] erleichtert nicht nur den //ssh//-Zugang, sondern vermindert durch den Wegfall der Passworteingabe auch die Angriffsfläche des //ssh-//-Servers, weil damit die Möglichkeit der Brute-Force-Angriffe reduziert wird. Dieser Sicherheitsvorteil kann nur realisiert werden, wenn die Passwort-Authentifizierung unterbunden wird. 
 + 
 +Hierfür werden in der Datei ''/etc/ssh/sshd_config'' die Einträge ''ChallengeResponseAuthentication '' und ''PasswordAuthentication'' jeweils auf ''no'' gesetzt. 
 + 
 +<code> 
 +ChallengeResponseAuthentication  no 
 +PasswordAuthentication no 
 +</code> 
 + 
 +<note> 
 +Zur Frage, ob zusätzlich in der Datei ''/etc/ssh/sshd_config'' den Eintrag ''UsePAM'' auf ''no'' zu setzen ist, finden sich unterschiedliche Antworten. Nach meiner Erfahrung funktioniert es unabhängig von der Stellung des Eintrags ''UsePAM''
 + 
 +Ich empfehle hier, sich sicherheitshalber selbst ein Bild zu machen.  
 +</note>
  
 <note important> <note important>
-Bevor man den Remote-Zugriff für //root// sperrt, sollte man ausreichend testen, dass das Administrieren mit ''sudo'' tatsächlich funktioniert.+Bevor der Zugang mit Passwort gesperrt wird, sollte der Zugang mit //Public-Keys// erfolgreich von mehreren Rechnern aus getestet werden und in der ''~/.ssh/authorized_keys'' die //Public-Keys// mehrerer Rechner abgelegt worden sein. Anderenfalls besteht die Gefahr, dass man sich aus dem eigenen System ausschließt, wenn der Zugriff ausschließlich remote möglich ist.
 </note> </note>
  
 +Die Änderung wird erst mit dem Restart des //ssh//-Daemons ((Wie der Restart erfolgt, variiert je nach dem technischen Umfeld.)) (oder ersatzweisem Reboot des Rechners) aktiv.
 +
 +===== Quellen =====
 +
 +==== zu Forced Commands ====
 +
 +  * [[https://www.thomas-krenn.com/de/wiki/Ausführbare_SSH-Kommandos_per_authorized_keys_einschränken|Thomas-Krenn-Wiki - Ausführbare SSH-Kommandos per authorized keys einschränken ]]
 +  * [[http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/|Guy Rutenberg - Restricting SSH Access to rsync]]
 +  * [[https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/|#!/bin/blog - OpenSSH: Going Flexible With Forced Commands]]
 +
 +==== zu Sicherung des ssh-Zugangs ====
 +
 +  * [[https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/|nixCraft: How to disable ssh password login on Linux to increase security]]
 +  * [[https://www.strato.de/faq/server/wie-kann-ich-den-ssh-dienst-auf-meinem-linux-server-absichern/|Strato Hilfe: Wie kann ich den SSH-Dienst auf meinem Linux Server absichern?]]
 +  * [[ubuntuusers>SSH/#PubKeys|ubuntuusers: SSH - Authentifizierung über Public-Keys]]
 +  * [[https://serverfault.com/questions/475880/ssh-public-key-auth-fails-when-usepam-is-set-to-no|serverfault: SSH public key auth fails when UsePAM is set to “no”]]
  
thoschwiki/linux/ssh.txt · Zuletzt geändert: 16.05.2021 18:40 von thosch