![[OpenSSH]](../images/smalltitle.gif){kind=small}
1.0 - Was ist OpenSSH und wo kann ich sie bekommen?
- 1.1 - Was ist OpenSSH und wo kann ich sie herunterladen?
- 1.2 - Warum sollte sie eingesetzt werden?
- 1.3 - Welche Betriebssysteme werden unterstützt?
- 1.4 - Was ist mit Copyrights, Benutzung und Patenten?
- 1.5 - Wo sollte ich um Hilfe fragen?
- 1.6 - Ich habe einen Fehler gefunden. Wo melde ich ihn?
2.0 - Allgemeine Fragen
- 2.1 - Warum benutzt ssh/scp Verbindungen auf den unteren Ports? Meine Firewall blockiert diese.
- 2.2 - Warum ist der ssh-Client setuid root?
- 2.3 - Warum hat SSH 2.3 Probleme beim Interoperieren mit OpenSSH 2.1.1?
- 2.4 - Warum gibt OpenSSH Folgendes aus: Dispatch protocol error: type 20
- 2.5 - Alte Versionen des kommerziellen SSH verschlüsseln Hostkeys mit IDEA.
- 2.6 - Was sind das für Warnmeldungen über Schlüssellängen?
- 2.7 - X11- und/oder Agent-Weiterleitung funktioniert nicht.
- 2.8 - Nach dem Upgrade auf OpenSSH habe ich keine SSH2-Unterstützung mehr.
- 2.9 - sftp/scp kann keine Verbindung aufbauen, obwohl ssh funktioniert.
- 2.10 - Werdet ihr [foo] zu scp hinzufügen?
- 2.11 - Wie verwende ich Portweiterleitung?
- 2.12 - Meine ssh-Verbindung friert ein oder steigt nach N Minuten Inaktivität aus.
- 2.13 - Wie rufe ich scp auf, um eine Datei zu kopieren, die einen Doppelpunkt beinhaltet?
- 2.14 - Warum teilt OpenSSH seine Version den Clients mit?
3.0 - Fragen zum portablen OpenSSH
- 3.1 - Unechte PAM-Authentifikationsmeldungen in den Logdateien.
- 3.2 - Leere Passwörter sind bei der PAM-Authentifikation nicht erlaubt.
- 3.3 - ssh(1) benötigt sehr lange zum Verbinden oder zum Einloggen
- 3.4 - »Can't locate module net-pf-10«-Meldungen im Log unter Linux.
- 3.5 - Passwortauthentifikation funktioniert nicht (z. B. unter Slackware 7.0 oder Red Hat 6.x)
- 3.6 - Configure oder sshd(8) beschweren sich über fehlende RSA-Unterstützung
- 3.7 - »scp: command not found«-Fehler
- 3.8 - Kann die Passphrase nicht lesen
- 3.9 - configure fehlt oder make versagt
- 3.10 - Hängt beim Verlassen von ssh
- 3.11 - Wieso hängt ssh beim Beenden?
- 3.12 - Ich habe ein Upgrade auf OpenSSH 3.1 durchgeführt und dann ging die X11-Weiterleitung nicht mehr.
- 3.13 - Ich habe ein Upgrade auf OpenSSH 3.8 durchgeführt und dann gingen einige X11-Programme nicht mehr.
- 3.14 - Ich habe meinen öffentlichen Schlüssel in authorized_keys kopiert, aber Publickey-Authentifizierung funktioniert immer noch nicht.
- 3.15 - OpenSSH-Versionen und das Verhalten von PAM.
- 3.16 - Warum zeigen weder »w« noch »who« unter AIX 5.x Benutzer an, die über ssh eingeloggt sind?
Die OpenSSH-Suite beinhaltet das ssh(1)-Programm, das rlogin und telnet ersetzt, und scp(1), das rcp(1) und ftp(1) ersetzt. OpenSSH beinhaltet auch sftp(1) und sftp-server(8), die eine einfache Lösung für Dateiübertragungen realisieren. Sie basieren auf dem secsh-filexfer-IETF-Entwurf.
OpenSSH besteht aus mehreren Programmen.
Die neueste Version von OpenSSH ist Teil der aktuellen Ausgabe von OpenBSD, und wird stets zusammen mit der Basisinstallation installiert.
Heutzutage beinhalten die meisten anderen Betriebssysteme eine Version von OpenSSH (oft umetikettiert oder »geheim« gekennzeichnet), sodass die meisten Benutzer es unmittelbar benutzen können. Wie auch immer, manchmal sind die enthaltenen Versionen ziemlich alt, und lassen Merkmale vermissen, die die aktuelle Veröffentlichung von OpenSSH hat, sodass man gerne die aktuelle Version installieren möchte, oder man möchte sie auf einem der wenigen Betriebssysteme installieren, auf denen sie fehlt, und für die der Herausgeber des Betriebssystems keine moderne Version verfügbar macht. Vielleicht möchte man auch OpenSSH auch für eine eingebettete Anwendung nutzen.
Nicht-OpenBSD-Nutzer werden die portable Distribution von einem Spiegelserver in ihrer Nähe herunterladen, und dann kompilieren und installieren wollen.
OpenSSH ist eine Sammlung von Werkzeugen, die dir hilft, deine Netzwerkverbindungen sicherer zu machen. Hier ist eine Liste der Funktionalitäten:
Zurzeit werden fast alle Übertragungen in Computernetzwerken unverschlüsselt durchgeführt. Als Konsequenz kann jeder, der Zugriff auf irgendeine Maschine in diesem Netzwerk hat, alle Verbindungen abhören. Das wird auch von Hackern, neugierigen Administratoren, Arbeitgebern, Kriminellen, Industriespionen und Regierungen so durchgeführt. Einige Netzwerke senden derartig viel elektromagnetische Strahlung ab, dass Daten sogar in großer Entfernung noch aufgefangen werden können.
Wenn du dich einloggst, wird dein Passwort im Klartext übertragen. Daher kann dann jeder Lauscher deinen Account zu jeglicher Tat benutzen. Es gibt weltweit viele Zeugnisse dafür, dass Cracker auf dem Rechner eines Opfers unbemerkt ein Programm gestartet haben, welches ohne Wissen des Anwenders einfach nur das Netzwerk belauscht und Passwörter gesammelt hat. Programme, die das tun, gibt es im Internet oder können von einem kompetenten Programmierer innerhalb weniger Stunden selbst geschrieben werden.
Firmen haben Geschäftsgeheimnisse, Patentanträge in Vorbereitung, Preisinformationen, Informationen über Vertragspartner, Kundendaten, Personendaten, Finanzdaten etc. Zurzeit kann jeder mit Zugriff auf das Netzwerk (jede Maschine im Netzwerk) alles belauschen, was im Netzwerk vor sich geht, und das noch ohne die normalen Zugriffsbeschränkungen.
Vielen Firmen ist nicht bewusst, dass Informationen so einfach aus ihrem Netzwerk gesammelt werden können. Sie vertrauen darin, dass ihre Daten sicher sind, da niemand wissen kann, dass dort vertrauliche Informationen kursieren, oder auch, weil dort so viele andere Daten übertragen werden. Dies ist keine sichere Einstellung.
Obwohl OpenSSH unter OpenBSD entwickelt wird, gibt es eine breite Palette an Portierungen auf andere Betriebssysteme. Die portable Version von OpenSSH wird von Damien Miller geleitet. Einen schnellen Überblick über die portable Version von OpenSSH gibt dir http://www.openssh.com/portable.html. Betriebssysteme, die zurzeit unterstützt werden, sind:
Eine Liste der Anbieter, die OpenSSH in ihre Distributionen einbinden, befindet sich auf der OpenSSH-Benutzerseite.
Die OpenSSH Entwickler haben sehr hart versucht, OpenSSH frei von Patent- oder Copyrightproblemen zu halten. Dazu mussten einige Optionen aus OpenSSH entfernt werden. Nämlich die Unterstützung für patentierte Algorithmen.
OpenSSH unterstützt keinerlei patentierte Transportalgorithmen. Im SSH1-Modus sind nur 3DES und Blowfish möglich. Im SSH2-Modus können nur 3DES, Blowfish, CAST128, Arcfour und AES ausgewählt werden. Der patentierte IDEA-Algorithmus wird nicht unterstützt.
OpenSSH bietet Unterstützung für sowohl das SSH1- als auch das SSH2-Protokoll.
Seit das RSA-Patent ausgelaufen ist, gibt es keinerlei Beschränkungen mehr für Software, die den RSA-Algorithmus benutzen, inklusive OpenBSD.
Es gibt mehrere Stellen, die du um Hilfe bitten kannst. Zusätzlich zur OpenSSH-Webseite gibt es mehrere Mailinglisten, in denen du dein Glück versuchen kannst. Bevor du das tust, durchsuche bitte alle Mailinglisten-Archive um zu sehen, ob deine Frage vielleicht schon beantwortet wurde. Die OpenSSH-Mailingliste wurde archiviert und steht in durchsuchbarer Form unter marc.info. zur Verfügung.
Mehr Informationen über das Abonnieren von OpenSSH-bezogenen Mailinglisten gibt es unter OpenSSH-Mailinglisten.
Informationen zum Senden von Fehlermeldungen können auf der OpenSSH ,Fehler melden'-Seite gefunden werden.
Wenn du eine Sicherheitslücke melden möchtest, kontaktiere bitte die private Liste »openssh@openssh.com«.
Der OpenSSH-Client benutzt die unteren Ports für rhosts- und rhosts-rsa-Authentifikation, da der Server dem Benutzernamen vertrauen muss, den der Client liefert. Um das zu umgehen, kannst du das Beispiel weiter unten in deine ssh_config- oder ~/.ssh/config-Datei kopieren.
UsePrivilegedPort no
Oder du kannst diese Option auf der Kommandozeile angeben, indem du die Option -o des ssh(1)-Kommandos benutzt.
$ ssh -o "UsePrivilegedPort no" host.com
In Verbindung mit der vorhergehenden Frage (2.1) braucht OpenSSH root-Autorität, um sich an die unteren und privilegierten Ports binden zu können, um dann eine rhosts-Authentifikation durchzuführen. Genauso notwendig ist dieser privilegierte Port für rhosts-rsa-Authentifikation zu älteren SSH-Versionen.
Zusätzlich gilt sowohl für rhosts-rsa-Authentifikation
(in Protokollversion 1) als auch für hostbasierte Authentifikation
(in Protokollversion 2), dass der ssh-Client Zugang zum
,private host key' braucht, um die Clientmaschine am Server
anzumelden.
OpenSSH-Versionen vor 3.3 benötigten ein gesetztes setuid-Bit für die
Binärdatei von ssh, um das zu erreichen, aber du kannst das Bit
löschen, wenn du diese Authentifizierungsmethoden nicht
benutzen willst.
Beginnend mit OpenSSH 3.3 ist ssh standardmäßig nicht
setuid. ssh-keysign
wird benutzt, um die privaten Hostschlüssel auszulesen, und ssh benutzt
standardmäßig keine privilegierten Quellports. Wenn du
doch einen benutzen willst, musst du das setuid-Bit von ssh
per Hand setzen.
SSH 2.3 und frühere Versionen haben einen Fehler in ihrer HMAC-Implementation. Ihr Code hat nicht die komplette Ausgabe des Datenblocks von der Auswahl bereitgestellt, sondern stattdessen eben nur 128 Bits. Bei längeren Anfragen konnte dann SSH 2.3 eben nicht mit OpenSSH zusammenarbeiten.
OpenSSH 2.2.0 erkennt, dass SSH 2.3 diesen Fehler hat. In zukünftigen Versionen von SSH wird dieser Fehler behoben sein. Alternativ kannst du das folgende in deine /etc/sshd2_config von SSH 2.3 einfügen.
Mac hmac-md5
Probleme bei der Zusammenarbeit treten auf, weil ältere Versionen von OpenSSH noch keine Unterstützung für ,session rekeying' hatten. Das kommerzielle SSH 2.3 versucht diese Funktionalität abzulehnen, und es kann zum Einfrieren der Verbindung kommen, oder die Fehlermeldung ,Dispatch protocol error: type 20 ' kann zu lesen sein. Das Problem wird entweder durch ein Upgrade auf eine aktuelle OpenSSH-Version oder Abschalten des ,rekeying' durch Hinzufügen des folgenden in die ssh2_config oder sshd2_config vom kommerziellen SSH 2.3 behoben.
RekeyIntervalSeconds 0
Die alten Versionen von SSH haben einen patentierten Algorithmus benutzt, um ihren /etc/ssh/ssh_host_key zu verschlüsseln. Das Problem manifestiert sich darin, dass der sshd(8) seinen Hostschlüssel nicht lesen kann. Um das Problem zu lösen, benutze das Kommando weiter unten, um deinen ssh_host_key zu 3DES zu konvertieren. HINWEIS: Benutze das ssh-keygen(1)-Programm von dem kommerziellen SSH-Produkt und *NICHT* OpenSSH für das Beispiel weiter unten.
# ssh-keygen -u -f /etc/ssh/ssh_host_key
Das ssh-keygen(1) des kommerziellen SSH-Programms hat einen Fehler beinhaltet, der dazu führte, dass es von Zeit zu Zeit ,Pubkey'-Authentifikationsschlüssel (RSA oder DSA) generiert hat, deren ,Most Significant'-Bit (MSB) nicht gesetzt war. Solche Schlüssel wurden zwar als ,mit voller Länge' angekündigt, waren aber die Hälfte der Zeit über kleiner als angekündigt.
OpenSSH wird Warnungen ausgeben, wenn es solchen Schlüsseln begegnet. Um diese Warnungen loszuwerden, passe deine known_hosts-Datei an und ersetze die falsche Schlüssellänge (normalerweise ,1024') mit der richtigen (normalerweise ,1023').
Prüfe deine ssh_config und sshd_config. Die voreingestellten Konfigurationsdateien schalten den Authentifikationsagenten und X11-Weiterleitung ab. Füge die Zeilen unten in die sshd_config ein, um sie zu aktivieren:
X11Forwarding yes
und füge die folgenden Zeilen in die ssh_config ein:
ForwardAgent yes
ForwardX11 yes
X11-Weiterleitung setzt eine funktionierende xauth(1)-Binary voraus. Unter OpenBSD befindet sie sich im xbase-Dateiset, was auf anderen Plattformen jedoch nicht der Fall sein muss. Für die portable OpenSSH muss xauth entweder während dem configure-Aufruf gefunden werden oder später mittels XauthLocation in der sshd_config(5) und ssh_config(5) angegeben werden.
Hinweis zur Agenten-Interoperabilität: Es gibt zwei unterschiedliche und inkompatible Agentweiterleitung-Mechanismen innerhalb des SSH2-Protokolls. OpenSSH hat immer eine Erweiterung der originalen SSH1-Agent-Anfragen genutzt, jedoch verwenden einige kommerzielle Produkte ein anderes, nicht freies Agentweiterleitungsprotokoll. Dies bedeutet, dass Agentweiterleitung nicht zwischen OpenSSH und diesen kommerziellen Produkten genutzt werden kann.
HINWEIS: Benutzer von Linux Mandrake 7.2: Mandrake modifiziert die XAUTHORITY-Umgebungsvariable in /etc/skel/.bashrc und damit das Heimatverzeichnis jedes Bash-Benutzers. Diese Variable wird von OpenSSH gesetzt und daher muss für die oben genannten Optionen die folgende Zeile auskommentiert werden:
# export XAUTHORITY=$HOME/.Xauthority
Die Dateien sshd_config oder ssh_config können von Version zu Version verändert werden. Du solltest immer nach solchen Änderungen Ausschau halten, wenn du auf eine neue Version von OpenSSH upgradest. Nach OpenSSH 2.3.0 musst du das folgende in deine sshd_config einfügen:
HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key
sftp und/oder scp können beim Aufbauen der Verbindung Probleme haben, wenn du eine Shellinitialisierung (.profile, .bashrc, .chsrc etc.) hast, die Ausgaben für nicht interaktive Sitzungen produziert. Diese Ausgabe verwirrt den sftp/scp-Client. Hiermit kannst du prüfen, ob deine Shell das tut:
ssh yourhost /usr/bin/true
Wenn das Kommando oben irgendeine Art von Ausgabe produziert, musst du deine Shellinitialisierung modifizieren.
Kurze Antwort: Nein.
Lange Antwort: scp ist nicht standardisiert. Die Beschreibung, die einer Spezifikation am nächsten kommt, ist: »Was rcp macht«. Da das selbe Kommando auf beiden Seiten einer Verbindung benutzt wird, bedeutet das Hinzufügen von Funktionalitäten oder Optionen das Risiko von Inkompatibilitäten mit anderen Implementationen.
Neue Funktionalitäten sind eher in sftp wahrscheinlich, da das Protokoll standardisiert (na ja, ein , draft standard') und erweiterbar ist und Client sowie Server voneinander getrennt sind.
Wenn sshd(8) auf dem Server auf der Gegenseite läuft, kann es möglich sein, bestimmte Dienste durch ssh zu ,tunneln'. Das kann wünschenswert sein, um beispielsweise POP- und SMTP-Verbindungen zu verschlüsseln, selbst wenn die Software keine eigene Unterstützung für verschlüsselte Verbindungen hat. Das Tunneln verwendet Portweiterleitung, um eine Verbindung zwischen dem Client und dem Server herzustellen. Die Client-Software muss hierfür in der Lage sein, auf einen nicht standardisierten Port verbinden zu können.
Die Idee dahinter ist, dass der Client sich mit dem entfernten System über ssh verbindet und angibt, welcher Port auf der Maschine des Clients dazu verwendet werden soll, Verbindungen zum Server weiterzuleiten. Danach ist es möglich, die Dienste, die verschlüsselt werden sollen (z. B. fetchmail, irc), auf dem Client mit der Angabe des gleichen Ports, der an ssh übergeben wurde, zu starten, und die Verbindung wird durch ssh getunnelt. Standardmäßig wird das System, das das Weiterleiten durchführt, nur eigene Verbindungen zulassen.
Die wichtigsten Optionen zum Tunneln sind die Optionen -L und -R, welche dem Benutzer das Portweiterleiten erlauben, die Option -D, welche das dynamische Portweiterleiten erlaubt, die Option -g, die es anderen Hosts erlaubt, Portweiterleitung zu benutzen, und die Option -f, welche ssh zuweist, nach der Authentifizierung im Hintergrund weiterzuarbeiten. Lies die ssh(1)-Handbuchseite, um weitere Details zu erfahren.
Dies ist ein Beispiel für eine getunnelte IRC-Sitzung von der Clientmaschine ,127.0.0.1' (localhost) zum entfernten Server ,server.example.com':
ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
Dies tunnelt eine Verbindung zum IRC-Server server.example.com und tritt mit dem Nick ,pinky' dem Channel ,#users' bei. Der lokale Port, der in diesem Beispiel verwendet wurde, ist 1234. Es tut nichts zur Sache, welcher Port benutzt wird, so lange er größer ist als 1023 (bedenke, nur root kann Sockets auf privilegierten Ports öffnen) und keine Störung mit bereits verwendeten Ports auftritt. Die Verbindung wird zum Port 6667 auf dem entfernten Server weitergeleitet, da das der Standardport für IRC-Dienste ist.
Der Remote-Befehl ,sleep 10' wurde angegeben, um dem Dienst, der getunnelt werden soll, eine gewisse Zeit (10 Sekunden in diesem Beispiel) zu geben, um zu starten. Wenn in der angegebenen Zeit keine Verbindung aufgebaut wurde, wird ssh sich beenden. Falls mehr Zeit benötigt wird, kann der sleep(1)-Wert entsprechend erhöht werden oder alternativ könnte das oben aufgelistete Beispiel als eine Funktion in die Benutzershell eingefügt werden. Siehe ksh(1) und csh(1) für weitere Details über benutzerdefinierte Funktionen.
ssh besitzt des Weiteren die Option -N, welche praktisch für das Portweiterleiten ist: Wenn -N übergeben wurde, ist es nicht notwendig, einen Remote-Befehl (»sleep 10« in dem Beispiel oben) anzugeben. Allerdings führt die Benutzung dieser Option dazu, dass ssh für immer wartet (anstatt zu beenden, wenn ein Remote-Befehl ausgeführt wurde), sodass der Benutzer darauf achten muss, den Prozess hinterher manuell mit kill(1) zu beenden.
Das ist üblicherweise das Resultat eines Paketfilters oder einem NAT-Gerät, das die TCP-Verbindung wegen Inaktivität auslaufen lässt. Du kannst ClientAliveInterval in der sshd_config des Servers aktivieren oder ServerAliveInterval in der ssh_config des Clients ermöglichen (die letzte Option ist in OpenSSH 3.8 und neuer verfügbar).
Das Aktivieren einer der beiden Optionen und das Setzen des Intervalls, das kürzer als die benötigte Zeit ist, um die Verbindung auslaufen zu lassen, sorgen dafür, dass die Verbindung in der Verbindungstabelle des Gerätes ,frisch' gehalten wird.
$ scp ./source:file sshserver:
OpenSSH, wie die meisten SSH-Implementationen, teilt seinen Namen und seine Version den Clients mit, wenn sie eine Verbindung aufbauen, z. B.
SSH-2.0-OpenSSH_3.9
Diese Information wird von den Clients und Servern verwendet, um Protokollkompatibilitätskniffe zu aktiveren, die veränderte, fehlerhafte oder fehlende Funktionen in der Implementation, mit der sie reden, zu umgehen. Dieser Protokollfunktionstest ist weiterhin nötig, weil noch immer Versionen mit Inkompatibilitäten im Umlauf sind.
Die portable Version von OpenSSH generiert unechte misslungene Authentifikationsmeldungen bei jedem Login, etwa wie:
"authentication failure; (uid=0) -> root for sshd service"
Diese werden erzeugt, weil OpenSSH zuerst versucht herauszufinden, ob der Anwender eine Authentifikation zum Login benötigt (z. B. leeres Passwort). Dummerweise logt PAM alle Authentifikationversuche, inklusive diesem hier.
Wenn es dich zu sehr stört, setze »PermitEmptyPasswords no« in sshd_config. Das wird die Meldung stilllegen, allerdings auf Kosten dessen, dass es nicht mehr möglich ist, sich in Accounts mit leeren Passwörtern einzuloggen. Das ist im übrigen bereits der Standard, wenn du die mitgelieferte sshd_config-Datei benutzt.
Um leere Passwörter in einer OpenSSH-Version zu erlauben, die mit PAM erzeugt wurde, musst du das ,nullok'-Flag an das Ende des Password-Checking-Moduls in der /etc/pam.d/sshd-Datei setzen. Zum Beispiel:
auth required/lib/security/pam_unix.so shadow nodelay nullok
Das muss zusätzlich zum Setzen von »PermitEmptyPasswords yes« in der sshd_config-Datei geschehen.
Es gibt einen Fallstrick beim Benutzen leerer Passwörter mit PAM-Authentifikation: PAM wird jegliches Passwort erlauben, wenn ein Account mit einem leeren Passwort authentifiziert wird. Das macht den Check, den sshd(8) benutzt, um zu prüfen, ob der Account ein Passwort gesetzt hat, wirkungslos und umgeht ebenso die Richtlinie, die von PermitEmptyPasswords gesetzt wurde. Aus diesem Grund raten wir davon ab, die nullok-Direktive in deiner PAM-Konfigurationsdatei zu setzen, es sei denn, du willst leere Passwörter explizit erlauben.
Große Verzögerungen (mehr als 10 Sekunden) werden normalerweise durch Probleme mit der Namensauflösung verursacht:
nslookup-Befehl auf dem
Client und dem Server verwenden, um den Namen und die IP-Adresse der Gegenseite
auflösen zu lassen. Lass zusätzlich den Namen auf dem Server
auflösen, den der Client beim Auflösen der IP-Adresse des Servers
zurückgegeben hat. Du kannst die meisten Lookups serverseitig durch
das Hinzufügen von UseDNS no in sshd_config
deaktivieren.Verzögerungen unter 10 Sekunden können andere Ursachen haben.
ssh, der
dazu führte, dass es größere moduli anforderte als erwartet
(was dann, in Kombination mit dem oben genannten Problem, in erheblichen
Geschwindigkeitseinbußen endete).
Ein Upgrade des Clients auf Version 3.8 oder höher wird das Problem
beheben.ssh-rand-helper zum Generieren vom Entropy
aufgerufen wird, hängt. Das kann ermittelt werden, indem es im Debug-Modus
ausgeführt wird:
Alle beachtlichen Verzögerungen sollten untersucht und behoben, oder aber die entsprechenden Befehle aus ssh_prng_cmds entfernt werden.
/usr/local/libexec/ssh-rand-helper -vvv
time ssh localhost
true mit einem 1024-Bit-RSA-Schlüssel auf einem ansonsten
ungenutzten System. OpenSSH und OpenSSL wurden mit gcc 3.3.x compiliert.
| CPU | Zeit (SSHv1)[1] | Zeit (SSHv2) |
|---|---|---|
| 170MHz SPARC/sun4m | 0.74 Sek | 1.25 Sek |
| 236MHz HPPA/8200[2] | 0.44 Sek | 0.79 Sek |
| 375MHz PowerPC/604e | 0.38 Sek | 0.51 Sek |
| 933MHz VIA Ezra | 0.34 Sek | 0.44 Sek |
| 2.1GHz Athlon 2600+ | 0.14 Sek | 0.22 Sek |
Der Linux-Kernel sucht (via modprobe) nach der Protokollfamilie 10 (IPv6). Lade entweder das passende Kernelmodul, gib den korrekten Alias in /etc/modules.conf an oder schalte IPv6 in /etc/modules.conf ab.
Aus irgendeinem blödsinnigen Grund kann /etc/modules.conf auch /etc/conf.modules heißen.
Falls das Passwort das korrekte Passwort ist, und der Login weiterhin verwehrt bleibt, liegt die Ursache normalerweise darin, dass das System zwar mit MD5-Typ-Passwörtern arbeitet, aber die crypt(3)-Funktion, die von sshd verwendet wird, diese nicht verstehen kann.
Betroffene Passwörter haben eine Passwortzeichenkette in /etc/passwd oder /etc/shadow, die mit $1$ beginnt. Falls die Passwortauthentifikation für neue Accounts oder Accounts mit Passwörtern, die kürzlich aktualisiert wurden, fehlschlägt, aber mit alten Accounts funktioniert, dann ist dies wahrscheinlich das Problem.
Der Grund hierfür ist, dass einige Versionen von OpenSSL eine crypt(3)-Funktion haben, die keine MD5-Passwörter versteht, und die ,link'-Reihenfolge von sshd führt dazu, dass OpenSSLs crypt(3) und nicht das vom System genutzt wird. OpenSSHs configure versucht dies zu korrigieren aber ist damit nicht immer erfolgreich.
Es gibt einige mögliche Lösungen:
Aktiviere sshds eingebaute Unterstützung für MD5-Passwörter während der Erzeugungsphase.
Dies ist sogar dann sicher, wenn du beide Verschlüsselungstypen verwendest, da sshd den korrekten Algorithmus für jeden Account automatisch auswählt.
./configure --with-md5-passwords [Optionen]
Wenn dein System eine separate libcrypt-Bibliothek hat (z. B. Slackware 7), dann kannst du manuell -lcrypt zur LIBS-Liste einfügen, sodass es statt OpenSSLs verwendet wird:
LIBS=-lcrypt ./configure [Optionen]
Wenn deine Plattform PAM unterstützt, könntest du sshd so konfigurieren, dass es dieses verwendet (siehe Sektion 3.15). Das bedeutet, dass sshd Passwörter nicht selbst überprüfen wird, sondern es an die konfigurierten PAM-Module übergibt.
Stelle sicher, dass deine OpenSSL-Bibliotheken mit eingebauter RSA- oder DSA-Unterstützung erzeugt wurden, entweder intern oder durch RSAref.
scp(1) muss sich im Standard-PATH sowohl auf dem Client als auch auf dem Server befinden. Möglicherweise musst du die Option --with-default-path angeben, um einen angepassten Pfad für die Suche auf dem Server angeben zu können. Diese Option ersetzt den Standardpfad, sodass du sowohl alle bisherigen Verzeichnisse in deinem Pfad angeben musst als auch das Verzeichnis, in dem scp installiert ist. Zum Beispiel:
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
Bedenke, dass die Konfiguration des Administrators des Servers Vorrang gegenüber der Option --with-default-path hat. Das beinhaltet das Rücksetzen von PATH in /etc/profile, PATH in /etc/environment unter AIX oder (für 3.7p1 und höher) das Setzen von PATH oder SUPATH in /etc/default/login unter Solaris oder Reliant Unix.
Einige Betriebssysteme setzen /dev/tty mit falschen Modi, was zum Fehler beim Lesen von Passwörtern mit folgender Fehlermeldung führt:
You have no controlling tty. Cannot read passphrase.
Die Lösung hierzu ist, die Berechtigungen von /dev/tty auf 0666 zu setzen und dann das ganze deinem Betriebssystem-Hersteller als Fehler zu melden.
Wenn es keine configure-Datei in deiner tar.gz-Datei gibt, die du heruntergeladen hast, oder make mit einem ,missing seperator'-Fehler versagt, hast du vermutlich die OpenBSD-Distribution heruntergeladen und versuchst, sie auf einer anderen Plattform zu kompilieren. Bitte verwende die portable Version.
OpenSSH kann beim Beenden hängen bleiben. Das kann passieren, wenn es einen aktiven Hintergrundprozess gibt. Linux und HP-UX sind hierfür bekannt. Das Problem kann hiermit verifiziert werden:
Versuche stattdessen das hier zu benutzen:
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
Ein Umgehen des Problems für bash-Anwender ist mittels eines Einfügens von "shopt -s huponexit" in entweder /etc/bashrc oder ~/.bashrc möglich. Ansonsten konsultiere die Handbuchseite deiner Shell um eine Option zu finden, mit der man aktiven Jobs ein HUP-Signal senden kann, wenn man sie verlässt. Siehe bug #52 für andere Möglichkeiten, das Problem umgehen zu können.
Beim Ausführen von
muss ssh hängen bleiben, da es zu warten hat
$ ssh host command
command keine weiteren
Eingaben benötigt.
command keine weitere
Ausgaben zurückgibt.
command beendet ist, da der sshd den Exitstatus
von command an ssh weitergeben muss.
Im Allgemeinen sollten X11-Clients, die X11 R6 benutzen, mit dieser Einstellung funktionieren. Einige Hersteller, einschließlich HP, setzen X11-Clients mit R6- und R5-Bibliotheken ein, sodass einige Clients funktionieren und andere nicht. Das gilt z. B. für HP-UX 11.X.
Wie in den 3.8 release notes dokumentiert
worden ist, wird ssh standardmäßig ,untrusted X11
cookies' benutzen. Das vorherige Verhalten kann durch das Setzen von
ForwardX11Trusted yes in sshd_config wiederhergestellt werden.
Mögliche Symptome beinhalten:
BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)
Typischerweise wird das durch die Dateirechte von $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys hervorgerufen, die mehr erlauben als sshd standardmäßig zulässt.
In diesem Falle kann es behoben werden, indem Folgendes auf dem Server ausgeführt wird.
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
Falls das aus irgendeinem Grund nicht möglich sein sollte, besteht die Alternative darin, StrictModes no in sshd_config zu setzen, jedoch wird das nicht empfohlen.
Um PAM auf irgendeine Weise nutzen zu können, muss diese Option während der Erzeugungsphase gesetzt sein. Das Laufzeit-Verhalten, wenn PAM erzeugt wurde, variiert mit der Version des portablen OpenSSH, und spätere Versionen müssen es ebenfalls mit dem Setzen von UsePAM auf yes in sshd_config aktivieren.
./configure --with-pam [Optionen]
Das Verhalten der relevanten Authentifikations-Optionen, wenn PAM-Unterstützung integriert wurde, ist in der folgenden Tabelle zusammengefasst.
| Version | UsePAM | PasswordAuthentication | ChallengeResponseAuthentication |
|---|---|---|---|
| <=3.6.1p2 | Nicht nutzbar | Verwendet PAM | Verwendet PAM, wenn PAMAuthenticationViaKbdInt aktiv ist |
| 3.7p1 - 3.7.1p1 | Standard ist yes | Verwendet nicht PAM | Verwendet PAM, wenn UsePAM aktiv ist |
| 3.7.1p2 - 3.8.1p1 | Standard ist no | Verwendet nicht PAM [1] | Verwendet PAM, wenn UsePAM aktiv ist |
| 3.9p1 | Standard ist no | Verwendet PAM, wenn UsePAM aktiv ist | Verwendet PAM, wenn UsePAM aktiv ist |
[1] Einige Verkäufer, insbesondere Redhat/Fedora, haben die Passwortauthentifikation von 3.9p1 auf ihre 3.8x-basierten Pakete zurückportiert. Wenn du ein Paket nutzt, das von einem Verkäufer bereitgestellt wurde, konsultiere bitte dessen Dokumentation.
,OpenSSH Portable's PAM-Interface hat immer noch Probleme mit ein paar Modulen, jedoch hoffen wir, dass wir diese Anzahl in Zukunft verringern können. Zum Zeitpunkt der Veröffentlichung von 3.9p1 sind folgende Probleme bekannt:
www@openbsd.org