centos:ssh_c7

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
centos:ssh_c7 [15.12.2016 11:22. ] – [ED25519 Key] #SSH #CentOS7 djangocentos:ssh_c7 [07.04.2022 15:15. ] (aktuell) – [Verbindungsaufbau via SSH] django
Zeile 1: Zeile 1:
 ====== Secure Shell - ssh unter CentOS 7.x ====== ====== Secure Shell - ssh unter CentOS 7.x ======
 {{:centos:openssh.png?200 |openSSH Logo}}Bei Internetdiensten wie [[centos:mail_c7:start|eMail]] oder [[centos:web_c7:start|Web]] haben sich verschlüsselte Datenübertragungen mit SSL/TLS ohne Eingriffe in das Originalprotokoll durchgesetzt. Bei den klassischen unverschlüsselten Unix-Diensten zum Arbeiten mit entfernten Rechnern oder zur Datenübertragung auf andere Rechner - z.B. **telnet**, **rcp** und **rsh** - erfolgt eine alternative Lösung mittels [[http://www.openssh.org|OpenSSH]]. {{:centos:openssh.png?200 |openSSH Logo}}Bei Internetdiensten wie [[centos:mail_c7:start|eMail]] oder [[centos:web_c7:start|Web]] haben sich verschlüsselte Datenübertragungen mit SSL/TLS ohne Eingriffe in das Originalprotokoll durchgesetzt. Bei den klassischen unverschlüsselten Unix-Diensten zum Arbeiten mit entfernten Rechnern oder zur Datenübertragung auf andere Rechner - z.B. **telnet**, **rcp** und **rsh** - erfolgt eine alternative Lösung mittels [[http://www.openssh.org|OpenSSH]].
 +\\
 +<WRAP center round info 65%>
 +**Hinweis**: \\ Möchte man gleich in den Praxisteil einsteigen überspringt man die beiden folgenden Kapitel und steigt direkt beim **[[#ssh_in_der_praxis_teil_1|Praxisteil]]** ein! \\
 +</WRAP>
  
 ===== openSSH - Programmsuite ===== ===== openSSH - Programmsuite =====
Zeile 3067: Zeile 3071:
  
  
-==== Erzeugung eines Schlüsselpäärchens  ====+==== Erzeugung eines SSH-Schlüssel(paars)  ====
 === RSA Key === === RSA Key ===
 Im ersten Beispiel erzeugen wir uns einen 4096er RSA-Schlüssel für die Authentifizierung: Im ersten Beispiel erzeugen wir uns einen 4096er RSA-Schlüssel für die Authentifizierung:
Zeile 3145: Zeile 3149:
  
 **id_ed25519_dmz** enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch __nur__ für den Nutzer selbst lesbar sein! **id_ed25519_dmz.pub**, der öffentliche Schlüssel, dagegen muss auf den Zielrechner kopiert werden.  **id_ed25519_dmz** enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch __nur__ für den Nutzer selbst lesbar sein! **id_ed25519_dmz.pub**, der öffentliche Schlüssel, dagegen muss auf den Zielrechner kopiert werden. 
 +
 +==== Passphrase eines SSH-Keys ändern ====
 +Will man die passphrase eines bestehenden SSH-Keys ändern benutzt man wie schon bei der Erstellung des Schlüssel(paares) den Befehl **ssh-keygen**.
 +   $ ssh-keygen -p -f ~/.ssh/id_ed25519_dmz
 +
 +   Enter old passphrase: 
 +
 +   Enter new passphrase (empty for no passphrase): 
 +
 +   Enter same passphrase again: 
 +
 +  Your identification has been saved with the new passphrase.
 +
 ==== Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren  ==== ==== Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren  ====
 Auf dem Zielrechner legen wir nun das Verzeichnis **.ssh** an und schützen es entsprechend. Auf dem Zielrechner legen wir nun das Verzeichnis **.ssh** an und schützen es entsprechend.
Zeile 3174: Zeile 3191:
 <WRAP round important>**Wichtig ist jedoch immer:** <WRAP round important>**Wichtig ist jedoch immer:**
  
-Der User muß selbst darauf achten, dass sein privater Schlüssel nicht in fremde Hände gelangt! Will man noch sicherer gehen, vergibt man, wie Eingangs bereits erwähnt, bei der Erzeugung des Schlüssels eine Passphrase. Diese muss er User dann aber bei jedem neuen Verbindungsaufbau angeben!</WRAP> +Der User muß selbst darauf achten, dass sein privater Schlüssel nicht in fremde Hände gelangt! Will man noch sicherer gehen, vergibt man, wie Eingangs bereits erwähnt, bei der Erzeugung des Schlüssels eine Passphrase. Diese muss er User dann aber bei jedem neuen Verbindungsaufbau angeben! 
 + 
 +<WRAP center round tip> 
 +Möchte man seine Schlüssel sicher ausserhalb seines Rechners/Dateisystems verwahren, bietet sich die Nutzung eines externen Krypto-Devices wie z.B. einem **[[https://shop.nitrokey.com/de_DE/shop/product/nitrokey-start-6|Nitrokey Start]]** an. Die Nutzung eines **ED25519**-Schlüssels ist in diesem **[[fedora:nitrokey:start#nitrokey_start_und_secure_shell|Artikel]]** ausführlich beschrieben. 
 +</WRAP> 
 + 
 + 
 +</WRAP> 
  
 ===== ssh-Daemon ===== ===== ssh-Daemon =====
Zeile 3330: Zeile 3354:
 # taken to be an absolute path or one relative to the user's home directory. # taken to be an absolute path or one relative to the user's home directory.
 AuthorizedKeysFile      .ssh/authorized_keys AuthorizedKeysFile      .ssh/authorized_keys
- 
-# Specifies whether pure RSA authentication is allowed. The default is  
-# ''yes''. This option applies to protocol version 1 only.  
-RSAAuthentication no 
  
 # Specifies whether public key authentication is allowed. The default is  # Specifies whether public key authentication is allowed. The default is 
Zeile 3343: Zeile 3363:
 # RhostsRSAAuthentication and HostbasedAuthentication # RhostsRSAAuthentication and HostbasedAuthentication
 RhostsRSAAuthentication no RhostsRSAAuthentication no
- 
 # Specifies whether rhosts or /etc/hosts.equiv authentication together  # Specifies whether rhosts or /etc/hosts.equiv authentication together 
 # with successful public key client host authentication is allowed  # with successful public key client host authentication is allowed 
Zeile 3464: Zeile 3483:
 # login when a user logs in interactively. The default is ''yes''.  # login when a user logs in interactively. The default is ''yes''. 
 PrintLastLog yes PrintLastLog yes
- 
-# Specifies whether login(1) is used for interactive login sessions. The  
-# default is ''no''. Note that login(1) is never used for remote command  
-# execution. Note also, that if this is enabled, X11Forwarding will be  
-# disabled because login(1) does not know how to handle xauth(1) cookies.  
-# If UsePrivilegeSeparation is specified, it will be disabled after  
-# authentication. 
-UseLogin no 
  
 # Set this to 'yes' to enable PAM authentication, account processing, # Set this to 'yes' to enable PAM authentication, account processing,
Zeile 3673: Zeile 3684:
 ===== ssh in der Praxis (Teil 2) ===== ===== ssh in der Praxis (Teil 2) =====
 ==== Verbindungsaufbau via SSH ==== ==== Verbindungsaufbau via SSH ====
-Nachdem wir den Login mit Passwort deaktiviert haben, werden wir nun beim Verbindungsaufbau nach der Passphrase des zur Anwendung kommenden Schlüssels gefragt.+Nun ist es an der Zeit, dass wir uns mit unserem Zielhost verbinden.  
 + 
 +<WRAP center round important 80%> 
 +**Achtung**: \\  
 +Doch bevor wir das machen, besorgen wir uns zuerst einmal noch die **fingerprints** des Zielhosts! doch warum sollten wir das machen? Nun, beim initialen Verbindungsaufbau wird uns der Fingerprint des ''host_keys'' des Zielsystems präsentiert und wir können diesen nur vergleichen, wenn wir diesen vorliegen haben. Sonst könnte es passieren, dass wir uns z.B. mit einem Ziel verbinden und wir gar nicht sicherstellen können, dass dies auch wirklich das gewählte Ziel ist, sondern ein ggf. kompromittiertes System, welches uns jemand "unterjubeln möchte". 
 + 
 +Also wichtig, nicht einfach **__blind__** irgendwelchen Zielen vertrauen. Eine gewisse Paranoia als Admin an den Tag legen ist nie verkehrt! 
 +</WRAP> 
 + 
 +/* 
 +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
 +@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ 
 +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
 +IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 
 +Someone could be eavesdropping on you right now (man-in-the-middle attack)! 
 +It is also possible that a host key has just been changed. 
 +The fingerprint for the ED25519 key sent by the remote host is 
 +SHA256:qAdwr92ndrh7PnoIH0GChFX2GxDo0xzcVhQF3kO4JV0. 
 +Please contact your system administrator. 
 +Add correct host key in /home/django/.ssh/known_hosts to get rid of this message. 
 +Offending ED25519 key in /home/django/.ssh/known_hosts:43 
 +  remove with: 
 +  ssh-keygen -f "/home/django/.ssh/known_hosts" -R "192.168.0.23" 
 +ED25519 host key for 192.168.0.23 has changed and you have requested strict checking. 
 +Host key verification failed. 
 +*/ 
 + 
 + 
 +Wir melden uns also direkt an der Konsole unseres Zielsystems vor Ort oder über eine Remote-Konsole an und lassen uns die betreffenden Fingerprints ausgeben. Hierzu ist es notwendig, dass wir das als Nutzer **''root''** machen, da die betreffenden Dateien nur diesem lesbar vorliegen. 
 +   [root@kd-141271-b357-fr13nd ~]# ll /etc/ssh/ssh_host_*_key 
 +<code>-rw-r-----. 1 root ssh_keys  227 Jan 17  2017 /etc/ssh/ssh_host_ecdsa_key 
 +-rw-r-----. 1 root ssh_keys  387 Jan 17  2017 /etc/ssh/ssh_host_ed25519_key 
 +-rw-r-----. 1 root ssh_keys 1675 Jan 17  2017 /etc/ssh/ssh_host_rsa_key</code> 
 + 
 +Die Fingerprints dieser drei Schlüssel (**ECDSA**, **ED25519**, **RSA**) ermitteln wir nun mit dem folgenden Befehl: 
 +   [root@kd-141271-b357-fr13nd ~]# for f in /etc/ssh/ssh_host_*_key; do ssh-keygen -l -f "$f"; done 
 +<code>256 SHA256:PKoQVl2oiYlw22JNoPakFdLUFG/KXHM62Ls0NcBppOI /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) 
 +256 SHA256:f1kCch8GMI1LZQ30PR0MItt0yyycbYnqSWV1qk2zA7E /etc/ssh/ssh_host_ed25519_key.pub (ED25519) 
 +2048 SHA256:ozmj5gq0Zv+l9ohEcAWExLrdfisktWJl0weKW08sIAg /etc/ssh/ssh_host_rsa_key.pub (RSA)</code> 
 + 
 +Nun können wir uns das erste mal mit unserem Zielhost verbinden. Nachdem wir den Login mit Passwort deaktiviert haben, werden wir nun beim Verbindungsaufbau nach der Passphrase des zur Anwendung kommenden Schlüssels gefragt.
    $ ssh www    $ ssh www
-<code>##############################################################################+<code>The authenticity of host 'www (10.11.12.13)' can't be established. 
 +ED25519 key fingerprint is SHA256:f1kCch8GMI1LZQ30PR0MItt0yyycbYnqSWV1qk2zA7E. 
 +Are you sure you want to continue connecting (yes/no/[fingerprint])?</code> 
 + 
 +Den angezeigten Fingerprint **''SHA256:f1kCch8GMI1LZQ30PR0MItt0yyycbYnqSWV1qk2zA7E''** des **ED25519**-Keys vergleichen wir nun gewissenhaft mit dem zuvor ermittelten Fingerprint: 
 +  256 SHA256:f1kCch8GMI1LZQ30PR0MItt0yyycbYnqSWV1qk2zA7E /etc/ssh/ssh_host_ed25519_key.pub (ED25519) 
 + 
 +Da sich dieser nicht unterscheidet, können wir nun die Frage **''Are you sure you want to continue connecting (yes/no/[fingerprint])?''** getrost beja'en und demnach mit **''yes''** bestätigen. 
 +  yes 
 +<code>Warning: Permanently added 'www' (ED25519) to the list of known hosts. 
 +##############################################################################
 #                                                                            # #                                                                            #
 #                        This is server of nausch.org.                       # #                        This is server of nausch.org.                       #
Zeile 3692: Zeile 3753:
 #                        This is server of nausch.org.                       # #                        This is server of nausch.org.                       #
 #                                                                            # #                                                                            #
-#                            kd-141271-b357-fr138d                           #+#                            kd-141271-b357-fr13nd                           #
 #                                                                            # #                                                                            #
 #             Unauthorized access to this system is prohibited !             # #             Unauthorized access to this system is prohibited !             #
Zeile 3701: Zeile 3762:
 ############################################################################## ##############################################################################
  
-[django@kd-141271-b357-fr138d ~]$+[django@kd-141271-b357-fr13nd ~]$
 </code> </code>
  
Zeile 3715: Zeile 3776:
 <file bash ~/.ssh/config># Clientkonfigurationsbeispiel für unterschiedliche Zielsysteme  <file bash ~/.ssh/config># Clientkonfigurationsbeispiel für unterschiedliche Zielsysteme 
 # Django : 2016-11-18 # Django : 2016-11-18
 +
 +# Standardwerte die für alle nachfolgenden Hosts gelten sollen, sofern diese Werte nicht überschrieben werden.
 +Host *
 +     User django
 +     Protocol 2
 +     
 Host 04x1 Host 04x1
-     Hostname kd-141271-b357-fr138d.dmz.nausch.org+     Hostname kd-141271-b357-fr13nd.dmz.nausch.org
      Port 9922      Port 9922
-     User django 
      ForwardX11 yes      ForwardX11 yes
      ForwardAgent yes      ForwardAgent yes
-     Protocol 2 
      IdentityFile ~/.ssh/id_ed25519_dmz      IdentityFile ~/.ssh/id_ed25519_dmz
  
Zeile 3727: Zeile 3792:
      Hostname d34db33f1.idmz.nausch.org      Hostname d34db33f1.idmz.nausch.org
      Port 22      Port 22
-     User django 
      Compression yes      Compression yes
-     Protocol 2 
      IdentityFile ~/.ssh/id_rsa4096_dmz      IdentityFile ~/.ssh/id_rsa4096_dmz
  
Zeile 3742: Zeile 3805:
  
  
-Im folgenden Beispiel würde eien Verbindungs zum Zielhost kd-141271-b357-fr138d.dmz.nausch.org aufgebeut werden.+Im folgenden Beispiel würde ein Verbindungs zum Zielhost kd-141271-b357-fr13nd.dmz.nausch.org aufgebeut werden.
    $ ssh 04x1    $ ssh 04x1
  
 __Ohne__ unsere Clientkonfigurationsdatei müssten wir hingegen folgenden Aufruf verwenden. __Ohne__ unsere Clientkonfigurationsdatei müssten wir hingegen folgenden Aufruf verwenden.
-   $ ssh -p 9922 -u django -Y -A -2 -i ~/.ssh/id_ed25519_dmz kd-141271-b357-fr138d.dmz.nausch.org+   $ ssh -p 9922 -u django -Y -A -2 -i ~/.ssh/id_ed25519_dmz kd-141271-b357-fr13nd.dmz.nausch.org
  
  
Zeile 3837: Zeile 3900:
 Von der Admin-Workstation aus, wollen wir nun nicht nur zum nächstgelegenen Host springen, sondern auch zum übernächsten oder gar zu einem Host im Internet, den wir aber aus Sicherheitsgründen nicht direkt erreichen dürfen und auch können. Von der Admin-Workstation aus, wollen wir nun nicht nur zum nächstgelegenen Host springen, sondern auch zum übernächsten oder gar zu einem Host im Internet, den wir aber aus Sicherheitsgründen nicht direkt erreichen dürfen und auch können.
 === System-Skizze === === System-Skizze ===
-<uml width=775 title="Grafische System-Übersicht"> +<uml>
 state Firewall_A { state Firewall_A {
   Firewall_A : -----------   Firewall_A : -----------
Zeile 3954: Zeile 4016:
 Die Komfortabelste Variante ist nun die Nutzung der Option **ProxyCommand**. Hierzu erweitern wir die bereits bei der [[centos:ssh_c7#client_konfiguration|Client Konfiguration]] angelegte Datei //**~/.ssh/config**// auf unserer Administrations-Workstation mit nachfolgendem Inhalt. Die Komfortabelste Variante ist nun die Nutzung der Option **ProxyCommand**. Hierzu erweitern wir die bereits bei der [[centos:ssh_c7#client_konfiguration|Client Konfiguration]] angelegte Datei //**~/.ssh/config**// auf unserer Administrations-Workstation mit nachfolgendem Inhalt.
    $ vim ~/.ssh/config    $ vim ~/.ssh/config
-<file bash ~/.ssh/config># Django : 2012-06-13+<file bash ~/.ssh/config># Default Werte 
 +Host *  
 +    Port 22 
 +    Protocol 2 
 +    user admin 
 +            
 +# Django : 2012-06-13
 # ssh-jumps über mehrere Sprunghosts # ssh-jumps über mehrere Sprunghosts
  
Zeile 3961: Zeile 4029:
 Host fwc Host fwc
     Hostname firewall-c.idmz.nausch.org     Hostname firewall-c.idmz.nausch.org
-    Port 22 
-    Protocol 2 
-    user admin 
     IdentityFile ~/.ssh/id_ed25519_idmz      IdentityFile ~/.ssh/id_ed25519_idmz 
  
Zeile 3970: Zeile 4035:
 Host fwb Host fwb
     Hostname firewall-b.edmz.nausch.org     Hostname firewall-b.edmz.nausch.org
-    Port 22 
-    Protocol 2 
-    user admin 
     IdentityFile ~/.ssh/id_ed25519_edmz     IdentityFile ~/.ssh/id_ed25519_edmz
     ProxyCommand  ssh -A -q -W %h:%p fwc     ProxyCommand  ssh -A -q -W %h:%p fwc
Zeile 3981: Zeile 4043:
     Hostname firewall-a.nausch.org     Hostname firewall-a.nausch.org
     Port 22222     Port 22222
-    Protocol 2 +    user sysadmin
-    user admin+
     IdentityFile ~/.ssh/id_ed25519_edmz     IdentityFile ~/.ssh/id_ed25519_edmz
     ProxyCommand  ssh -A -q -W %h:%p fwc     ProxyCommand  ssh -A -q -W %h:%p fwc
Zeile 3991: Zeile 4052:
     Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>     Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>
     Port 42422     Port 42422
-    Protocol 2 
     user n3rd     user n3rd
     IdentityFile ~/.ssh/id_ed25519_n3rd     IdentityFile ~/.ssh/id_ed25519_n3rd
Zeile 4070: Zeile 4130:
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
-~~AUTOTWEET:~~ +
-~~DISCUSSION~~+
  • centos/ssh_c7.1481800951.txt.gz
  • Zuletzt geändert: 15.12.2016 11:22.
  • (Externe Bearbeitung)