Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| centos:ssh-install [14.06.2012 19:35. ] – [System-Skizze] django | centos:ssh-install [12.10.2024 12:46. ] (aktuell) – Deppenapostroph entfernt django | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== Secure Shell - ssh ====== | ||
| + | {{: | ||
| + | |||
| + | ===== openSSH - Programmsuite ===== | ||
| + | Die für die **// | ||
| + | * 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, | ||
| + | < | ||
| + | Name : openssh | ||
| + | Version | ||
| + | ... | ||
| + | |||
| + | ... | ||
| + | Signature | ||
| + | Packager | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | 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' | ||
| + | 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, | ||
| + | /etc/ssh | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | ==== openssh-clients ==== | ||
| + | Beim Paket **openssh-clients** wird mitgeliefert: | ||
| + | < | ||
| + | Name : openssh-clients | ||
| + | Version | ||
| + | ... | ||
| + | |||
| + | ... | ||
| + | Signature | ||
| + | Packager | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | 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. | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | ==== openssh-server ==== | ||
| + | Hingegen liefert uns **openssh-server** folgende Dateien: | ||
| + | < | ||
| + | Name : openssh-server | ||
| + | Version | ||
| + | ... | ||
| + | |||
| + | ... | ||
| + | Signature | ||
| + | Packager | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | 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/ssh | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | ==== openssh-askpass ==== | ||
| + | Zu guter Letzt sehen wir uns noch das Paket **openssh-askpass** genauer an: | ||
| + | < | ||
| + | Name : openssh-askpass | ||
| + | Version | ||
| + | ... | ||
| + | |||
| + | ... | ||
| + | Signature | ||
| + | Packager | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | 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. | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | ===== ssh in der Praxis ===== | ||
| + | Auch wenn das Passwort bei **ssh** verschlüsselt übertragen wird, lohnt ein Blick auf die Alternative | ||
| + | Einfacher geht dies über asymetrische Schlüssel. | ||
| + | ==== Erzeugung eines Schlüssel | ||
| + | Als erstes erzeugen wir uns einen Schlüssel für die Authentifizierung: | ||
| + | < | ||
| + | Generating public/ | ||
| + | Enter file in which to save the key (/ | ||
| + | Enter passphrase (empty for no passphrase): | ||
| + | Enter same passphrase again: | ||
| + | Your identification has been saved in / | ||
| + | Your public key has been saved in / | ||
| + | The key fingerprint is: | ||
| + | 2b: | ||
| + | |||
| + | Die // | ||
| + | |||
| + | Nun liegen in dem Verzeichnis **/ | ||
| + | < | ||
| + | insgesamt 24 | ||
| + | -rw------- 1 django django 3311 22. Apr 22:11 id_rsa | ||
| + | -rw-r--r-- 1 django django | ||
| + | |||
| + | **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**, | ||
| + | ==== 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]$ | ||
| + | |||
| + | 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 // | ||
| + | |||
| + | $ ssh-copy-id -i ~/ | ||
| + | |||
| + | Die Angabe '' | ||
| + | '' | ||
| + | </ | ||
| + | ==== authorized_keys vs. authorized_keys2 ==== | ||
| + | <WRAP round info>Bei der Einführung von SSH Version 2 kam die Datei '' | ||
| + | |||
| + | ===== ssh-Daemon ===== | ||
| + | ==== ssh-Daemon einrichten/ | ||
| + | |||
| + | Folgende Zeilen müssen wir in der Datei **/ | ||
| + | # vim / | ||
| + | < | ||
| + | RSAAuthentication yes | ||
| + | PubkeyAuthentication yes | ||
| + | AuthorizedKeysFile .ssh/ | ||
| + | |||
| + | 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 **/ | ||
| + | # vim / | ||
| + | |||
| + | 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> | ||
| + | |||
| + | 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!</ | ||
| + | ==== 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 | ||
| + | |||
| + | 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 / | ||
| + | | ||
| + | Dort legen wir die Datei **ssh-add.desktop** mit folgendem Inhalt an: | ||
| + | < | ||
| + | Name=No name | ||
| + | Encoding=UTF-8 | ||
| + | Version=1.0 | ||
| + | Exec=ssh-add | ||
| + | X-GNOME-Autostart-enabled=true</ | ||
| + | Somit wird beim nächsten Amelden am // | ||
| + | |||
| + | ===== 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 < | ||
| + | fremdgehostetes_System : IP-Adresse: aa-bb-cc-dd | ||
| + | } | ||
| + | |||
| + | state DMZ { | ||
| + | state bredmz { | ||
| + | bredmz : EDMZ-Netzwerkswitch (bredmz) | ||
| + | bredmz : Netz: | ||
| + | } | ||
| + | state bridmz { | ||
| + | bridmz : EDMZ-Netzwerkswitch (bridmz) | ||
| + | bridmz : Netz: | ||
| + | } | ||
| + | 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 { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | } | ||
| + | state EDMZ_Repository_Host { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | } | ||
| + | } | ||
| + | } | ||
| + | |||
| + | |||
| + | state Intranet { | ||
| + | state Switch { | ||
| + | Switch : Physikalischer Netzwerk-Switch | ||
| + | Switch : Netz 10.10.10.0/ | ||
| + | } | ||
| + | state Workstation { | ||
| + | Workstation : Gerät: Djangos Admin-Workstation | ||
| + | Workstation : Hostname: pml010040 | ||
| + | Workstation : CNAME: office-work | ||
| + | Workstation : MAC: | ||
| + | Workstation : IP: | ||
| + | } | ||
| + | } | ||
| + | | ||
| + | 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 | ||
| + | </ | ||
| + | |||
| + | ==== 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 ~/ | ||
| + | <file bash ~/ | ||
| + | ssh -t -A -Y firewall-c.idmz.nausch.org 'ssh -Y -A -l swat maill.idmz.nausch.org' | ||
| + | </ | ||
| + | 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 ~/ | ||
| + | <file bash ~/ | ||
| + | # ssh-jumps über mehrere Sprunghosts | ||
| + | |||
| + | # Erster Sprunghost (fwc) - direkt erreichbar | ||
| + | # Host --> | ||
| + | Host fwc | ||
| + | Hostname firewall-c.idmz.nausch.org | ||
| + | |||
| + | # Zweiter Sprunghost (fwb) - nur über fwc erreichbar | ||
| + | # Host --> | ||
| + | Host fwb | ||
| + | Hostname firewall-b.edmz.nausch.org | ||
| + | ProxyCommand | ||
| + | |||
| + | # Dritter Sprunghost (fwa) - nur über fwb erreichbar | ||
| + | # Host --> fwc --> fwb --> fwa | ||
| + | Host fwa | ||
| + | Hostname firewall-a.nausch.org | ||
| + | ProxyCommand | ||
| + | |||
| + | # externer Server im Internet nur über externe Firewall " | ||
| + | # also: Host --> fwc --> fwb --> fwa --> daxie | ||
| + | Host daxie | ||
| + | Hostname < | ||
| + | ProxyCommand | ||
| + | </ | ||
| + | |||
| + | Anschließend passen wir noch die Dateiberechtigungen an, damit **ssh** später nicht mäkelt. | ||
| + | $ chmod 600 ~/ | ||
| + | |||
| + | 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 " | ||
| + | $ ssh fwa | ||
| + | |||
| + | Auch können wir nun ohne großem Heckmeck Dateien von einem Ende zum anderen Ende kopieren. | ||
| + | $ scp ~/ | ||
| + | |||
| + | $ scp daxie:/ | ||
| + | |||
| + | ====== Links ====== | ||
| + | * **[[wiki: | ||
| + | * **[[http:// | ||
| + | |||