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 [20.11.2016 12:40. ] – [Client Konfiguration] 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 3103: Zeile 3107:
  
 === ED25519 Key === === ED25519 Key ===
-Ob man in Zeiten von Überwachungsphantasten bei einer NSA oder BND, noch solchen RSA.Schlüssel einsetzen kann und mag, muss natürlich jeder Admin für sich selbst entscheiden. Auf diese Schlüssel muss man aber nicht mehr zwingend zurückgreifen, stehen doch aktuellere und zeitgemäßere Cipher, MACs, Schlüssel Typen und Key Exchange Algorithmen zur Verfügung. Als Alternative zu einem RSA-Keys wollen wir nun nun einen [[http://ed25519.cr.yp.to/|ed25519]] Schlüssel erzeugen. [[https://de.wikipedia.org/wiki/Curve25519|Ed25519]] ist ein Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbaren Aufwand verspricht, als ECDSA oder DSA dies der Fall ist. Zur Auswahl sicherer kryptografischer Kurven bei der //Elliptic-Curve Cryptography// findet man auf der Seite [[https://safecurves.cr.yp.to/|hier]] hilfreiche Erklärungen und eine Gegenüberstellung der möglichen verschiedenen Alternativen.+<WRAP center round important 90%> 
 +Ob man in Zeiten von Überwachungsphantasten in Unternehmen und vor allem auch bei einer NSA oder BND, noch solchen **[[http://www.golem.de/news/elliptische-kurven-die-herkunft-der-nist-kurven-1309-101567.html|RSA-Schlüssel]]** einsetzen kann und mag, muss natürlich jeder Admin für sich selbst entscheiden.  
 + 
 +Der Sicherheitsguru Bruce Schneier hat in seinem **[[https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929|Blog]]** hierzu eine eindeutige Aussage getätigt:  
 + 
 +<wrap em>//"On the crypto bits in your guardian piece, I found especially interesting that you suggest classic discrete log crypto over ecc. I want to ask if you could elaborate more on that." __I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.__//</wrap> 
 +</WRAP> 
 + 
 + 
 + 
 + 
 +Auf diese Schlüssel muss man aber nicht mehr zwingend zurückgreifen, stehen doch aktuellere und zeitgemäßere Cipher, MACs, Schlüssel Typen und Key Exchange Algorithmen zur Verfügung. Als Alternative zu einem RSA-Keys wollen wir nun nun einen [[http://ed25519.cr.yp.to/|ed25519]] Schlüssel erzeugen. [[https://de.wikipedia.org/wiki/Curve25519|Ed25519]] ist ein Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbaren Aufwand verspricht, als ECDSA oder DSA dies der Fall ist. Zur Auswahl sicherer kryptografischer Kurven bei der //Elliptic-Curve Cryptography// findet man auf der Seite [[https://safecurves.cr.yp.to/|hier]] hilfreiche Erklärungen und eine Gegenüberstellung der möglichen verschiedenen Alternativen.
    $ ssh-keygen -t ed25519 -o -a 100 -C django@nausch.org -f ~/.ssh/id_ed25519_dmz    $ ssh-keygen -t ed25519 -o -a 100 -C django@nausch.org -f ~/.ssh/id_ed25519_dmz
  
Zeile 3134: 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.
  
-  [django@zielhost django]$ mkdir .ssh +  [django@zielhost django]$ (umask 077 ; mkdir -p $HOME/.ssh)
-  [django@zielhost django]$ chmod 700 .ssh+
  
 Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem; hatten wir uns einen RSA-key erstellt verwenden wir folgenden Aufruf: Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem; hatten wir uns einen RSA-key erstellt verwenden wir folgenden Aufruf:
Zeile 3164: 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 3320: 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 3333: 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 3454: 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 3489: Zeile 3510:
 # indicating that these messages will not be sent to the client. This option # indicating that these messages will not be sent to the client. This option
 # applies to protocol version 2 only.  # applies to protocol version 2 only. 
-ClientAliveInterval 0+ClientAliveInterval 900 
  
 # Sets the number of client alive messages (see below) which may be sent  # Sets the number of client alive messages (see below) which may be sent 
Zeile 3504: Zeile 3526:
 # will be disconnected after approximately 45 seconds. This option applies  # will be disconnected after approximately 45 seconds. This option applies 
 # to protocol version 2 only.  # to protocol version 2 only. 
-ClientAliveCountMax 3+ClientAliveCountMax 0
  
 # Specifies whether the system should send TCP keepalive messages to the  # Specifies whether the system should send TCP keepalive messages to the 
Zeile 3566: Zeile 3588:
 # authentication is allowed.  # authentication is allowed. 
 Banner /etc/issue.net Banner /etc/issue.net
 +
 +# pecifies whether ~/.ssh/environment and environment= options in 
 +# ~/.ssh/authorized_keys are processed by sshd(8). Enabling environment 
 +# processing may enable users to bypass access restrictions in some 
 +# configurations using mechanisms such as LD_PRELOAD.
 +PermitUserEnvironment no
  
 # Accept locale-related environment variables # Accept locale-related environment variables
Zeile 3582: Zeile 3610:
 </file> </file>
  
-Anschließend starten wir mit +Im Wesentlichen werden wir hier zu Absicherung bzw. Härtung des SSH-Daemon folgende Parameter besondere Beachtung schenken. 
 +  * **AddressFamily**: Abhängig von den verwendeten Adressklassen, setzen wir hier entweder //any// für IPv4 und IPv6 oder z.B. //inet// für IPv4 only. 
 +  * **ListenAddress**: Hier legen wir fest auf welcher IP-Adresse und welchem Port der SSH-Daemon lauschen soll. Bei Systemen, die direkt aus fremden Netzen erreichbar sind, hat es sich bewährt, den SSH-Daemon nicht auf dem Standardport 22 lauschen zu lassen. Einfache script-kiddies lassen sich so z.B. schon ein wenig aussperren. Eine Garantie, dass derartige Zugriffe mit einer Portverlegung ausbleiben, gibt es natürlich nicht. 
 +  * **HostKey**: Hier geben wir nun an, dass nur noch die besten und [[centos:ssh_c7#ed25519_key|vertrauenswürdigen Host-Schlüssel]] zur Anwendung kommen sollen.  
 +  * **Ciphers**, **MACs** und **KexAlgorithms**: Hier gilt auch das vorgenannte, wie beim Parameter **HosKeys**. Natürlich muss man hier Rücksicht auf ggf. vorhandene **puuty**-User oder Nutzer von älteren Linux-Distributionen Rücksicht nehmen. Oft muss bei der Qualität und Gülte dann der ein oder andere Abstrich dennoch gemacht werden, um solche Nutzer nicht auszuschließen.  
 +  * **PermitRootLogin**: Hier unterbinden wir **root**-logins mit einem **no**! 
 +  * **AllowUsers**: Nur die berechtigten Benutzer, die sich auf dem Server anmelden dürfen, werden hier angegeben! 
 +  * **MaxAuthTries**: Hier legen wir ein vertretbare Anzahl Anmeldeversuche fest. Da wir bei den Clientkonfigurationen jeweils den richtigen Schlüssel zum richtigen Zielhost festlegen, können wir auch bei Nutzung vieler unterschiedlicher Schlüssel im Verzeichnis //**~/.ssh**//, den **MaxAuthTries** auf **2** setzen! 
 +  * **PasswordAuthentication**: Da wir keine Passwortgestützten Logins der Admin zulassen wollen, setzen wir diesen Parameter auf **no**.  
 + 
 +<WRAP center round tip 100%> 
 +Alle weiteren Parameter sind in unserer Musterkonfigurationsdatei hin- und ausreichend beschrieben. Bei Bedarf passen wir diese unseren Anforderungen nach noch an! 
 +</WRAP> 
 + 
 +Bevor wir unsere Konfiguration scharf schalten überprüfen wir noch, ob sich nicht ein syntaktischer Fehler eingeschlichen hat. 
 +   # sshd -t 
 + 
 +  /etc/ssh/sshd_config: line 101: Bad configuration option: oginGraceTime 
 +  /etc/ssh/sshd_config: terminating, 1 bad configuration options 
 + 
 +Wir berichtigen also den Schreibfehler und überprüfen erneut die Änderung. 
 +   # sshd -t 
 + 
 +Erfolgt keine Fehlermeldung, bedeutet dies, dass alles in Ordnung ist und wir nun unseren Daemon einmal durchstarten können.
   # systemctl restart sshd.service   # systemctl restart sshd.service
-den ssh-Daemon neu und melden uns mit **ssh zielhost** am entfernten Rechner an.+ 
 +Bei Bedarf können wir auch den Status unseres SSH-Daemon wie folgt abfragen: 
 +   # systemctl status sshd.service  
 + 
 +<html><pre class="code"> 
 +<font style="color: rgb(29, 180, 29)"><b>●</b></font> sshd.service - OpenSSH server daemon 
 +   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) 
 +   Active:<font style="color: rgb(29, 180, 29)"><b> active (running)</b></font> since Sun 2016-11-20 14:34:10 CET; 3min 50s ago 
 +     Docs: man:sshd(8) 
 +           man:sshd_config(5) 
 + Main PID: 27346 (sshd) 
 +   CGroup: /system.slice/sshd.service 
 +           └─27346 /usr/sbin/sshd -D 
 + 
 +Nov 20 14:34:10 vml000017.dmz.nausch.org systemd[1]: Started OpenSSH server daemon. 
 +Nov 20 14:34:10 vml000017.dmz.nausch.org systemd[1]: Starting OpenSSH server daemon... 
 +Nov 20 14:34:10 vml000017.dmz.nausch.org sshd[27346]: Set /proc/self/oom_score_adj from 0 to -1000 
 +Nov 20 14:34:10 vml000017.dmz.nausch.org sshd[27346]: Server listening on 0.0.0.0 port 22.</font></pre> 
 +</html>
 ==== Finale sshd-Änderungen  ==== ==== Finale sshd-Änderungen  ====
 Das war's eigentlich schon. Im Moment kann sich der user mittels rsa-key oder seinem Passwort anmelden -es funktionieren beide Verfahren. Das kann während der Umstiegphase von Passwörtern auf Schlüssel wichtig sein, um sich z.B. nicht versehentlich selbst auszusperren. Schlägt die Anmeldung mit dem fehl, tritt wieder die Passwortauthentifizierung in Kraft. Das war's eigentlich schon. Im Moment kann sich der user mittels rsa-key oder seinem Passwort anmelden -es funktionieren beide Verfahren. Das kann während der Umstiegphase von Passwörtern auf Schlüssel wichtig sein, um sich z.B. nicht versehentlich selbst auszusperren. Schlägt die Anmeldung mit dem fehl, tritt wieder die Passwortauthentifizierung in Kraft.
Zeile 3615: 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 3634: 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 3643: Zeile 3762:
 ############################################################################## ##############################################################################
  
-[django@kd-141271-b357-fr138d ~]$+[django@kd-141271-b357-fr13nd ~]$
 </code> </code>
  
Zeile 3657: 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 3669: 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
  
 </file> </file>
 +
 +Da wir bei der Konfiguration unseres SSH-Daemons die Option **StrictModes yes** gesetzt hatten, damit fehlerhafte Datei und Verzeichnisrechte erkannt werden, passen wir noch die Dateirechte entsprechend an.
 +   $ chmod 600 ~/.ssh/config
  
 <WRAP center round tip> <WRAP center round tip>
Zeile 3681: 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 3709: Zeile 3833:
 Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.</WRAP> Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.</WRAP>
  
-Wir werden also den privaten RSA-Schlüssel besser z.B. mit einer Verfallszeit von 60 Minuten wie folgt laden.+Wir werden also den privaten RSA-Schlüssel besser z.B. mit einer Verfallszeit von 30 Minuten wie folgt laden.
    $ ssh-add -t 1800 ~/.ssh/id_rsa4096_dmz    $ ssh-add -t 1800 ~/.ssh/id_rsa4096_dmz
  
Zeile 3735: Zeile 3859:
   Lifetime set to 1800 seconds   Lifetime set to 1800 seconds
  
 +<WRAP center round alert 90%>
 +**WICHTIG**: Nun wird aber bei jedem Laden des/der Schlüssel ein neuer SSH-Agent gestartet, was natürlich bei längerer Laufzeit einer Session weder wünschenswert noch zu empfehlen ist!
 +</WRAP>
 +
 +Wir werden daher in der **.bashrc** unseres Homeverzeichnisses folgende **[[http://mah.everybody.org/docs/ssh|Erweiterung]]** anfügen:
 +   # vim ~/.bashrc
 +
 +<file bash ~/.bashrc>...
 +
 +SSH_ENV="$HOME/.ssh/environment"
 +
 +function start_agent {
 +    echo "Initialising new SSH agent..."
 +    (umask 066; /usr/bin/ssh-agent > "${SSH_ENV}")
 +    . "${SSH_ENV}" > /dev/null
 +    /usr/bin/ssh-add;
 +}
 +
 +# Source SSH settings, if applicable
 +
 +if [ -f "${SSH_ENV}" ]; then
 +    . "${SSH_ENV}" > /dev/null
 +    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
 +        start_agent;
 +    }
 +else
 +    start_agent;
 +fi
 +
 +</file>
 +
 +Nun können wir wie gewohnt die neuen als sicherer geltenden ED25519 Schlüssel genau so einfach laden, wie die altbekannten RSA-Schlüssel!
  
  
Zeile 3744: 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 3843: Zeile 3998:
  
 Na ja, komfortabel ist das nicht gerade und beim Kopieren von Daten von Ende zu Ende nervt das doch gewaltig, oder? Na ja, komfortabel ist das nicht gerade und beim Kopieren von Daten von Ende zu Ende nervt das doch gewaltig, oder?
 +\\ 
 +\\
 == verkette Sprünge == == verkette Sprünge ==
 O.K. wird sich da der ein oder andere sagen, dann verkette ich die Sprünge doch einfach.  O.K. wird sich da der ein oder andere sagen, dann verkette ich die Sprünge doch einfach. 
Zeile 3854: Zeile 4010:
 </file> </file>
 Na ja, das Kopieren geht immer noch nur von Host zu Host, oder eben mit einer verketteten Befehlsfolge oder eigenen Bash-Scripten. Na ja, das Kopieren geht immer noch nur von Host zu Host, oder eben mit einer verketteten Befehlsfolge oder eigenen Bash-Scripten.
 +\\ 
 +\\
  
 == ssh mit ProxyCommand == == ssh mit ProxyCommand ==
-Die Komfortabelste Variante ist nun die Nutzung der Option **ProxyCommand**. Hierzu legen wir uns einmalig eine entsprechende Konfigurationsdatei auf unserer Administrations-Workstation mit nachfolgendem Inhalt an.+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 3866: Zeile 4029:
 Host fwc Host fwc
     Hostname firewall-c.idmz.nausch.org     Hostname firewall-c.idmz.nausch.org
 +    IdentityFile ~/.ssh/id_ed25519_idmz 
  
 # Zweiter Sprunghost (fwb) - nur über fwc erreichbar # Zweiter Sprunghost (fwb) - nur über fwc erreichbar
Zeile 3871: Zeile 4035:
 Host fwb Host fwb
     Hostname firewall-b.edmz.nausch.org     Hostname firewall-b.edmz.nausch.org
-    ProxyCommand  ssh fwc nc -w 120 %h %p+    IdentityFile ~/.ssh/id_ed25519_edmz 
 +    ProxyCommand  ssh -A -q -W %h:%p fwc
  
 # Dritter Sprunghost (fwa) - nur über fwb erreichbar # Dritter Sprunghost (fwa) - nur über fwb erreichbar
Zeile 3877: Zeile 4042:
 Host fwa Host fwa
     Hostname firewall-a.nausch.org     Hostname firewall-a.nausch.org
-    ProxyCommand  ssh fwb nc -w 120 %h %p+    Port 22222 
 +    user sysadmin 
 +    IdentityFile ~/.ssh/id_ed25519_edmz 
 +    ProxyCommand  ssh -A -q -W %h:%p fwc
  
 # externer Server im Internet nur über externe Firewall "A" erreichbar # externer Server im Internet nur über externe Firewall "A" erreichbar
 # also: Host --> fwc --> fwb --> fwa --> daxie # also: Host --> fwc --> fwb --> fwa --> daxie
-Host daxie+Host s1u7
     Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>     Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>
-    ProxyCommand  ssh -l root -i ~/.ssh/id_rsa_daxie -2 -4 fwa nc -w 120 %h %p+    Port 42422 
 +    user n3rd 
 +    IdentityFile ~/.ssh/id_ed25519_n3rd 
 +    ProxyCommand  ssh -A -q -W %h:%p fwa
 </file> </file>
  
-Anschließend passen wir noch die Dateiberechtigungen an, damit **ssh** später nicht mäkelt. 
-   $ chmod 600 ~/.ssh/config 
- 
-Auf den Sprunghosts wird das Paket **netcat** benötigt. Wenn dies noch nicht bei der Grundinstallation unseres Systems bereits installiert wurde, werden wir dies nun noch nachholen. 
-   # yum install nc -y 
  
-==== Test ==== +=== Test === 
-Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhostz direkt "sehen".+Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhost direkt "sehen".
    $ ssh fwa    $ ssh fwa
  
 Auch können wir nun ohne großem Heckmeck Dateien von einem Ende zum anderen Ende kopieren. Auch können wir nun ohne großem Heckmeck Dateien von einem Ende zum anderen Ende kopieren.
-   $ scp ~/Downloads/enigmail-1.4-sm+tb.xpi daxie:/tmp/+   $ scp ~/Downloads/enigmail-1.4-sm+tb.xpi 51u7:/tmp/
  
-   $ scp daxie:/home/baby/Photos/Bild_001.png .+   $ scp 51u7:/home/babe/51lv14/04x.png .
  
 +==== Fehlersuche ====
 +Klappt aus unerfindlichen Gründen eine Verbindungsaufbau zu einem Zielsystem nicht, können wir mit der Option **-v** beim Aufruf von **ssh** die Ausgabe im Modus **verbose** erzwingen. Dort finden wir dann in der Regel entsprechende Hinweise, warum ein Verbindungsaufbau fehl schlug.
 +
 +   $ ssh -v centos7-testhost
 +<code>OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
 +debug1: Reading configuration data /home/django/.ssh/config
 +debug1: /home/django/.ssh/config line 2: Applying options for nausch
 +debug1: Reading configuration data /etc/ssh/ssh_config
 +debug1: /etc/ssh/ssh_config line 56: Applying options for *
 +debug1: Hostname has changed; re-reading configuration
 +debug1: Reading configuration data /home/django/.ssh/config
 +debug1: Reading configuration data /etc/ssh/ssh_config
 +debug1: /etc/ssh/ssh_config line 56: Applying options for *
 +debug1: Connecting to 192.168.1.173 [192.168.1.173] port 22.
 +debug1: Connection established.
 +debug1: identity file /home/django/.ssh/id_ed25519_dmz type 4
 +debug1: identity file /home/django/.ssh/id_ed25519_dmz-cert type -1
 +debug1: Enabling compatibility mode for protocol 2.0
 +debug1: Local version string SSH-2.0-OpenSSH_6.6.1
 +debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
 +debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
 +debug1: SSH2_MSG_KEXINIT sent
 +debug1: SSH2_MSG_KEXINIT received
 +debug1: kex: server->client aes256-ctr hmac-sha2-256-etm@openssh.com none
 +debug1: kex: client->server aes256-ctr hmac-sha2-256-etm@openssh.com none
 +debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
 +debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
 +debug1: sending SSH2_MSG_KEX_ECDH_INIT
 +debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
 +debug1: Server host key: ED25519 53:69:6c:76:69:61:44:61:78:69:73:74:67:65:69:6c
 +debug1: Host '[192.168.1.173]:22' is known and matches the ED25519 host key.
 +debug1: Found key in /home/django/.ssh/known_hosts:1412
 +debug1: ssh_ed25519_verify: signature correct
 +debug1: SSH2_MSG_NEWKEYS sent
 +debug1: expecting SSH2_MSG_NEWKEYS
 +debug1: SSH2_MSG_NEWKEYS received
 +debug1: SSH2_MSG_SERVICE_REQUEST sent
 +debug1: SSH2_MSG_SERVICE_ACCEPT received
 +##############################################################################
 +#                                                                            #
 +#                       This is a private home server.                       #
 +#                                                                            #
 +#             Unauthorized access to this system is prohibited !             #
 +#                                                                            #
 +#    This system is actively monitored and all connections may be logged.    #
 +#         By accessing this system, you consent to this monitoring.          #
 +#                                                                            #
 +##############################################################################
 +debug1: Authentications that can continue: publickey
 +debug1: Next authentication method: publickey
 +debug1: Offering ED25519 public key: /home/django/.ssh/id_ed25519_dmz
 +debug1: Server accepts key: pkalg ssh-ed25519 blen 51
 +debug1: key_parse_private_pem: PEM_read_PrivateKey failed
 +debug1: read PEM private key done: type <unknown>
 +Enter passphrase for key '/home/django/.ssh/id_ed25519_dmz': 
 +debug1: No more authentication methods to try.
 +Permission denied (publickey).
 +</code>
 +Im vorliegendem Beispiel wurde im Vorfeld der benötigte Schlüssel nicht geladen. Beim Verbindungsaufbau wurde dazu die Passphrase nicht richtig eingegeben und somit der Zugriff auf den publickey verweigert, was letztendlich zum Abbruch der Verbindung führte.
 ====== Links ====== ====== Links ======
   * **[[wiki:start|Zurück zu Projekte und Themenkapitel]]**   * **[[wiki:start|Zurück zu Projekte und Themenkapitel]]**
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
-~~DISCUSSION~~+
  • centos/ssh_c7.1479645635.txt.gz
  • Zuletzt geändert: 20.11.2016 12:40.
  • von django