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
thoschwiki:linux:ssh [12.04.2021 12:22]
thosch 'Sicherung des ssh-Zugangs' und 'root-Remote-Zugriff unterbinden' ergänzt.
thoschwiki:linux:ssh [16.05.2021 18:40]
thosch [root-Remote-Zugriff unterbinden] Typo
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, 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