Keine Verbindung per SSH zum Server

Hinweis: In dem Thema Keine Verbindung per SSH zum Server gibt es 7 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo zusammen,
    seit Tagen durchwühle ich das Internet um eine Lösung oder eine Idee zu finden, warum ich nicht per SSH auf meinen Server komme. Eine Verbindung per VNC funktioniert dagegen einwandfrei.


    Clientrechner: Win7 und Putty
    Server: OS: Suse 12.1 (64bit); Firewall: keine, alle Updates durchgeführt
    Netzwerk: internes Heimnetzwerk, Client per WLan, Server hängt per Kabel am Router.


    Das merkwürdige dabei ist, dass es zweimal funktioniert hat. Hatte abends die sshd_config geändert und konnte mich verbinden. Zufrieden den Server ausgeschaltet (befindet sich noch in der Aufbauphase), am nächsten Tag eingeschaltet, seitdem keine Verbindung mehr per ssh.


    Ich rufe am Client Puty auf, es erfolgt ein Verbindungsversuch aber keine "Login:" Ausgabe.
    Die Daten von Putty habe ich mal mitgeschnitten:

    Code
    Event Log: Server unexpectedly closed network connection 
    Die vollständigen Daten findet ihr in der angehängten Datei (Wie kann ich eigentlich einen Link draufsetzen?)


    Am Server gibt es in /var/log/messages folgende Einträge:

    Code
    Oct 2 08:50:13 AGHnetServer sshd[5955]: Set /proc/self/oom_score_adj to 0 
    Oct 2 08:50:13 AGHnetServer sshd[5955]: Connection from 10.3.2.10 port 54201 
    Oct 2 08:54:29 AGHnetServer sshd[6040]: Set /proc/self/oom_score_adj to 0 
    Oct 2 08:54:29 AGHnetServer sshd[6040]: Connection from 10.3.2.10 port 54246


    Mit der Zeile /proc/self/oom_score_adj kann ich nichts anfangen. In der Zeile mit der Verbindung fehlt mir noch SSH2.


    Der Vollständigkeit halber noch die sshd_config:


    Ich habe bereits einiges ausprobiert:
    1. in Win7 die Firewall deaktiviert - ohne Erfolg
    2. in der Win Registry und im Suse den ausgetauschten Schlüssel gelöscht (vielleicht hatte ich unbeabsichtigt irgendetwas irgentwo im Suse verbogen) - ohne Erfolg, Schlüssel wird nicht ausgetauscht
    3. Ich habe noch einen ext. Server mit Suse 10.x bei einem Provider für meine HP. Um auszuschließen, dass ich ein Win7 Problem habe, mußte ich dort erstmal die SSH Verbindung testen. Also es scheint mit Win7 etwas schwieriger zu sein, denn der 1. Verbindungaufbau klappt selten. Spätestens der 4. funktioniert. Warum auch immer.
    4. Jetzt habe ich noch einen Test gemacht und bin mit einem anderen Client, auf dem WinXP läuft per SSH auf meinen Heimserver gegangen und siehe da, kein Problem.


    Jetzt zu meinen Fragen:
    1. Ist meine sshd_config so ok? Wenn ja,
    2. warum bekomme ich mit meinem Win7-Client keine Verbindung? (Vielleicht ist die Frage hier ja falsch, aber wo sollte ich sie sonst stellen)
    3. An welchen Einstellungen muss ich drehen, damit es funktioniert?


    Ich danke euch allen schon jetzt für eure Mühe und eure Ideen.
    Gruß Andreas

  • Die sshd.conf ist nicht in Ordnung.
    Am brutalst falsch Möglichem (um mal politischen Jargon zu verwenden),
    ist das "PermitRootLogin yes".
    Wer das angibt, sollte niemals einen Server auch nur einschalten.
    Auch wenn er (oft nur scheinbar) rein local läuft.
    Der korrekte Weg, ist das IMMER zu verbieten,
    sich als normaler user mit dem Server zu verbinden
    und dort mit "su" oder "sudo" root zu werden.


    Dein "Set /proc/self/oom_score_adj to 0 " hat nichts mit dem Problem zu tun.
    (Es sei denn, die Kiste hat tatsächlich kein RAM+Swap mehr zur Verfügung.)
    OOM == Out Of Memory.
    Ein eigenständiger Process überwacht die andere Prozesse, wie und wieviel Speicher sie strapazieren.
    Gerät der kernel an die absolute Speichergrenze ( pys RAM + Swap - bestimmteReserve ), so wird dieser "watchdog" nach seinem Algorithmus irgendeinen Process killen, um das System am Laufen zu halten.
    Vergiss also diese "Spur".


    Trotzdem du dich bemüht hast, möglichst viel Info zu bringen, was sehr, sehr löblich ist, sind sie leider nicht sonderlich erhellend.
    Du hast etwas an der sshd.conf geändert, aber WAS schreibst du nicht.
    Ich vermute, diese Änderung ist schuld.
    Denn damit eine Änderung wirksam wird, muss man den SSH-Server neu starten, was du durch Weiterarbeiten am nächsten Tag. Oder hast du NACH der Änderung den sshd neu gestartet?


    Das Putty log ist nett. Spricht aber auch nicht wirklich, die Wahrheit.
    Einfacher kämen wir zum Ziel, wenn du eine ssh- Verbindung mit "verbosity" aufrufen würdest.
    Unter GNU/Linux ist das sowas wie:

    Code
    ssh -v   user@host.tld


    (mehrere "v"s (also z.B -vv ) erhöhen die Anzahl der Meldungen.)
    Dein Putty kann sowas auch. Lies mal dort nach.


    (und stelle bei der Gelegenheit gleich bei dem Putty ein, es möge künftig keine od- Dumps mehr machen. Liest sich einfach zu schwer )


    Ich denke, du hast jetzt schlicht ein Auth Problem.
    Du weist du den Server an nur Protocol V2 zu nehmen (Zeile 15: Protocol 2 )
    Wenn du das wirklich willst, solltest du ein wenig nach "ssh protocol 2"
    Und sage dann deinem Putty, wie es sich genau verbinden soll
    UND die Weise, wie sie sich autrhentifizieren sollen, muss auf beiden Seiten gleich sein.


    Mit einem Wort: Lass die Finger davon, kommentiere die Zeile 15 (Protocol 2) einfach aus.
    Und starte den sshd neu!


    Falls es immer noch nicht geht, stelle putty so ein, dass vernünftige Loglevel lesbar ausgespuckt werden.
    Oder einfacher: Geh mit einer anderen Linuxkiste drauf mit "ssh -v ..."
    Zur Not kannst du auch mal auf dem Server selbst ein Terminal öffnen und mit "ssh -v user@192.x.x." auf die locale IP-Adresse des Servers verbinden. (Ich glaube du hast local 10.x.x.x)
    Hast du wirklich den sshd neu gestartet?

    Für den Inhalt des Beitrages 46754 haftet ausdrücklich der jeweilige Autor: uhelp

  • Hallo uhelp,
    Dein erster Absatz ist für die Funktion völlig irrelevant. In meinem Heimnetzwerk kann ich ja tun und lassen was ich will.


    Zur ssshd_config und keine Änderungen gepostet. Die Kritik ist angekommen, deshalb noch schnell ein Nachtrag: Ich hatte das X1Forwarding aus und wieder eingeschaltet. Nach meiner Auffassunf hat das wenig mit der urprünglichen Funktion zu tun. Dann habe ich noch die Zeilen "AcceptEvent....." auskommentiert. Ich konnte damit nichts anfangen. Nach einen Restart des SSHD bin ich online gekommen. Habe ehrlich gesagt nicht weiter darüber nachgedacht, war spät abends. Bei nachträglicher Betrachtung haben nach meiner Auffassung die Parameter aber auch nichts damit zu tun.


    Protocol: Ich werde gleichmal Deinen Tipp verfolgen und melde mich dann wieder.


    Noch eine Ergänzung. Dass Einloggen über ssh von der Konsole funktioniert.


    Gruß
    P.S. Deine letzte Frage beantworte ich nicht :)

  • Die Umstellung des Protokolls hat leider keine Erfolg eingefahren.


    Hier noch der Event-Log von Putty:

    Code
    2012-10-02 15:53:05 Looking up host "10.3.2.14"
    2012-10-02 15:53:05 Connecting to 10.3.2.14 port 22
    2012-10-02 15:53:05 Server version: SSH-2.0-OpenSSH_5.8
    2012-10-02 15:53:05 Using SSH protocol version 2
    2012-10-02 15:53:05 We claim version: SSH-2.0-PuTTY_Release_0.62
    2012-10-02 15:53:05 Doing Diffie-Hellman group exchange
    2012-10-02 15:55:05 Server unexpectedly closed network connection


    Mit Diffie Hellman kann ich leider nichts anfangen. Ist das der DSA Schlüssel?



    @uhelp: Ich habe keine zweite Linuskiste, die ich nutzen könnte. Aber wie gesagt von der Konsole geht es. Mit einem WinXP auch, mit einem Win7 nicht. Danke für den Hinweis mit der Authentifizierung, ich werde das jetzt mal verfolgen.

  • Zitat


    3:05 We claim version: SSH-2.0-PuTTY_Release_0.62
    2012-10-02 15:53:05 Doing Diffie-Hellman group exchange


    Mit Diffie Hellman kann ich leider nichts anfangen. Ist das der DSA Schlüssel?


    Nein, Diffie und Hellman haben diesen Algorithmus entwickelt, mit dem sich zwei ssh Teilnehmer eine verschlüsselte Kommunikationsstrecke aufbauen können. Dazu tauschen sie Schlüssel aus. Der sogenante Diffi-Hellman-Group-Exchange.


    Es kann sogar schlicht sein, dass er einfach keinen Schlüssel hat.


    Welche Authentifizierung wird denn verwendet?
    Hast du hostkeys? Oder alles mit Passwort?


    Und wenn du mit anderen Kisten auf den Server kommst, dann ändere doch in der sshd_config das Loglevel auf DEBUG2


    Dann kann man schon eher sehen, was beim Schlüsselaustausch zwischen den Beiden schief geht.


    p.s.
    Das Auskommentieren hat bewirkt, dass der Server wieder anständig die Protokollversion aushandeln kann, was bewirkt, dass ein paar mehr Geräte via ssh keine Probleme kriegen.
    p.s.s
    Deine Frage war, ob die conf so in Ordnung sei - nicht ob sie problemrelevant in Ordnung sei.
    grins

    Einmal editiert, zuletzt von uhelp ()

    Für den Inhalt des Beitrages 46761 haftet ausdrücklich der jeweilige Autor: uhelp

  • Zitat

    Es kann sogar schlicht sein, dass er einfach keinen Schlüssel hat.

    in /etc/ssh gibt es die Datei moduli. Wenn ich richtig gelesen habe, sind dort alle Deffie Hellman Group exchange Schlüssel enthalten.

    Zitat

    Welche Authentifizierung wird denn verwendet?

    Passwort

    Zitat

    Und wenn du mit anderen Kisten auf den Server kommst, dann ändere doch in der sshd_config das Loglevel auf DEBUG2


    Da hatten wir wohl die gleiche Idee. Ich habe DEBUG3 eingeschaltet. Mit folgendem Ergebnis:



    Welcher Schlüssel ausgetauscht werden soll, erkenne ich da nicht. Evtl. liegt es an dem Eintrag IPV6 only. Nur eigentlich hab ich das Protokoll abgeschaltet.

    Zitat

    Das Auskommentieren hat bewirkt, dass der Server wieder anständig die Protokollversion aushandeln kann, was bewirkt, dass ein paar mehr Geräte via ssh keine Probleme kriegen.

    Naja, so ganz stimmt das nicht, da Protocol 2 die DEFAULT Einstellung ist. Der Parameter müßten die Werte 1, 2 übergeben werden. Dann passt es.

  • Nimm Debuglevel 2
    und paste vom Anfang des Verbindungversuches bis zum Abbruch.
    Nicht irgendwas und das unvollständig.


    Aber ich denke, du kriegst das schon alleine hin.

    Für den Inhalt des Beitrages 46765 haftet ausdrücklich der jeweilige Autor: uhelp

  • Ergebnis ist: SSH1 funktioniert SSH2 nicht. Dazu in der sshd_config entweder Protocol 1 oder Protocol 1,2 eintragen und Putty auf prefered Protocol 1 stellen


    @uhelp Danke für Deine Hilfe


    SSH2 bekomme ich nicht zum Laufen. Die Ausgaben dazu habe ich ja schon mehrfach gepostet. Was mir nach mehrmaligen Ansehen auffiel ist die Zeile mit debug1: no match: Putty Release und danach das Umschalten in den Kompatibilitätsmodus. Also habe ich Wireshark aktiviert und auf dem Server gestartet. Da gibt es dann im Protokoll zei nette Zeilen:
    Server > Client = Server: Key Exchange Init
    Client > Server = Client: Diffie-Hellman Key Exchange Init [Malformed Packet]


    Heißt für mich der Client ( also Win7) hat mit einem defekten Paket geantwortet. Deshalb kommt keine Verbindung zustande.


    Dann war es dann wohl ersteinmal und ich benutze SSH1