11. Januar 201313 J. Hi, ein von mir betreuter Server erkennt plötzlich VON SELBER kein OpenSSH- Login mehr (ich verwende BitVise Tunnelier dafür). Auf dem Server hat sich NICHTS geändert, vor allem keine Kennwörter. Auch das Entfernen und neuinstallieren von OpenSSH half nicht. Kennt sich hier jemand aus und kann helfen ? Carsten
11. Januar 201313 J. hast du mal in deinen keys geguckt und den betreffenden gelöscht? lauscht der server auf den port? gruss z.
11. Januar 201313 J. Ersteller Was bedeutet "in die Keys geguckt und gelöscht" ? Ich habe mit mkpasswd -d die Datei erstellt, aber das sieht nach recht unformatiertem Text aus. Der Server lauscht- nehme ich einen anderen Port (ich habe es manuell von 22 weggeändert in etwas 5-stelliges, um Portscans zu minimieren, die suchen "so hoch" nicht mehr), dann bricht er mit einem Fehler ab. Hier ist es so, dass er den Key Exchange noch macht, und dann nach dem Password fragt. Nehme ich das Admin- Kennwort des Servers (w2k3 sbs), so kriege ich dieselbe Maske wieder. Nehme ich no auth., dann kommt das Textbanner aus der .txt- Datei, von daher bin ich sicher, das das soweit läuft. Carsten
11. Januar 201313 J. naja, ich kenn das nur unter linux und da hab ich eine datei in /home/username/.ssh, die known_hosts heisst, darin sind keys zu den betreffenden verbindungen. wenn sich ein ssh-zugang ändert, oder wenn du da eine gewisse zeit einstellst, musst du dann halt den betreffenden key-eintrag für die betreffende verbindung löschen und gut ist. was macht ein telnet www.name.de 22 ? gruss z.
11. Januar 201313 J. Ersteller Das Telnet macht, egal ob mit oder ohne Port, nur "Verbinden fehlgeschlagen". Die known_hosts kann ich mal sichten und reinsehen. Leider komm ich an die Kiste von hier ja grad nicht mehr dran. Schlauerweise hätte ich mir nur einen PC mit Teamviewer im netz anlassen sollen, und dann von da aus per RDP weiter, aber das hab ich verpennt, also hinfahren... Carsten
11. Januar 201313 J. hi, wenn telnet "verbindung fehlgeschlagen" sagt, dann is wohl der dienst (sshd) down... kannst du die kiste nicht port scannen? gruss z.
11. Januar 201313 J. Ersteller Neues: Telnet auf die Kiste OHNE www davor und mit dem "special Port", nennen wir ihn 22222, geht: Da wird die Version des OpenSSH angezeigt. 3.8.1p1 oder so. Dann kann ich irgendwas tippen, und kriege dann sofort "protocol mismatch". Hilft das ? Carsten
11. Januar 201313 J. dann geht der sshd. wenn du willst, schick mir ne pn mit den daten und ich guck mal, was er macht... ich hab ja keine keys von dem ding und sehe dann, ob er ein passwort will... logischerweise nicht das passwort schicken... ;-) oder versuch es selbst mit einem anderen rechner. gruss z.
11. Januar 201313 J. du auch... nmap (portscan) macht nix.... ist da ne firewall dazwischen? sicher, dass der port stimmt? gruss z.
11. Januar 201313 J. ok, schade, dass ich nicht helfen konnte, viel erfolg, ziemlich sicher macht der router davor wellen.... gruss z.
11. Januar 201313 J. Ersteller Hast noch ne PN. Ist ein Lancom, den habe ich jüngst upgedatet, evtl. hat der dabei ungefragt den Port abgedichtet... Carsten
11. Januar 201313 J. Aus diesen Gründen ist es schon sinnvoll bei Standardports zu bleiben, aber dafür DualFactor Authentifizierung mit Key und Passwort zu verwenden. Dann können einem die Portscanner egal sein. Wir haben in der Firma ca. 50 Systeme und betreuen und überwachen aktiv 220 Systeme (ausnahmslos Unix/Linux/*BSD) und, die alle "draussen" hängen und SSH auf Port 22 erlauben. Aufgemacht wurde noch keiner in 10 Jahren, aber es wird auch kein Zugang nur auf Passwortbasis eingerichtet. Vielleicht eine Überlegung wert? Denn den Port zu verstecken ist ja auch nur Security by Obscurity, würde ich mich nicht drauf verlassen. Ciao, Daniel
14. Januar 201313 J. Ersteller Naja, man braucht ja den Port, und ein LANGES Passwort. Das hat mir bisher immer ausgereicht. Zum Problem an sich: Ich habe heute den OpenSSHD entfernt, neu aufgesetzt. Half nix. Den Router durchgeguckt, half nix. Immerhin bin ich jetzt SICHER, das Router und OpenSSH miteinander reden, denn wenn ich auf dem Server in der config_SSHD etwas editiere, reagiert im Anmeldeprozess der Client darauf. Das kann nur sein, wenn der Port richtig ist. Also: Irgendwas führt dazu, dass Opensshd auf Windows (2k3) das Kennwort, was ihm der Client gibt, nicht akzeptiert. Kann das etwas mit den Zertifikatsberechtigungen zu tun haben, die man beim IIS - Dienst einträgt ? Da war kürzlich was im Exchange defekt, der System Manager zeigte die Verwaltung der öffentlichen Ordner nicht an, und dann habe ich dort gemäß MS- Anleitung irgendeine 128 bit- Schlüssellänge als "nein, nicht erzwungen" gesetzt. Vielleicht ist es sowas ? Wenn man doch nur iiiiirgendwo bei google etwas dazu finden würde, verflixt... Carsten
Erstelle ein Konto, um zu kommentieren