[buug-l] Umstellung auf ssh v2
Alexander Stielau
aleks@sailtraining.de
Wed, 19 Dec 2001 00:09:46 +0100
Am Mon, Dez 17, 2001 at 07:29:49 +0100 schrieb Alexander Stielau:
> ssh -1 username@buug.de cat .ssh/key2 >> .ssh/authorized_keys
Das ist latürnich flasch, Der Befehl muß in Tüddel. Also
ssh -1 username@buug.de "cat .ssh/key2 >> .ssh/authorized_keys"
Karl-Heinz hat ein Diskussionspaper zum Thema verfaßt, ich poste es
mal in Auszügen hier. Ich hätte wirklich gerne eine Diskussion hier
auf der Liste zu diesem Thema.
,----
| From: Karl-Heinz Haag <khaag@linux-ag.com>
|
| Aus erneut gegebenem Anlaß ganz aktuell:
| SSH ist vulnerable -- Es gibt mehrere ROOT-Kits und Exploits
|
| WAS TUN?
| -Antwort: NUR noch die SSH Protokoll-Version 2 verwenden!
|
| 1. Durch exploits betroffen ist SSH in der *Protkoll* Version *1*
| Die neuere *Protokoll*-Version *2* ist bis jetzt nicht exploitable.
|
| Version 2 von SSH ist von Grund auf neu implementiert.
| Version 1 und 2 sind *nicht* kompatibel zueinander; sowohl auf
| Server- als auch auf der Client-Seite.
|
| 2. Linux-Systeme verwenden meistens OpenSSH
| OpenSSH beherrscht (dank Markus Friedl) seit 4.5.2000 _beide_ Protokolle.
| http://www.openssh.org/goals.html
|
| 3. Default-Installationen von Linux-Systemen (+ssh-keygen auf User-Seite)
| aktivieren durch die Konfiguration das ALTE (unsichere) Protokoll mit OpenSSH!
| Dies wohl zu dem Zweck, abwärtskompatibel zu sein.
| OpenSSH macht es uns hier eindeutig zu leicht, beim unsicheren
| alten Protokoll zu bleiben.
|
| 3. Wie bei jedem anderen Netzwerkprotokoll treten bei SSH-Verbindungen ein
| SERVER und ein CLIENT in Aktion.
| Es sind weiterhin die Server-keys und die keys des Users im Spiel.
|
| Der Server (sshd) wartet auf Verbindungsanfragen; der
| Client (ssh) fragt einen Verbindungsaufbau an.
| keys: Server und Client identifizieren sich gegenseitig mit Ihren
| HostKeys und handeln einen gemeinsamen Sitzungsschlüssel aus.
| Mit dem public key des Users werden die eigenen Nachrichten
| verschlüsselt, die ssh mittels des private keys entschlüsselt.
|
|
| NOTWENDIGE UMSTELLUNGSMASSNAHMEN; Migration Version1 --> Version2
| Hier sind sowohl die Server- als auch Clientseite zu berücksichtigen.
| Die hinterlegten keys der Protokoll-Version 1 müssen überall erneuert werden
|
| 5. SERVER --> sshd sicher machen -- Aufgabe von root
| Konfigurationsdatei in /etc/ssh/sshd_config anpassen.
|
| Die sicherheitsrelevanten Einträge in sshd_config:
| Protocol 2,1 # erzwingt zunächst Connect mit Protokoll 2; Fallback nach 1
| # Wenn alle User-keys auf 2 umgestellt sind,
| # kann später (bald) die 1 entfernt werden
| HostKey /etc/ssh/ssh_host_key # der HostKey des Protokoll 1
| HostKey /etc/ssh/ssh_host_rsa_key # RSA HostKey des Protokolls 2
| HostKey /etc/ssh/ssh_host_dsa_key # DSA HostKey des Protokolls 2
|
| X11Forwarding no
| PasswordAuthentication no # zur Sicherheit!!, damit jeder
| # auch wirklich keys zum Login verwendet
| # Passwort-Login ist lokal exploitable!
| Nach den Änderungen sshd neu starten.
|
| 6. CLIENT --> ssh neu einstellen -- Aufgabe jedes Users
| a) Neuen SSH2-kompatiblen key erzeugen
|
| ssh-keygen -t dsa
|
| Der massgebliche Abschnitt der manpage hierzu:
| ssh-keygen generates, manages and converts authentication keys for
| ssh(1).
| ssh-keygen defaults to generating a RSA1 key for use by SSH pro
| tocol version 1. (sic!,KHH)
| Specifying the -t option instead creates a key for use
| by SSH protocol version 2.
|
| Auf jeden Fall sollte man dabei eine Passphrase übergeben; mit
| dieser wird der private key verschlüsselt und ist dadurch zur Verwendung
| von unautorisierten Personen einigermaßen sicher.
|
| b) Erzeugt wird das SSH-Protokoll2-kompatible Schlüsselpaar
| ~/.ssh/id_dsa
| und
| ~/.ssh/id_dsa.pub
| Den public key kann man nun an die Datei ~/.ssh/authorized_keys im
| gewünschten Zielsystem anhängen.
| Bei nicht ganz neuen OpenSSH-Versionen (vor 3.0.1p1) kann es sein,
| daß man die Datei ~/.ssh/authorized_keys2 verwenden muß.
|
| 7. VERBINDUNGSAUFNAHME mittels SSH Version 2
| Wirklich sichergehen, daß man sich mit dem Zielsystem via Version 2
| verbindet (was man sollte) kann man durch:
|
| ssh -2 username@zielsystem (zusätzliches -v zeigt, was passiert)
|
| Eindeutig erkennbar ist die Verbindung mittels Protokollversion 2 bei
| Verwendung der Option -v (verbose) an dem String:
| "ssh-userauth2 successful: method publickey"
| Zusatz:
| Das Anlegen einer ~/.ssh/config -Datei mit default-Eintrag, ssh v2 zu
| benutzen, hat im Selbsttest _nicht_ funktioniert.
|
| 8. ERLEICHTERUNGEN: ssh-agent + ssh-add nutzen
| Damit man nicht bei jeder Verbindung zu einem ssh-server seine
| Passphrase aufs Neue angeben muß, kann man mit dem ssh-agent arbeiten.
| Das geht aus einem Xterm heraus so:
|
| ssh-add ~/.ssh/id_dsa
| Enter passphrase for id_dsa: <passphrase eingeben>
| Identity added: id_dsa (id_dsa)
|
| Von nun an ist es während der laufenden X-Session ohne Angabe der
| passphrase möglich, sich mit 'ssh -2 username@host' auf andere Rechner
| einzuloggen.
| Bei Shell-Benutzung (ohne X) bedient man sich des ssh-agents so:
| ssh-agent $SHELL
| ssh-add ~/.ssh/id_dsa
| (weiter wie oben)
|
| 9. WINDOWS-Spezifika
| Durch einen Kunden war heute zu erfahren, daß Client-Programme putty/winscp
| keinen dsa-key erzeugen können. [für OpenSSH _die_ bevorzugte Schlüsselmethode]
| Die sshd-Server sind jedoch in der Grundeinstellung so konfiguriert,
| daß sie mit rsa-keys von clients umgehen können müßten.
| Das schließe ich aus der Zeile: HostKey /etc/ssh/ssh_host_rsa_key
| in den /etc/ssh/sshd_config auf aktuellen Linux-Installationen.
|
|
| **ADDONS und weitere Informationen** (wenn Muße ist ...)
|
| Nur noch SSH2 benutzen?
| http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.12
| 1.12 . Shouldn't I be using only SSH2?
| There are structural weaknesses in SSH1 which leave it open to additional
| attacks
| SSH1 is subject to a man-in-the-middle attack
| SSH1 has more supported platforms
| SSH1 supports .rhosts authentication (it's against the draft for SSH2
| SSH1 has more diverse authentication support (AFS, Kerberos, etc.)
| Performance for SSH2 is not equal to SSH1
|
| Unterschiede zwischen SSH Protokoll 1 und 2
| http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.8
| 1.8 What is the difference between SSH1 and SSH2?
| The difference between SSH1 and SSH2 is they are two entirely different
| protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1
| uses server and host keys to authenticate systems where SSH2 only uses host
| keys. SSH2 is a complete rewrite of the protocol, and it does not use the
| same networking implementation that SSH1 does. Also, SSH2 is more secure.
|
| Because of the different protocol implementation, they are not compatible.
|
| In a nutshell, SSH2 is a rewrite of the SSH1 protocol, with improvements to
| security, performance, and portability.
|
| Die obigen Zitate beziehen sich auf die kommerziellen Varianten von SSH1 und
| SSH2 - nicht auf OpenSSH.
| OpenSSH ist eine eingenständige Weiter-/Neuentwicklung, die auf der von
| ssh.com [© SSH Communications Security] freigegebenen Version 1.3(?) aufbaut.
| Alle _protokoll_-bezogenen Aussagen betreffen jedoch auch die
| OpenSSH-Implementierung.
| Beim aktuellen OpenSSH ist es eine Frage der *Konfiguration*, welches Protokoll
| verwendet wird. Das Nähere dazu ist oben ausgeführt.
|
| Ein schon älterer exploit von SSH protocol 1 ist hier beschrieben:
| http://www.securityfocus.com/archive/1/161150
| Es gibt weitere (neuere).
| U.a. kann man mit dsniff (-->sshmitm) Verbindungaufnahmen Client-Server
| kapern und/oder mithören. Mit Protokoll 2 kann dsniff das jedoch nicht.
| http://www.monkey.org/~dugsong/dsniff/faq.html#How do I sniff / hijack HTTPS / SSH connections
|
| Die Exploitbarkeit von eingeschalteter PasswordAuthenitcation kann gefunden
| werden über die Stichworte "uselogin exploit" auf www.google.com
`----
Wer das gelesen hat und sich mal in die zitierten Links einliest,
dem wird wahrscheinlich auch etwas die Muffe gehen.
Mir z.B. war zwar klar, das es immer wieder ssh-Probleme gab, ich bin
aber nie ernsthaft der Ursache gefolgt, sondern habe einfach immer
eine aktuellere Version eingespielt, die aber - wie ich nun weiß - durch die zitierte
Abwärts-Kompatibilität zumindest prinzipiell auch gefährdet ist.
Aleks
(Das Reply-to der Liste zeigt immer auf den Autor, für eine
Listendiskussion an buug-l@buug.de antworten)
--
Der Schrauber schafft, der Hebel waechst,
es steigt die Kraft, die Schraube aechzt.
Zu spaet merkt erst die Grosshirnrinde -
die Schraube trug ein Linksgewinde.