• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Putty Verbindungsproblem

G

gTux

Ich habe ein ungewoehnliches Putty Problem. Ich habe einen Suse 11.2 PC (nur Konsole) der am Netzwerk hängt und eigentlich nichts weiter als ein Samba Server ist. Der Router im Netz ist eine Fritzbox 7270 und die Topographie ist Stern.

Wenn ich über das Netzwerk (gleicher IP Bereich) oder von einem anderen Linux Rechner über DYNDNS (auch mein Android Handy) auf den PC zugreifen möchte - kein Problem. Die Portweiterleitung in der Fritzbox funktioniert gut ich kann alles tun was ich will. Auch im Netzwerk über Putty klappt das.

Aber wenn ich jetzt über DYNDNS mit Putty von Außerhalb zugreife (aus dem Internet) dann passiert komisches. Zuerst wird eine Verbindung erstellt, er fragt das PW ab. Wenn ich ein falsches Passwort eingebe, dann meldet er auch, daß es falsch wäre -> Access Denied.

Doch dann, wenn ich das richtige PW eingebe kommt folgende Fehlermeldung:
Code: 
Using username "root".
Using keyboard-interactive authentication.
Password:
Access denied
Using keyboard-interactive authentication.
Password:
ssh: connect to host 123456.dyndns.org port 22: No route to host

Vorher hatte das aber mit den exakt gleichen Einstellungen bei Putty immer geklappt ich hatte paar Sachen in der Fritzbox verstellt, ich bin aber jetzt nicht mehr sicher ob es die FB ist oder der Samba Server. Muss ich noch eine Portweiterleitung zurück - ins Internet - legen? Ich glaube, ich hab da bei den Fritzboxeinstellungen etwas gelöscht, was ich nicht löschen sollte.

Nur jetzt weiß ich nicht mehr was. :???:
 
HBtux

HBtux

Hast Du die Weiterleitung auf der FritzBox auf einen Hostnamen eingerichet, der von der FritzBox nicht aufgelöst werden kann?
 
OP
G

gTux

Hi, also wenn ich mit meinem Phone oder mit PCs mit Linux drauf über das gleiche Sockel reinkomme, dann muss die Portweiterleitung richtig eingestellt sein. Einzig und alleine Putty funktioniert nicht.
 
OP
G

gTux

Vollständigkeitshalber - das sieht dann so aus: http://img146.imageshack.us/i/puttybug.jpg/

Es passiert aber nur, wann das richtige PW eingegeben wird. Gebe ich ein falsches ein, wird der Zugriff verweigert.
 
framp

framp

Moderator
Teammitglied
Bau mal die ssh Verbindung von einem Linuxrechner mit
Code: 
ssh -vv targetHost
auf. Dann bekommst Du eine Menge Meldungen beim Verbindungsaufbau. Sieh sie Dir mal genauer an. Wenn Du damit nicht weiterkommst poste mal hier die Ausgaben.
 
OP
G

gTux

Habs gemacht. Mit Ubuntu 9.10 bin ich rein:

Code: 
mobil:~$ ssh -vv root@123456.dyndns.org -p16420
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 123456.dyndns.org [12.34.56.789] port 16420.
debug1: Connection established.
debug1: identity file /home/joerg/.ssh/identity type -1
debug1: identity file /home/joerg/.ssh/id_rsa type -1
debug1: identity file /home/joerg/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[123456.dyndns.org]:16420' is known and matches the RSA host key.
debug1: Found key in /home/joerg/.ssh/known_hosts:2
debug2: bits set: 489/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/joerg/.ssh/identity ((nil))
debug2: key: /home/joerg/.ssh/id_rsa ((nil))
debug2: key: /home/joerg/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/joerg/.ssh/identity
debug1: Trying private key: /home/joerg/.ssh/id_rsa
debug1: Trying private key: /home/joerg/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

Ich wüsste nur nicht, was das bringen soll - ich komme ja mit Linux rein. Nur mit Putty klappt es nicht.
 
framp

framp

Moderator
Teammitglied
gTux schrieb:
Ich wüsste nur nicht, was das bringen soll - ich komme ja mit Linux rein. Nur mit Putty klappt es nicht.
Zum Vergrößern anklicken....
Sorry - hatte Deinen Thread nicht richtig gelesen :eek:ps: . Du kannst das logging auch auf dem Server einschalten.
Auszug aus man sshd_config:
Code: 
     LogLevel
             Gives the verbosity level that is used when logging messages from sshd(8).  The possible values are: QUIET, FATAL, ERROR, INFO, VER‐
             BOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3.  The default is INFO.  DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify
             higher levels of debugging output.  Logging with a DEBUG level violates the privacy of users and is not recommended.
 
OP
G

gTux

Ich habe mich an diese Anleitung gehalten. Ausser Tunnel Port - da habe ich "dynamisch" gewählt.

http://www.cfd.tu-berlin.de/Lehre/EDV1/downloads/ssh/putty/tunnel.html

Früher hatte es immer geklappt, auch im LAN geht es.
 
OP
G

gTux

Ich fand einfach keine andere Anleitung und schon garnicht zum Thema "dynamisch". Zudem ist es bei LAN sehr hilfreich gewesen.

Mittlerweile habe ich es gelöst, allerdings verwirrt mich die Lösung. Vielleicht wisst Ihr ja, was damit ist.

Unter "SSH/Remote Command"
-> http://www.cfd.tu-berlin.de/Lehre/EDV1/downloads/ssh/putty/PuTTY-Konfiguration-6.png

habe ich das Remotecommand vorher (als es nicht ging) so eingetragen

Code: 
ssh 123456.dyndns.org

Jetzt habe ich es ganz weggelassen und es geht komischerweise.

Hast du eine Idee wieso?
 
S

spoensche

So gut kenne ich mich mit Putty nicht aus, weil ich dafür meine Konsole in Linux habe. :)

Ich vermute mal das <poolrechner> durch den "angewählten" Host ersetzt wird.
 
drboe

drboe

gTux schrieb:
Unter "SSH/Remote Command"
-> http://www.cfd.tu-berlin.de/Lehre/EDV1/downloads/ssh/putty/PuTTY-Konfiguration-6.png

habe ich das Remotecommand vorher (als es nicht ging) so eingetragen

Code: 
ssh 123456.dyndns.org

Jetzt habe ich es ganz weggelassen und es geht komischerweise.

Hast du eine Idee wieso?
Zum Vergrößern anklicken....
Der Befehl, der unter 'Remote Command' stand, nämlich 'ssh 123456.dyndns.org, sollte vom Zielrechner ausgeführt werden. D. h., es wurde sofort mit der Anmeldung versucht vom Zielrechner aus eine ssh-Session mit dem PC 123456.dyndns.org aufzubauen. Der Zielrechner findet nun 123456.dyndns.org nicht (DNS? ein Ping auf die Adresse 123456.dyndns.org führt nach Polen), weshalb er mit "ssh: connect to host 123456.dyndns.org port 22: No route to host" antwortet.

M. Boettcher
 
OP
G

gTux

Ach, dann sollte die lokale IP des Zielrechners da rein... Wenn ich das richtig verstehe.
 
drboe

drboe

gTux schrieb:
Ach, dann sollte die lokale IP des Zielrechners da rein... Wenn ich das richtig verstehe.
Zum Vergrößern anklicken....
Nein! Wie spoensche schon schrieb, lässt Du die Konfiguration wie sie ist und das Feld "Remote command" grundsätzlich leer. Der SSH-Befehl da macht nur Sinn, wenn im LAN hinter dem adressierten Zugangs-PC ein weiterer Computer steht, den man immer übernehmen will. Statt in der Konsole des ersten PC dann eine SSH-Verbindung zum nächsten PC aufzubauen, lässt man putty das automatisieren. Du willst aber den PC, den Du per IP ansprichst, direkt kontrollieren. D. h. Du konfigurierst in putty:

- Session > Host Name: IP-Adress oder Name des PC, den Du kontrollieren willst
- Session > Connection Typ: SSH
- Session > saved Session: Name der Konfiguration
- Connection > Data > Auto-login username: Name, mit dem Du Dich gewöhnlich beim PC anmeldest

Die übrigen Werte kannst Du in der Regel auf Default lassen, falls Du nicht besondere Wünsche an die Farben und Größe (Abschnitt Window) hast oder Tunnel definieren willst (SSH > Tunnels)

M. Boettcher
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben