From owner-svn-doc-all@freebsd.org Sun May 15 22:43:54 2016 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32A1BB3BE4C; Sun, 15 May 2016 22:43:54 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAF711E11; Sun, 15 May 2016 22:43:53 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u4FMhrec017830; Sun, 15 May 2016 22:43:53 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u4FMhrO8017829; Sun, 15 May 2016 22:43:53 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201605152243.u4FMhrO8017829@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Sun, 15 May 2016 22:43:53 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48817 - head/de_DE.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 22:43:54 -0000 Author: bhd Date: Sun May 15 22:43:52 2016 New Revision: 48817 URL: https://svnweb.freebsd.org/changeset/doc/48817 Log: Update to r44520: Editorial review of first 1/2 of OpenSSH chapter. Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Sun May 15 14:42:05 2016 (r48816) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Sun May 15 22:43:52 2016 (r48817) @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $ - basiert auf: r44444 + basiert auf: r44520 --> Sicherheit @@ -2591,25 +2591,23 @@ racoon_enable="yes" OpenSSH stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. Zusätzlich - können TCP/IP-Verbindungen sicher durch SSH - weitergeleitet (getunnelt) werden. Mit SSH - werden alle Verbindungen verschlüsselt, dadurch wird verhindert, - dass die Verbindung zum Beispiel abgehört oder übernommen - (Hijacking) werden kann. - - OpenSSH wird vom OpenBSD-Projekt - gepflegt und wird in der Voreinstellung von &os; installiert. - OpenSSH ist mit den - SSH-Protokollen der Versionen 1 und 2 - kompatibel. - - Wenn Daten unverschlüsselt über das Netzwerk gesendet - werden, besteht die Gefahr, dass Benutzer/Passwort - Kombinationen oder alle Daten an beliebiger Stelle zwischen - dem Client und dem Server abgehört werden. Mit - OpenSSH stehen eine Reihe von - Authentifizierungs- und Verschlüsselungsmethoden zur - Verfügung, um das zu verhindern. + können TCP/IP-Verbindungen sicher durch + SSH getunnelt oder weitergeleitet werden. + OpenSSH verschlüsselt alle + Verbindungen. Dadurch wird beispielsweise verhindert, dass die + Verbindung abgehört oder übernommen + (Hijacking) werden kann. Weitere + Informationen zu OpenSSH finden Sie + auf + http://www.openssh.com/. + + Dieser Abschnitt enthält einen Überblick über die + integrierten Client-Werkzeuge, mit denen Sie sicher auf + entfernte Systeme zugreifen können, oder mit denen Sie sicher + Dateien austauschen können. Der Abschnitt beschreibt auch die + Konfiguration eines SSH-Servers auf einem + &os;-System. Weitere Informationen finden Sie in den hier + erwähnten Manualpages. Die SSH Client-Werkzeuge benutzen @@ -2619,36 +2617,44 @@ racoon_enable="yes" Client - Benutzen Sie &man.ssh.1; um sich mit einem System zu - verbinden, auf dem &man.sshd.8; läuft. Verwenden Sie dazu - den Benutzernamen und den Namen des Rechners, mit dem Sie - sich verbinden möchten: + Benutzen Sie ssh zusammen mit einem + Benutzernamen und einer IP-Adresse oder dem + Hostnamen, um sich an einem SSH-Server + anzumelden. Ist dies das erste Mal, dass eine Verbindung mit + dem angegebenen Server hergestellt wird, wird der Benutzer + aufgefordert, zuerst den Fingerabdruck des Servers zu + prüfen: &prompt.root; ssh user@example.com -Host key not found from the list of known hosts. +The authenticity of host 'example.com (10.0.0.1)' can't be established. +ECDSA key fingerprint is 25:cc:73:b5:b3:96:75:3d:56:19:49:d2:5c:1f:91:3b. Are you sure you want to continue connecting (yes/no)? yes -Host 'example.com' added to the list of known hosts. -user@example.com's password: ******* +Permanently added 'example.com' (ECDSA) to the list of known hosts. +Password for user@example.com: user_password SSH speichert einen Fingerabdruck des - Serverschlüssels. Die Aufforderung, yes - einzugeben, erscheint nur bei der ersten Verbindung zu einem - Server. Weitere Verbindungen zu dem Server werden gegen den - gespeicherten Fingerabdruck des Schlüssels geprüft und - der Client gibt eine Warnung aus, wenn sich der empfangene - Fingerabdruck von dem gespeicherten unterscheidet. Die - Fingerabdrücke werden in - ~/.ssh/known_hosts gespeichert. + Serverschlüssels um die Echtheit des Servers zu überprüfen, + wenn der Client eine Verbindung herstellt. Wenn der Benutzer + den Fingerabdruck mit yes bestätigt, wird + eine Kopie des Schlüssels in + .ssh/known_hosts im Heimatverzeichnis des + Benutzers gespeichert. Zukünftige Verbindungen zu dem Server + werden gegen den gespeicherten Fingerabdruck des Schlüssels + geprüft und der Client gibt eine Warnung aus, wenn sich der + empfangene Fingerabdruck von dem gespeicherten unterscheidet. + Wenn dies passiert, sollte zunächst geprüft werden, ob sich + der Schlüssel geändert hat, bevor die Verbindung hergestellt + wird. In der Voreinstellung akzeptieren aktuelle Versionen von - &man.sshd.8; nur SSH v2 Verbindungen. - Wenn möglich, wird der Client versuchen Version 2 zu - verwenden, ist dies nicht möglich, fällt er auf Version 1 - zurück. Der Client kann gezwungen werden, nur eine der beiden - Versionen zu verwenden, indem die Option - oder übergeben wird. Die Unterstützung - für Version 1 ist nur noch aus Kompatibilitätsgründen zu - älteren Versionen enthalten. + OpenSSH; nur + SSHv2 Verbindungen. Wenn möglich, wird der + Client versuchen Version 2 zu verwenden, ist dies nicht + möglich, fällt er auf Version 1 zurück. Der Client kann + gezwungen werden, nur eine der beiden Versionen zu verwenden, + indem die Option oder + übergeben wird. Weitere Optionen sind in &man.ssh.1; + beschrieben. OpenSSH @@ -2657,65 +2663,64 @@ user@example.com's password: &man.scp.1; Mit &man.scp.1; lassen sich Dateien in einer sicheren - Weise auf entfernte Maschinen übertragen. + Weise auf entfernte Maschinen übertragen. Dieses Beispiel + kopiert die Datei COPYRIGHT von einem + entfernten System in eine Datei mit dem gleichen Namen auf + das lokale System: &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT -user@example.com's password: +Password for user@example.com: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; - Da der Fingerabdruck schon im vorigen Beispiel abgespeichert - wurde, wird er bei der Verwendung von scp in - diesem Beispiel überprüft. Da die Fingerabdrücke - übereinstimmen, wird keine Warnung ausgegeben. - - Die Argumente, die &man.scp.1; übergeben werden, gleichen - denen von &man.cp.1; in der Beziehung, dass die ersten - Argumente die zu kopierenden Dateien sind und das letzte - Argument den Bestimmungsort angibt. Da die Dateien über das - Netzwerk kopiert werden, können ein oder mehrere Argumente die - Form + Da der Fingerabdruck für diesen Rechner bereits bestätigt + wurde, wird er automatisch überprüft, bevor der Benutzer zur + Eingabe des Passworts aufgefordert wird. + + Die Argumente, die scp übergeben + werden, gleichen denen von cp in der + Beziehung, dass die ersten Argumente die zu kopierenden + Dateien sind und das letzte Argument den Bestimmungsort + angibt. Da die Dateien über das Netzwerk kopiert werden, + können ein oder mehrere Argumente die Form + besitzen. Schlüsselbasierte Authentifizierung - Mit &man.ssh-keygen.1; können DSA- oder - RSA-Schlüssel für einen Benutzer erzeugt - werden, die anstelle von Passwörtern verwendet werden - können: + Ein Client kann bei der Verbindung auch Schlüssel + anstelle von Passwörtern verwenden. Mit + ssh-keygen können DSA- + oder RSA-Schlüssel erzeugt werden. Geben + Sie das entsprechende Protokoll an, wenn Sie einen + öffentlichen und einen privaten Schlüssel erzeugen. Folgen + Sie anschließend den Anweisungen des Programms. Es wird + empfohlen, die Schlüssel mit einer einprägsamen, aber schwer + zu erratenen Passphrase zu schützen. &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. -Enter passphrase (empty for no passphrase): -Enter same passphrase again: +Enter passphrase (empty for no passphrase): type some passphrase here which can contain spaces +Enter same passphrase again: type some passphrase here which can contain spaces Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com - &man.ssh-keygen.1; erzeugt einen öffentlichen und einen - privaten Schlüssel für die Authentifizierung. Der private - Schlüssel wird in ~/.ssh/id_dsa oder - ~/.ssh/id_rsa gespeichert, während - sich der öffentliche Schlüssel in - ~/.ssh/id_dsa.pub oder - ~/.ssh/id_rsa.pub befindet, je nachdem, - ob es sich um einen DSA- oder einen - RSA-Schlüssel handelt. - Der öffentliche Schlüssel muss sowohl für - RSA- als auch für - DSA-Schlüssel in - ~/.ssh/authorized_keys auf dem entfernten - Rechner aufgenommen werden, damit der Schlüssel - funktioniert. - - Damit werden Verbindungen zu der entfernten Maschine über - SSH-Schlüsseln anstelle von Passwörtern - authentifiziert. + Abhängig vom verwendeten Protokoll wird der private + Schlüssel in ~/.ssh/id_dsa (oder + ~/.ssh/id_rsa) und der öffentliche + Schlüssel in ~/.ssh/id_dsa.pub (oder + ~/.ssh/id_rsa.pub) gespeichert. Der + öffentliche Schlüssel muss zuerst auf + den entfernten Rechner nach + ~/.ssh/authorized_keys kopiert werden, + damit die schlüsselbasierte Authentifizierung + funktioniert. Viele Benutzer denken, dass die Verwendung von @@ -2736,12 +2741,10 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 IP-Adresse anmelden darf. - Die Optionen und Dateinamen sind abhängig von der OpenSSH-Version. Die für das System gültigen Optionen finden Sie in &man.ssh-keygen.1;. - Wenn bei der Erzeugung des Schlüssels eine Passphrase angegeben wurde, wird der Benutzer bei jeder Anmeldung am @@ -2751,44 +2754,45 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 laden, damit die Passphrase nicht jedes Mal eingegeben werden muss. - &man.ssh-agent.1; übernimmt die Authentifizierung - von ihm geladener privater Schlüssel. - &man.ssh-agent.1; sollte nur dazu verwendet werden, ein - anderes Programm zu starten, beispielsweise eine Shell oder - einen Window-Manager. - - Um &man.ssh-agent.1; in einer Shell zu verwenden, muss - es mit einer Shell als Argument aufgerufen werden. Zudem muss - die zu verwaltende Identität mit &man.ssh-add.1; sowie deren - Passphrase für den privaten Schlüssel übergeben werden. - Nachdem dies erledigt ist, kann sich ein Benutzer über - &man.ssh.1; auf jedem Rechner anmelden, der einen - entsprechenden öffentlichen Schlüssel besitzt. Dazu ein - Beispiel: + ssh-agent übernimmt die + Authentifizierung mit den geladenen privaten Schlüsseln. + ssh-agent sollte nur dazu verwendet werden, + ein anderes Programm zu starten, beispielsweise eine Shell + oder einen Window-Manager. + + Um ssh-agent in einer Shell zu + verwenden, muss es mit einer Shell als Argument aufgerufen + werden. Zudem muss die zu verwaltende Identität mit + ssh-add sowie deren Passphrase für den + privaten Schlüssel übergeben werden. Nachdem dies erledigt + ist, kann sich ein Benutzer mit ssh auf + jedem Rechner anmelden, der einen entsprechenden öffentlichen + Schlüssel besitzt. Dazu ein Beispiel: &prompt.user; ssh-agent csh &prompt.user; ssh-add -Enter passphrase for /home/user/.ssh/id_dsa: -Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) +Enter passphrase for /usr/home/user/.ssh/id_dsa: type passphrase here +Identity added: /usr/home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; - Um &man.ssh-agent.1; unter - &xorg; zu verwenden, muss - &man.ssh-agent.1; in ~/.xinitrc + Um ssh-agent unter + &xorg; zu verwenden, muss ein + Eintrag für das Programm in ~/.xinitrc aufgenommen werden. Dadurch können alle unter &xorg; gestarteten Programme die - Dienste von &man.ssh-agent.1; nutzen. + Dienste von ssh-agent nutzen. ~/.xinitrc könnte etwa so aussehen: exec ssh-agent startxfce4 Dadurch wird bei jedem Start von - &xorg; zuerst &man.ssh-agent.1; - aufgerufen, das wiederum XFCE - startet. Nachdem diese Änderung durchgeführt wurde, muss + &xorg; zuerst + ssh-agent aufgerufen, das wiederum + XFCE startet. Nachdem diese + Änderung durchgeführt wurde, muss &xorg; neu gestartet werden. - Danach können Sie mit &man.ssh-add.1; die + Danach können Sie mit ssh-add die SSH-Schlüssel laden.