Hallo Werner,
debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Trying private key: /home/caxwf/.ssh/id_rsa debug3: no such identity: /home/caxwf/.ssh/id_rsa
.. lässt drauf schliessen das dein SSHd vielleicht keine Keys angelegt hat? Sind deine KeyFiles vorhanden?
ls -la /home/caxwf/.ssh/id_dsa ls -la /home/caxwf/.ssh/id_rsa
Ich habe nur den DSA Key erstellt, weil wir nur diesen Benutzen. Muss mal in der ssh config vom Notebook nachschauen warum das unbedingt (?) einen RSA haben will.
Hmm. Nichts gefunden. Ich habe die SuSE Standards an den SSH Configs nicht geaendert. Nur in ssh_config habe ich inzwischen
ForwardAgent yes ForwardX11 yes
und
PreferredAuthentications hostbased,publickey,keyboard-interactive,password
drin. Das habe ich jedoch erst waehrend der rumprobiererei mit SSH gemacht. Warum funktionierts dann mit dem Notebook nicht, mit dem Linux-PC, auf dem auch 9.3 drauf ist schon ?
Weitere Ideen ?
Ein weiterer Versuch wäre auf der Maschine VON der du dich aus einloggen moechtest (also dein Linux Desktop oder SUN) die datei /home/<benutzer>/.ssh/known_hosts mal zu loeschen. Das ist nicht weiter schlimm, da du dann beim verbinden gefragt ob der Fingerprint gespeichert werden soll. Diese mit 'yes' beantworten. Versuchst du dich mit Passwort einzuloggen, oder mit ner KeyFile? Gruß Kai Kai Möller Service Center Information Technology ________________________________________________________________ ExperTeach GmbH Waldstr. 94 63128 Dietzenbach Telefon: +49 6074 4868-237 Telefax: +49 6074 4868-109 mailto:kai.moeller@experteach.de http://www.experteach.de ________________________________________________________________ ExperTeach Summer Team Package - der dritte Platz ist kostenfrei! Alle Informationen zu dieser Aktion: http://www.experteach.de/classroomtraining/aktion_000222E2.html ________________________________________________________________
Kai Moeller schrieb:
Muss mal in der ssh config vom Notebook nachschauen warum das unbedingt
Ich habe nur den DSA Key erstellt, weil wir nur diesen Benutzen.
(?)
einen RSA haben will.
Hmm. Nichts gefunden. Ich habe die SuSE Standards an den SSH Config
Schau mal in /etc/ssh/ssh_config ob die Zeile IdentityFile ~/.shh/id_dsa aktiviert ist
mfg Max
Hallo Max, alle, Am Freitag, 15. Juli 2005 14:30 schrieb MAX:
Kai Moeller schrieb:
Muss mal in der ssh config vom Notebook nachschauen warum das unbedingt
Ich habe nur den DSA Key erstellt, weil wir nur diesen Benutzen.
(?)
einen RSA haben will.
Hmm. Nichts gefunden. Ich habe die SuSE Standards an den SSH Config
Schau mal in /etc/ssh/ssh_config ob die Zeile IdentityFile ~/.shh/id_dsa aktiviert ist
Ich habe die Ursache: Es liegt am QIP Server im zusammenhang mit DHCP. Laut einem Kollegen, funktioniert bei Linux in einigen Faellen die Hostnamenuebermittlung nicht so wie es soll. Der PC bekommt zwar vom DHCP Server seine IP, aber den Hostnamen, den der PC zurueckgibt, kommt beim QIP Server nicht an. (oder so) Und dann weigert sich die SSH eine Verbindung aufzubauen. Von anderen PCs weiss ich, dass sie nur lange genug am LAN sein muessen. Irgendwann kriegts der QIP Server schon mit. Mein Notebook ist aber erst seit heute Morgen am LAN und das ist anscheinend nicht lange genug. Damit ueber Nacht nicht ploetzlich 2 Notebooks dastehen, raeume ich ihn dann Abends wieder weg. Tja.... Gruss und schönes Wochenende, Werner
Hi, On Fri, 15 Jul 2005, Werner Franke wrote:
Am Freitag, 15. Juli 2005 14:30 schrieb MAX:
Kai Moeller schrieb:
Muss mal in der ssh config vom Notebook nachschauen warum das unbedingt
Ich habe nur den DSA Key erstellt, weil wir nur diesen Benutzen.
(?)
einen RSA haben will.
Hmm. Nichts gefunden. Ich habe die SuSE Standards an den SSH Config
Schau mal in /etc/ssh/ssh_config ob die Zeile IdentityFile ~/.shh/id_dsa aktiviert ist
Ich habe die Ursache:
Es liegt am QIP Server im zusammenhang mit DHCP.
Laut einem Kollegen, funktioniert bei Linux in einigen Faellen die Hostnamenuebermittlung nicht so wie es soll.
Der PC bekommt zwar vom DHCP Server seine IP, aber den Hostnamen, den der PC zurueckgibt, kommt beim QIP Server nicht an. (oder so)
Und dann weigert sich die SSH eine Verbindung aufzubauen.
hä? [ ] du hast einen windows admin gefragt? ;) Das Oben geschilderte Problem kann IMHO folgende Ursachen haben: [ ] falsche Konfiguration in sshd_config die irgendwelche seltsamen Keykombinationen anfordert. [ ] Interaktive Logins deaktiviert und keine (passenden) Schlüssel Du kannst ganz einfach testen, ob der Admin recht hat oder nicht (eher nicht). Gib statt dem hostname die IP deines Rechners an. Damit ist DNS und DHCP (fast komplett) aus dem Spiel. Wenn du damit den gleichen Fehler bekommst benutze eine "known good" Konfigurationsdatei und starte den sshdäemon neu. Known good ist z.B. eine Konfiguration one explizit angegebenen Optionen. (Wenn SuSE da nichts verbockt hat) Greetings Daniel -- Quis custodiet ipsos custodes?
Hi Daniel, Am Samstag, 16. Juli 2005 09:34 schrieb Daniel Lord:
Hi,
On Fri, 15 Jul 2005, Werner Franke wrote:
[...]
Ich habe die Ursache:
Es liegt am QIP Server im zusammenhang mit DHCP.
Laut einem Kollegen, funktioniert bei Linux in einigen Faellen die Hostnamenuebermittlung nicht so wie es soll.
Der PC bekommt zwar vom DHCP Server seine IP, aber den Hostnamen, den der PC zurueckgibt, kommt beim QIP Server nicht an. (oder so)
Und dann weigert sich die SSH eine Verbindung aufzubauen.
hä? [ ] du hast einen windows admin gefragt? ;)
Nein, einen UNIX/Linux Spezialisten (unser IT-Support). Ihm war dieser Effekt mit der SSH gleich bekannt. Laut seiner Aussage ist das ein Ihm bekanntes Problem nur mit Linux. Windows hat keine Probleme. Der DHCP- und QIP Server laeuft uebrigends auf einer SUN. Eventuell ist's auch eine Einstellungssache des QIP Server's. Momentan besteht aber nicht die dringende Notwendigkeit an der QIP-Baustelle weiter zu forschen, weil es noch zu wenig DHCP-Linux-Kisten sind. Die meissten habe eine feste IP.
Das Oben geschilderte Problem kann IMHO folgende Ursachen haben: [ ] falsche Konfiguration in sshd_config die irgendwelche seltsamen Keykombinationen anfordert. [ ] Interaktive Logins deaktiviert und keine (passenden) Schlüssel
Du kannst ganz einfach testen, ob der Admin recht hat oder nicht (eher nicht). Gib statt dem hostname die IP deines Rechners an. Damit ist DNS und DHCP (fast komplett) aus dem Spiel.
Ich habe nie den Hostnamen angegeben, sondern in diesem Fall ausschliesslich die IP Adresse, da der PC ueber den Hostnamen ja nicht erreichbar war. Momentan kann ich's leider nicht mehr testen, weil ich mein Notebook wieder zu Hause habe. Aber ich werde demnaechst einen PC mit RadHat installieren und da werde ich's nochmal testen.
Wenn du damit den gleichen Fehler bekommst benutze eine "known good" Konfigurationsdatei und starte den sshdäemon neu. Known good ist z.B. eine Konfiguration one explizit angegebenen Optionen. (Wenn SuSE da nichts verbockt hat)
Gruss Werner
participants (4)
-
Daniel Lord -
Kai Moeller -
MAX -
Werner Franke