SSH - Login klappt, dann keine Eingabe mehr möglich

[anawak12]

Hast Du es mal mit Password-Authentication statt Pub-Key probiert,
nur um sicherzustellen, das ein Connect prinzipiell funktioniert?

Leider funktioniert der Login über Passwort ebenfalls nicht. Zwischenzeitlich habe ich versucht mich auf anderen Servern über SSH durch Passwort und Key anzumelden - das gleiche Problem. Darum gehe ich stark davon aus, dass das Problem beim Client liegt. (Dafür spricht auch, dass der Server seit über 2 Jahren läuft und es noch nie Probleme mit dem Login gab und bei anderen Clients auch weiterhin nicht gibt)

Wenn ja, liegt das Problem vielleicht eher Server-seitig (Was akzeptiert der Server, dsa, rsa?)
Oder die Keys stimmen nicht/sind kaputt.

Der Server akzeptiert momentan sowohl dsa als auch rsa. Die verwendeten Keys funkionieren über andere Systeme reibungslos, darum sollten sie eigentlich ok sein. Zum Test habe ich mir jedoch über ssh-keygen ein neues Paar erstellt (ich komme über andere Clients ja auf den Server drauf), aber auch das hat keine Abhilfe geschafft.

Wie hast Du dein Keys generiert?

ssh-keygen -t rsa

Zeig bitte mal ein "ls -la" von /Users/anawak/.ssh/.
Da sollten nur id_dsa, id_dsa.pub, id_rsa, id_rsa.pub und known_hosts liegen.

drwx------   6    anawak  anawak   204   Nov 11 10:16 .
drwxr-xr-x  34  anawak  anawak  1156   Nov 11 10:16 ..
-rw-r--r--    1    anawak  anawak  6148   Nov 10 23:40 .DS_Store
-rw-------    1    anawak  anawak  1675   Nov 10 23:33 id_rsa
-rw-r--r--    1    anawak  anawak  426     Nov 10 23:33 id_rsa.pub
-rw-r--r--    1    anawak  anawak  237     Nov 10 23:34 known_hosts

Die Zugriffsrechte sollte ebenfalls stimmen. die .DS_Store sollte eigentlich nicht stören, aber ich hatte sie zwischenzeitlich auch gelöscht.

Irgendwo taucht bei Dir PEM auf. Hast Du die Keys im .pem Format? (tut eigentlich nich not)

Nicht, dass ich wüste. Aber reichlich merkwürdig ist es schon.

Ich verbinde mich mit "ssh -pXXX [email protected]" auf meine Server, bis zum
PubKey-Offering sieht ein -vvv ziemlich ähnlich zu deinem Listing aus.

Genau so mache ich es auch. Und der gleiche Befehl mit den gleichen Keys und der gleichen Config läuft über eine parallel auf dem MacBook installierte Suse 10 ebenfalls.

Hast Du an deiner lokalen ssh_config geschraubt? (Ist bei mir komplett auskommentiert.)

Bei mir ist auch alles auskommentiert.

Vielleicht auch ein Netzwerk-Problem? -Schaut arg dünn aus.
Nur so als Denkanstoss.

Netzwerkproblem halte ich fast für ausgeschlossen, leider. Denn wenn ich Putty über CrossOver starte, kann ich mich einloggen. Ebenso über ein parallel installiertes Linux. Alles aus dem gleichen Netzwerk. Danke für den Denkanstöße. Ich hoffe noch immer, dass irgendwer die rettende Idee hat. Ein solch merkwürdiges Problem hatte ich noch nie...

Alles Gute
anawak

 

[Hilarious]

Ja, in /etc/passwd ist für den Account bin/bash eingetragen. Bei dem Server handelt es sich um eine Suse 10, mit Der Login funktioniert ja auch schon seit Monaten von anderen Rechnern aus ohne Probleme.

Auf dem Server läuft OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004


mit folgender sshd_config

Port 22 #durch Firewall von außen über 2222 erreichbar
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTH
LogLevel Info
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 3
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
UsePAM no
AllowTcpForwarding yes
X11Forwarding yes
PermitUserEnvironment yes
MaxStartups 1
Subsystem       sftp    /usr/lib/ssh/sftp-server
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

(alles andere Default)


Alles Gute
anawak

Hmm. Knifflig.

Wenn es von anderen Rechnern aus ging, sind diese im gleichen lokalen Netzwerk gewesen wie Du oder hatten die feste IP-Adressen (Stichwork: ReverseMappingCheck)?

Wie hast Du Dein Schlüsselpaar auf dem Mac generiert? Die Fehlermeldungen sind zwar nicht kritisch, aber Du könntest den öffentlichen Schlüssel mal checken, ob da sich nicht Zeilenumbrüche eingeschlichen haben, die dort nicht hin dürfen.

 

[anawak12]

debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600

Was genau bedeuten die Werte eigentlich?

Alles Gute
anawak

 

[anawak12]

Wenn es von anderen Rechnern aus ging, sind diese im gleichen lokalen Netzwerk gewesen wie Du oder hatten die feste IP-Adressen (Stichwork: ReverseMappingCheck)?

Die anderen Rechner hingen im gleichen Netzwerk und haben über DHCP ebenso wie de Mac ihre IP bezogen. Übrigens funktioniert es sogar über den Mac, wenn ich Putty über CrossOver starte. Wirklich sehr kurios.

Wie hast Du Dein Schlüsselpaar auf dem Mac generiert?

Das erste Schlüsselpaar habe ich über Putty generiert und dann in einen OpenSSH Key konvertiert. (Unter Linux funktioniert der auch ohne Probleme). Um aber irgendwelche Fehler im Key auszuschließen, habe ich mittlerweile über

ssh-keygen -t rsa

ein neues generiert, welches bei anderen Clients ebenfalls keine Probleme bereitet.

Die Fehlermeldungen sind zwar nicht kritisch, aber Du könntest den öffentlichen Schlüssel mal checken, ob da sich nicht Zeilenumbrüche eingeschlichen haben, die dort nicht hin dürfen.

Meinst du in der Datei authorized_keys auf dem Server? Gute Idee. Könnte wirklich sein, weil ich über cat key.pub >> authorized_keys mittlerweile drei Schlüssel angehängt habe. Dumme Frage: Wie checke ich den öffentlichen Schlüssel? was auch merkwürdig ist: ssh bekritelt die ---- BEGIN --- Zeile, obwohl diese von ssh-keygen in den Key geschrieben wurden.

Alles Gute
anawak

 

[Hilarious]

Die Zeilen mit »BEGIN« und »END« kannst Du weglassen. Mein öffentlicher Schlüssel sieht ungefähr so aus:

ssh-rsa AAAAB3[COLOR="Silver"][...][/COLOR]Cwlc= [email protected]

 

[Rastafari]

sshd läuft auf Port 2222

Welcher wilde Affe reitet dich?
Dir ist schon klar, dass für alle Ports >1023 gilt: "DangerZone"?
(Da können beliebige Benutzerprozesse dran lauschen, bei denen <1024 nur root allein...)
Stell das ab. Immediately.

 

[MacMark]

Kleiner Seitenhieb auf Windows: Es hat im Gegensatz zu Unix keine privilegierten Ports. Dort kann jeder beliebige User auch an Ports <= 1023 Dienste anbieten.

 

[anawak12]

Welcher wilde Affe reitet dich?
Dir ist schon klar, dass für alle Ports >1023 gilt: "DangerZone"?
(Da können beliebige Benutzerprozesse dran lauschen, bei denen <1024 nur root allein...)
Stell das ab. Immediately.

Ich verstehe das Problem nicht so ganz. Meinst du, das eine Schadsoftware den SSH-Server abschießen und gegen ein eigenes Programm ersetzen könnte, um interessant Daten wie etwas den PrivateKey abzufangen?

 

[anawak12]

Das Problem konnte gelöst werden. Und zwar so:

touch ~/.ssh/id_rsa

Den Tipp gab mir jemand der der OpenSSH-Mailingliste. Offenbar handelt es sich tatsächlich um einen Bug in der Software, der im Zusammenspiel mit Mac OS X auftritt.

 

[Hilarious]

Das Problem konnte gelöst werden. Und zwar so:

touch ~/.ssh/id_rsa

Den Tipp gab mir jemand der der OpenSSH-Mailingliste. Offenbar handelt es sich tatsächlich um einen Bug in der Software, der im Zusammenspiel mit Mac OS X auftritt.

Wie unbefriedigend Na dann, viel Erfolg & danke für die Auflösung.

 

[anawak12]

Na dann, viel Erfolg & danke für die Auflösung.

Danke für die vielen Ideen und Tipps!

 

[MacMark]

Ich verstehe das Problem nicht so ganz. Meinst du, das eine Schadsoftware den SSH-Server abschießen und gegen ein eigenes Programm ersetzen könnte, um interessant Daten wie etwas den PrivateKey abzufangen?

Bei Unix kann normalerweise an privilegierten Port nur ein Prozeß arbeiten, der von Root dazu ermächtigt wurde, da nur root privilegierte Ports beispielsweise weiterleiten kann. So stellt man sicher, daß nicht irgendein normaler Benutzer Fake-Dienste anbietet.

Einen Dienst an Port 2222 kann jeder anbieten - nicht vertrauenswürdig.

 

[anawak12]

Einen Dienst an Port 2222 kann jeder anbieten - nicht vertrauenswürdig.

Okay, danke für die Erklärung. Aber der Dienst läuft ja eigentlich auf Port 22 - die Firewall (eigenständiges Gerät) leitet Port 2222 auf Port 22 des Webservers weiter. Ich denke, diese Konstellation ist unproblematisch, oder?

Alles Gute
anawak

 

[Rastafari]

Okay, danke für die Erklärung. Aber der Dienst läuft ja eigentlich auf Port 22 - die Firewall (eigenständiges Gerät) leitet Port 2222 auf Port 22 des Webservers weiter. Ich denke, diese Konstellation ist unproblematisch, oder?

Das sollte man annehmen. (Ich bin nicht mit deiner FW perdu, also... hm... )

 

[Hilarious]

... zumal, wenn ich das richtig verstehe, MacMark, weniger der Server gefährdet ist, als der (unwissende) Nutzer. Eine Umstellung auf zum Beispiel 2222 sollte demnach für adminstrative Zwecke kein Problem sein.

 

[anawak12]

Danke, dann bin ich ja beruhigt.