![[OpenSSH]](../images/smalltitle.gif){kind=small}
OpenSSH is fast komplett kompatibel mit dem kommerziellenl SSH 1.2.x. Es gibt aber trotzdem ein paar Ausnahmen, die du im Kopf behalten musst, wenn du ein Upgrade machst oder SSH zu einem System hinzufügen willst, das nicht standardmässig mit SSH ausgeliefert wird.
Der OpenSSH Client benutzt die unteren Ports für rhosts und rhosts-rsa Authentifikation, weil der Server dem Usernamen vertrauen muss, der vom Client geliefert wird.
Um SSH davon abzuhalten, füge einfach
UsePrivilegedPort noin deine ssh_config oder ~/.ssh/config Dateien ein, entferne das setuid Bit vom ssh Programm oder füge
-o "UsePrivilegedPort no"in deine ssh ode scp Kommandzeile ein.
Der ssh client muss einen niedrigen port für die rhosts und rhosts-rsa Authentifikation benutzen. Du kannst das setuid Bit vom ssh Programm entfernen, wenn du diese Authentifikation nicht benutzen willst.
In OpenSSH 2.3.0 hat Markus Friedl Unterstützung für einen SFTP Server hinzugefügt, der das SFTP Protokoll implementiert, das von mehreren kommerziellen SSH Clients benutzt wird. Mehr Informationen gibt in der sshd manpage unter der Subsystem Option.
SSH 2.3 und frühere Versionen haben einen Fehler in der HMAC Implementation. Ihr Code hat nicht den kompletten Datenblock aus der Auswahl bereitgestellt, sondern stattdessen immer 128 Bits. Bei längeren Auswahlen führte das dazu, dass SSH 2.3 nicht mit OpenSSH zusammenarbeitet.
OpenSSH 2.2.0 kennt diesen Fehler von SSH 2.3. Zukünftige Versionen von SSH werden diesen Fehler nicht mehr haben.
Im SSH1 Modus können nur 3DES und Blowfish ausgewählt werden. Im SSH2 Modus können zur Zeit nur 3DES, Blowfish, CAST128 oder Arcfour ausgewählt werden. Der patentierte und veraltete IDEA Algoritmus wird nicht unterstützt.
Dieser Unterschied kann sich darin manifestieren ,dass sich das ssh Kommando weigert, Config-Files aus einer vorhergehenden Installation des kommerziellen ssh zu lesen.
Lösung: Editiere /etc/ssh/ssh_config und wähle eine andere Cipher Option ("3des" oder "blowfish").
Die alten Versionen von SSH benutzen einen patientierten Algorithmus um ihren /etc/ssh/ssh_host_key. Dieses Problem wird sich darin manifestieren, dass der sshd nicht mehr in der Lage ist, seinen eigenen 'host-key' zu lesen.
Lösung: Du wirst die kommerzielle Version von ssh-keygen für den privaten key des Host's anwenden müssen:
# ssh-keygen -u -f /etc/ssh/ssh_host_keyDas wird den Key zu 3DES "upgraden".
OpenSSH erweitert das sshd_config Dateiformat in einer ganzen Reihe von Dingen. Momentan gibt es genau eine Änderung, die inkompatibel mit der alten Form ist.
Kommerzielles SSH kontrollierte Logging mit Hilfe der QuietMode und FascistLogging Direktiven. OpenSSH führt ein allgemeines Set von Loggingoptionen ein, nämlich SyslogFacility und LogLevel. Siehe sshd Manual Page.
Das ssh-keygen Programm des kommerziellen SSH beinhaltet einen Bug, der dazu führt, dass ab und zu ein RSA Schlüssel generiert wird, bei dem das Most Significant Bit (MSB) nicht gesetzt ist. Solche Schlüssel werden als solche mit voller Länge ausgegeben, sind tatsächlich aber die Hälfte der Zeit nur halb so lang wie angegeben.
OpenSSH wird Warnhinweise ausgeben, wenn es solche Schlüssel bemerkt. Um diese Hinweise loszuwerden editiere deine known_hosts Datei und ersetze die unkorrekte Schlüssellänge (für gewöhlich"1024") mit der korrekten Schlüssellänge (für gewöhnlich "1023"). Wie auch immer, wie vorher bereits gesagt sind diese Schlüssel weniger sicher, so dass es am besten ist, einfach neue zu erzeugen.
OpenSSH generiert unechte Authentifikationsfehlschläge bei jedem login, etwa so:
"authentication failure; (uid=0) -> root for sshd service"Diese werden generiert, da OpenSSH zuerst prüft, ob ein User Authentifikation zum Login benötigt (z.B. leeres Passwort). Unglücklicherweise logt PAM alle Authenfikationsvorkommnisse, inklusive dieses.
Wenn dich das zu sehr stört, setze PermitEmptyPasswords in sshd_config auf "no". Das wird zwar die Warnmeldung abschalten, verhindert aber auch das Einloggen ohne gesetztes Passwort. Das ist übrigens die Standardeinstellung wenn du mit dem mitgelieferten sshd_config File arbeitest.
Um leere Passwörter bei einer Version von OpenSSH zu gestatten, die mit PAM erzeugt wurde, musst du das Flag nullok am Ende des Password Checking Moduls in der /etc/pam.d/sshd Datei setzen. Zum Beispiel:
auth required/lib/security/pam_unix.so shadow nodelay nullokDas muss zusätzlich zum Setzen von PermitEmptyPasswords "yes" in der sshd_config Datei geschehen.
Es gibt ein Problem mit dem Benutzen von leeren Passwörtern mit PAM Authentifikation: PAM erlaubt jegliches Passwort beim Authentifizieren eines Accounts mit leerem Passwort. Das setzt den Check ausser Kraft, den sshd benutzt, um festzustellen ob ein Account kein Passwort gesetzt hat und gibt den Zugang zum Account frei, unabhängig davon, wie die Policy in PermitEmptyPasswords ist. Aus diesem Grund wird empfohlen die nullok Direktive nicht in deine PAM Konfigurationsdatei aufzunehmen, es sei denn du willst unbedingt leere Passwörter erlauben.
Überprüfe deine ssh_config und sshd_config. Die Standard- Konfigurationsdatei schaltet die Authentifikation für agent und X11 forwarding ab.
Mandrake Linux 7.2 verändert auch die XAUTHORITY Umgebungsvariable in /etc/skel/.bashrc und daher jedes Heimatverzeichnis der Bash-Benützer. Dies verhindert X11 forwarding, es sei denn, die folgende Zeile ist auskommentiert: "export XAUTHORITY=$HOME/.Xauthority"
Die mit Redhat 6.1 ausgeliferte glibc2.1 scheint eine lange Zeit zu benötigen um "IPv6 oder IPv4" Addressen von Domainnamen aufzulösen. Das kann umgangen werden, indem man die --with-ipv4-default Konfigurations-Option benutzt. Die weist OpenSSH an, nur IPv4 Adressauflösung zu benutzen. (IPv6 lookups können trotzdem mit Hilfe der -6 Option gemacht werden).
Selected cipher type idea not supported by serverDieser Fehler wird erzeugt, wenn ein kommerzielles ssh, das mit der Option 'idea' Chiffre konfiguriert wurde, versucht einen OpenSSH Server zu kontaktieren. Um das geradezubiegen, wähle eine andere Chiffre in den ssh_config oder ~/.ssh/config Dateien (3des für Sicherheit oder blowfish für Geschwindigkeit).
Der Linux kernel prüft (via modprobe) ob die Protokollfamilie 10 (IPv6) da ist. Lade entweder das entsprechende Kernelmodul, trag den entsprechenden Alias in /etc/modules.conf ein oder schalte IPv6 in /etc/modules.conf ab.
Aus einem blödsinnigen Grund kann /etc/modules.conf auch als /etc/conf.modules benannt sein.
Linke OpenSSH mit libcrypt:
LIBS=-lcrypt ./configure [options]
Stelle sicher, dass deine OpenSSL libraries mit eingebauter RSA Unterstützung entweder intern oder mit Hilfe von RSAref erzeugt wurden.
scp muss im Standard-Pfad (PATH) sowohl im Server als auch im Client sein. Möglicherweise musst du auch die --with-default-path Option setzen, um einen gewünschten Pfad auf dem Server anzugeben, in dem gesucht werden soll. Diese Option ersetzt den Standardpfad, so dass du alle momentan enthaltenen Verzeichnisse angeben musst, und ausserdem muss scp installiert sein. Zum Beispiel:
./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
Einige Betriebssysteme setzen /dev/tty mit falschen Modi, was das Lesen von Passwörtern verhindert, und folgenden Fehlercode erzeugt:
You have no controlling tty. Cannot read passphrase.Die Lösung dazu ist, die Rechte von /dev/tty auf Modus 0666 zu setzen und den Fehler als Bug an den Betriebssystemhersteller oder Distributor zu schicken.
Wenn es in der tar.gz-Datei, die du runtergeladne hast, keine 'configure' Datei gibt, oder make mit der Fehlermeldung "missing separator" versagt, hast du wahrschienlich die OpenBSD Distribution von OpenSSH heruntergeladen und versuchst sie auf einer anderen Plattform zu kompilieren. Bitte lies die Information auf der Seite der portablen Version.
OpenSSH bietet Unterstützung für sowohl das SSH1 als auch das SSH2 Protokoll.
Das SSH1 Protokoll benutzt den RSA Algorithmus, welcher bis zum 21. September diesen Jahres innerhalb der USA einem Patent unterlag. Ausserhalb der USA war nichts davon jemals relevant.
Das SSH2 Protokoll benutzt DH und DSA, zwei andere Algorithmen, die keinen ärgerlichen Patenten unterliegen. Wenn du die Benutzugn des SSH1 Protokolls vermeiden kannst, und nur das SSH2 Protokoll benutzt, brauchst du dir um nichts Gedanken zu machen. Du wirst dann aber trotzdem SSH2-kompatible Clients und Server für deine anderen Maschinen finden müssen. Für einige User kann das ein kleines Problem werden, da uns zur Zeit keine freien SSH2 Windows Clients bekannt sind.
Da das RSA Patent abgelaufen ist, gibt es keinerlei Beschränkungen mehr bei der Benutzung von Software mit dem RSA Algorithmus, inklusive OpenBSD.
www@openbsd.org