centos:ssh-install

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.


Vorhergehende Überarbeitung
centos:ssh-install [20.05.2021 07:50. ] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 1: Zeile 1:
 +====== Secure Shell - ssh ======
 +{{:centos:openssh.png?200 |openSSH Logo}}Bei Internetdiensten wie [[centos:mailserver:start|eMail]] oder [[centos:webserver: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ösiung mittels [[http://www.openssh.org|OpenSSH]].
 +
 +===== openSSH - Programmsuite =====
 +Die für die **//Secure-Shell//** benötigten Pakete werden i.d.R. bereits bei der Erstinstallation erfolgreich ins System eingebettet. Bei Centos teilen sich die Programme der //Programmsuite// auf folgende Pakete auf:
 +  * openssh.i386 : Die OpenSSH-Implementierung der SSH Protokoll-Versionen 1 und 2
 +  * openssh-clients.i386 : Die OpenSSH-Client-Anwendungen
 +  * openssh-server.i386 : Der OpenSSH-Server Daemon
 +  * openssh-askpass.i386 : Passphrase-Dialog für OpenSSH und X
 +==== openssh ====
 +Mittels **__rpm -iql__** können wir überprüfen, welche Programme, Konfigurationsdateien und Dokumentationen installiert wurden.
 +<code># rpm -iql openssh
 +Name        : openssh                      Relocations: (not relocatable)
 +Version     : 4.3p2                             Vendor: CentOS
 +...
 +
 +...
 +Signature   : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897
 +Packager    : Karanbir Singh <kbsingh@karan.org>
 +URL         : http://www.openssh.com/portable.html
 +Summary     : Die OpenSSH-Implementierung der SSH Protokoll-Versionen 1 und 2
 +Description :
 +SSH (Secure SHell) is a program for logging into and executing
 +commands on a remote machine. SSH is intended to replace rlogin and
 +rsh, and to provide secure encrypted communications between two
 +untrusted hosts over an insecure network. X11 connections and
 +arbitrary TCP/IP ports can also be forwarded over the secure channel.
 +
 +OpenSSH is OpenBSD's version of the last free version of SSH, bringing
 +it up to date in terms of security and features, as well as removing
 +all patented algorithms to separate libraries.
 +
 +This package includes the core files necessary for both the OpenSSH
 +client and server. To make this package useful, you should also
 +install openssh-clients, openssh-server, or both.
 +/etc/ssh
 +/etc/ssh/moduli
 +/usr/bin/ssh-keygen
 +/usr/libexec/openssh
 +/usr/libexec/openssh/ssh-keysign
 +/usr/share/doc/openssh-4.3p2
 +/usr/share/doc/openssh-4.3p2/CREDITS
 +/usr/share/doc/openssh-4.3p2/ChangeLog
 +/usr/share/doc/openssh-4.3p2/INSTALL
 +/usr/share/doc/openssh-4.3p2/LICENCE
 +/usr/share/doc/openssh-4.3p2/OVERVIEW
 +/usr/share/doc/openssh-4.3p2/README
 +/usr/share/doc/openssh-4.3p2/README.dns
 +/usr/share/doc/openssh-4.3p2/README.nss
 +/usr/share/doc/openssh-4.3p2/README.platform
 +/usr/share/doc/openssh-4.3p2/README.privsep
 +/usr/share/doc/openssh-4.3p2/README.smartcard
 +/usr/share/doc/openssh-4.3p2/README.tun
 +/usr/share/doc/openssh-4.3p2/RFC.nroff
 +/usr/share/doc/openssh-4.3p2/TODO
 +/usr/share/doc/openssh-4.3p2/WARNING.RNG
 +/usr/share/man/man1/ssh-keygen.1.gz
 +/usr/share/man/man8/ssh-keysign.8.gz</code>
 +==== openssh-clients ====
 +Beim Paket **openssh-clients** wird mitgeliefert:
 +<code># rpm -iql openssh-clients
 +Name        : openssh-clients              Relocations: (not relocatable)
 +Version     : 4.3p2                             Vendor: CentOS
 +...
 +
 +...
 +Signature   : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897
 +Packager    : Karanbir Singh <kbsingh@karan.org>
 +URL         : http://www.openssh.com/portable.html
 +Summary     : Die OpenSSH-Client-Anwendungen
 +Description :
 +OpenSSH is a free version of SSH (Secure SHell), a program for logging
 +into and executing commands on a remote machine. This package includes
 +the clients necessary to make encrypted connections to SSH servers.
 +You'll also need to install the openssh package on OpenSSH clients.
 +/etc/ssh/ssh_config
 +/usr/bin/scp
 +/usr/bin/sftp
 +/usr/bin/slogin
 +/usr/bin/ssh
 +/usr/bin/ssh-add
 +/usr/bin/ssh-agent
 +/usr/bin/ssh-copy-id
 +/usr/bin/ssh-keyscan
 +/usr/share/man/man1/scp.1.gz
 +/usr/share/man/man1/sftp.1.gz
 +/usr/share/man/man1/slogin.1.gz
 +/usr/share/man/man1/ssh-add.1.gz
 +/usr/share/man/man1/ssh-agent.1.gz
 +/usr/share/man/man1/ssh-copy-id.1.gz
 +/usr/share/man/man1/ssh-keyscan.1.gz
 +/usr/share/man/man1/ssh.1.gz
 +/usr/share/man/man5/ssh_config.5.gz</code>
 +==== openssh-server ====
 +Hingegen liefert uns **openssh-server** folgende Dateien:
 +<code># rpm -iql openssh-server
 +Name        : openssh-server               Relocations: (not relocatable)
 +Version     : 4.3p2                             Vendor: CentOS
 +...
 +
 +...
 +Signature   : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897
 +Packager    : Karanbir Singh <kbsingh@karan.org>
 +URL         : http://www.openssh.com/portable.html
 +Summary     : Der OpenSSH-Server Daemon
 +Description :
 +OpenSSH is a free version of SSH (Secure SHell), a program for logging
 +into and executing commands on a remote machine. This package contains
 +the secure shell daemon (sshd). The sshd daemon allows SSH clients to
 +securely connect to your SSH server. You also need to have the openssh
 +package installed.
 +/etc/pam.d/sshd
 +/etc/rc.d/init.d/sshd
 +/etc/ssh
 +/etc/ssh/sshd_config
 +/usr/libexec/openssh/sftp-server
 +/usr/sbin/sshd
 +/usr/share/man/man5/sshd_config.5.gz
 +/usr/share/man/man8/sftp-server.8.gz
 +/usr/share/man/man8/sshd.8.gz
 +/var/empty/sshd
 +/var/empty/sshd/etc
 +/var/empty/sshd/etc/localtime</code>
 +==== openssh-askpass ====
 +Zu guter Letzt sehen wir uns noch das Paket **openssh-askpass** genauer an:
 +<code># rpm -iql openssh-askpass
 +Name        : openssh-askpass              Relocations: (not relocatable)
 +Version     : 4.3p2                             Vendor: CentOS
 +...
 +
 +...
 +Signature   : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897
 +Packager    : Karanbir Singh <kbsingh@karan.org>
 +URL         : http://www.openssh.com/portable.html
 +Summary     : Passphrase-Dialog für OpenSSH und X
 +Description :
 +OpenSSH is a free version of SSH (Secure SHell), a program for logging
 +into and executing commands on a remote machine. This package contains
 +an X11 passphrase dialog for OpenSSH.
 +/etc/profile.d/gnome-ssh-askpass.csh
 +/etc/profile.d/gnome-ssh-askpass.sh
 +/usr/libexec/openssh/gnome-ssh-askpass
 +/usr/libexec/openssh/ssh-askpass</code>
 +===== ssh in der Praxis =====
 +Auch wenn das Passwort bei **ssh** verschlüsselt übertragen wird, lohnt ein Blick auf die Alternative  **//RSA/DSA-Authentifizierung//**. Bei dieser Variante muss gar kein Passwort über das Netz übertragen werden. Normalerweise muss der User beim Zugriff via ssh auf einen entfernten Rechner sein Passwort eingeben. Zum einen wollen wir aus Sicherheitsgründen darauf verzichten und zum anderen kann dies doch auf Dauer doch als etwas nervig empfunden werden. 
 +Einfacher geht dies über asymetrische Schlüssel. 
 +==== Erzeugung eines Schlüssel  ====
 +Als erstes erzeugen wir uns einen Schlüssel für die Authentifizierung:
 +<code>[django@host ~]$ ssh-keygen -b 4096 -t rsa
 +Generating public/private rsa key pair.
 +Enter file in which to save the key (/home/django/.ssh/id_rsa): 
 +Enter passphrase (empty for no passphrase): 
 +Enter same passphrase again: 
 +Your identification has been saved in /home/django/.ssh/id_rsa.
 +Your public key has been saved in /home/django/.ssh/id_rsa.pub.
 +The key fingerprint is:
 +2b:83:69:f2:76:e8:c9:8b:cf:34:c8:c2:ae:2b:e1:ee django@host.nausch.org</code>
 +
 +Die //passphrase// die man hier angibt, wird später beim Anmelden auf dem entfernten Rechner abgefragt, oder vom //ssh-agent// bei der Anmeldung mitübergeben.
 +
 +Nun liegen in dem Verzeichnis **/home/django/.ssh** zwei Dateien:
 +<code>[django@host .ssh]$ ll
 +insgesamt 24
 +-rw------- 1 django django 3311 22. Apr 22:11 id_rsa
 +-rw-r--r-- 1 django django  748 22. Apr 22:11 id_rsa.pub</code>
 +
 +**id_rsa** 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_rsa.pub**, der öffentliche Schlüssel, dagegen muss auf den Zielrechner kopiert werden. 
 +==== Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren  ====
 +Auf dem Zielrechner legen wir nun das Verzeichnis **.ssh** an und schützen es entsprechend.
 +
 +  [django@zielhost django]$ mkdir .ssh
 +  [django@zielhost django]$ chmod 700 .ssh
 +
 +Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem:
 +  [django@host .ssh]$  scp /home/django/.ssh/id_rsa.pub zielhost:/home/django/.ssh/id_rsa.pub
 +
 +Anschließend wird der Schlüssel in die Datei authorized_keys kopiert. Diese Datei kann mehrere Schlüssel enthalten, daher ist das doppelte Umleitungszeichen wichtig, um eine evt. existierende Datei nicht versehentlich zu überschreiben. Somit wird der neue Schlüssel in die Datei hinzugefügt:
 +  [django@zielhost .ssh]$ cat id_rsa.pub >> authorized_keys
 +Zu guter Letzt passen wir noch die Berechtigungen an und löschen die nicht mehr benötigte **id_rsa.pub**
 +  [django@zielhost .ssh]$ chmod 600 authorized_keys
 +  [django@zielhost .ssh]$ rm id_rsa.pub
 +
 +<WRAP round info>Das Kopieren des Public-Keys auf unseren Zielhost mit Anpassen der Dateiberechtigungen kann man natürlich auch einfacher vornehmen. Man benutzt hierzu einfach den Befehl **ssh-copy-id** aus dem Paket //**openssh-clients**//.
 +
 +   $ ssh-copy-id -i ~/.ssh/id_rsa.pub testhost.intra.nausch.org
 +
 +Die Angabe ''~/.ssh/id_rsa.pub'' entspricht dabei dem Public-Key und ''testhost.intra.nausch.org
 +'' dem gewünschten Zielhost.
 +</WRAP>
 +==== authorized_keys vs. authorized_keys2 ====
 +<WRAP round info>Bei der Einführung von SSH Version 2 kam die Datei ''authorized_keys2'' zum Einsatz. Seit OpenSSH 3.0 wird nun wiederum neben der ''authorized_keys2'' wieder die ''authorized_keys'' verwendet. In unserem Fall nutzen wir in unserem obigen Beispiel daher nur noch die Schlüsseldatei ''authorized_keys''.</WRAP>
 +
 +===== ssh-Daemon =====
 +==== ssh-Daemon einrichten/anpassen  ====
 +
 +Folgende Zeilen müssen wir in der Datei **/etc/ssh/sshd_config** anpassen:
 +   # vim /etc/ssh/sshd_config
 +<code>PermitRootLogin yes
 +RSAAuthentication yes
 +PubkeyAuthentication yes
 +AuthorizedKeysFile .ssh/authorized_keys</code>
 +
 +Anschließend starten wir mit 
 +  # service sshd restart
 +den ssh-Daemon neu und melden uns mit **ssh zielhost** am entfernten Rechner an.
 +==== 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.
 +
 +Wenn jedoch alles wunschgemäß funktioniert sollte man in der **/etc/ssh/sshd_config** des Zielsystems folgenden Eintrag freischalten: 
 +   # vim /etc/ssh/sshd_config
 +
 +  PasswordAuthentication no
 +
 +Anschließend den daemon wieder mittels:
 +  # service sshd restart
 +neu starten.
 +
 +Somit sind dann nur noch Userlogins zugelassen, die einen Publikkey auf dem Zielsystem besitzen.
 +
 +<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> 
 +==== ssh-Daemon automatisch starten  ====
 +Damit der ssh-Daemon **sshd** automatisch bei jedem Systemstart startet, kann die Einrichtung eines Start-Scripts über folgenden Befehl erreicht werden:
 +
 +  # chkconfig sshd on
 +
 +Ein Überprüfung ob der Dienst (Daemon) sshd wirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehl erreicht werden:
 +
 +  # chkconfig --list | grep sshd
 +  sshd            0:Aus   1:Aus   2:Ein   3:Ein   4:Ein   5:Ein   6:Aus
 +
 +Wichtig ist jeweils der Schalter **on** bei den Runleveln - **2 3 4 5**. 
 +
 +==== sshd-Agent nutzen  ====
 +
 +Damit man nicht bei jedem anmelden am entfernten Rechner, die Passphrase erneut eingeben müssen, nutzen wir nun den **ssh-agent**.
 +
 +Im Homeverzeichnis des remote-clients legen wir ein Verzeichnis **autostart** an:
 +
 +  $ mkir /home/django/.config/autostart
 +  
 +Dort legen wir die Datei **ssh-add.desktop** mit folgendem Inhalt an:
 +<code>[Desktop Entry]
 +Name=No name
 +Encoding=UTF-8
 +Version=1.0
 +Exec=ssh-add
 +X-GNOME-Autostart-enabled=true</code>
 +Somit wird beim nächsten Amelden am //X-Gnome-Desktop// die passphrase einmalig abgefragt und beim Anmelden am Remotesystem mit übertragen.
 +
 +===== SSH ProxyCommand - Transparente multi-jump SSH =====
 +Oft steht man vor einem Problem, dass man ein Host nicht direkt via **ssh** erreichbar ist, man aber dennoch zur Adminsitration dort hin möchte oder gar Dateien via **scp** kopieren möchte.
 +
 +Schauenm wir uns hierzu einfach mal nachstehende Skizze an.
 +
 +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 ====
 +<uml>
 +
 +state Firewall_A {
 +  Firewall_A : -----------
 +  Firewall_A : A-Firewall
 +  Firewall_A : -----------
 +}
 +
 +state Internet {
 + state fremdgehostetes_System
 +  fremdgehostetes_System : Host beim Housing-Provider
 +  fremdgehostetes_System : Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>
 +  fremdgehostetes_System : IP-Adresse: aa-bb-cc-dd
 +}
 +
 + state DMZ {
 +  state bredmz {
 +    bredmz : EDMZ-Netzwerkswitch (bredmz)
 +    bredmz : Netz:10.0.0.0/24
 +  }
 +    state bridmz {
 +    bridmz : EDMZ-Netzwerkswitch (bridmz)
 +    bridmz : Netz:10.10.0.0/24
 +  }
 +  state edmz_switch {
 +    edmz_switch : EDMZ-Switch 
 +    edmz_switch : Netgear Typ: x
 +  }
 +
 +  
 +  state FWB {
 +    FWB : FQDN: vml000010.dmz.nausch.org
 +    FWB : ------------------------------------
 +    FWB : Services: iptables
 +  }
 +  state FWC {
 +    FWC : FQDN: vml000020.dmz.nausch.org
 +    FWC : ------------------------------------
 +    FWC : Services: iptables
 +  }
 +
 + state DMZ_HOSTs {
 +  state IDMZ_Repository_Host {
 +     IDMZ_Repository_Host : FQDN: vml000050.dmz.nausch.org
 +     IDMZ_Repository_Host : CNAME : syslog, tftp, install
 +     IDMZ_Repository_Host : IP (IDMZ) : eth0 - 52:54:00:19:08:67 - 10.0.0.50
 +     IDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe 
 +  }
 +  state EDMZ_Repository_Host {
 +     EDMZ_Repository_Host : FQDN: vml100080.dmz.nausch.org
 +     EDMZ_Repository_Host : CNAME : mail
 +     EDMZ_Repository_Host : IP (EDMZ) : eth0 - 52:54:00:14:12:71 - 10.0.0.50
 +     EDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe 
 +  }
 + }
 +}
 +
 +
 +state Intranet {
 +  state Switch {
 +    Switch : Physikalischer Netzwerk-Switch
 +    Switch : Netz 10.10.10.0/26
 +  }
 +  state Workstation {
 +    Workstation : Gerät: Django's Admin-Workstation
 +    Workstation : Hostname: pml010040
 +    Workstation : CNAME: office-work
 +    Workstation : MAC: 
 +    Workstation : IP:10.10.10.40
 +  }
 +}  
 +  
 +  FWB -down-> edmz_switch  
 +
 +  bredmz -down-> FWB  
 +  FWC -up-> bredmz
 +  FWC -up-> bridmz
 +  bredmz -up-> EDMZ_Repository_Host
 +
 +  bridmz -up-> IDMZ_Repository_Host
 +       
 +  Switch -up-> FWC
 +  
 +  Workstation -up-> Switch
 +
 +  edmz_switch --> Firewall_A
 +  Firewall_A -right-> fremdgehostetes_System
 +</uml>
 +
 +==== Lösung ====
 +=== manuelle Sprünge ===
 +Die vermutlich naheliegendste Variante ist vermutlich der jeweils manuelle Spring zum nächsten Host. Damit wir in unserem Beispiel die A-Firewall erreichen können springen wir nacheinander zum jeweilig nächsten Host. Mit Hilfe der Option **-A** nutzen wir dabei die SSH-Key-Forwarding-Option des SSH-Agenten. 
 +   $ ssh -A firewall-c.idmz.nausch.org
 +
 +   $ ssh -A firewall-b.edmz.nausch.org
 +
 +   $ ssh -A firewall-a.nausch.org
 +
 +Na ja, komfortabel ist das nicht gerade und beim Kopieren von Daten von Ende zu Ende nervt das doch gewaltig, oder?
 +
 +=== verkette Sprünge ===
 +O.K. wird sich da der ein oder andere sagen, dann verkette ich die Sprünge doch einfach. 
 +   $ ssh -A -t firewall-c.idmz.nausch.org ssh -A -t firewall-b.edmz.nausch.org ssh -A firewall-a.nausch.org
 +
 +Oder ich schreib mir jeweils kleine bash-scripte zum Springen
 +   $ vim ~/bin/fwa-jump
 +<file bash ~/bin/fwa-jump># /bin/bash
 +ssh -t -A -Y firewall-c.idmz.nausch.org 'ssh -Y -A -l swat maill.idmz.nausch.org'
 +</file>
 +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 und netcat ===
 +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.
 +   $ vim ~/.ssh/config
 +<file bash ~/.ssh/config># Django : 2012-06-13
 +# ssh-jumps über mehrere Sprunghosts
 +
 +# Erster Sprunghost (fwc) - direkt erreichbar
 +# Host -->  fwc
 +Host fwc
 +    Hostname firewall-c.idmz.nausch.org
 +
 +# Zweiter Sprunghost (fwb) - nur über fwc erreichbar
 +# Host -->  fwc --> fwb
 +Host fwb
 +    Hostname firewall-b.edmz.nausch.org
 +    ProxyCommand  ssh fwc nc -w 120 %h %p
 +
 +# Dritter Sprunghost (fwa) - nur über fwb erreichbar
 +# Host --> fwc --> fwb --> fwa 
 +Host fwa
 +    Hostname firewall-a.nausch.org
 +    ProxyCommand  ssh fwb nc -w 120 %h %p
 +
 +# externer Server im Internet nur über externe Firewall "A" erreichbar
 +# also: Host --> fwc --> fwb --> fwa --> daxie
 +Host daxie
 +    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
 +</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 ====
 +Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhostz direkt "sehen".
 +   $ ssh fwa
 +
 +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 daxie:/home/baby/Photos/Bild_001.png .
 +
 +====== Links ======
 +  * **[[wiki:start|Zurück zu Projekte und Themenkapitel]]**
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
 +