Benutzer-Werkzeuge

Webseiten-Werkzeuge


thoschwiki:linux:ssh

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung
Vorherige Überarbeitung
Letzte Überarbeitung Beide Seiten, nächste Überarbeitung
thoschwiki:linux:ssh [14.02.2021 12:19]
thosch angelegt
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**:+ 
 +===== Sicherung des ssh-Zugangs ===== 
 + 
 +Um die Angriffsfläche eines (//ssh//)-Servers zu verringern, kann man die folgenden beiden Maßnahmen ergreifen. Dies gilt insbesondere dann, wenn der Server aus dem Internet erreichbar ist. 
 + 
 +==== 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. Aber gerade auf Cloud-/VPS-Instanzen ist dieser Account oft aktiv.)) 
 + 
 +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 wird in der Datei ''/etc/ssh/sshd_config'' den Eintrag ''PermitRootLogin'' auf ''no'' gesetzt. 
 + 
 +<code> 
 +PermitRootLogin no 
 +</code> 
 + 
 +<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 Rechners) aktiv. 
 + 
 +==== 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> 
 +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> 
 + 
 +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 ]]   * [[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]]   * [[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]]   * [[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