Routing Probleme? (sshd: authentication timeout)

K

KingNothing

Well-Known Member
Hi,
ich habe letztens einen kleinen PII ausgepackt, wollt ihn als Server mit FreeBSD 5.3/5.4 einsetzen, jedoch haben ich Probleme mit dem SSH-Daemon.
Immer wenn ich versuche per SSH auf den PC zu kommen, bekomme ich auf dem Server ein "Timeout before authentication".
Ich habe gelesen dass dies warscheinlich ein Routing Problem/Namensauflösung ist - ich habe mit bei sysinstall als Gateway den (DSL-)Router eingetragen und in /etc/resolv.conf den nameserver 217.237.150.33.

Ich habe testweise mal ein Damn Small Linux gebootet, dort mit netcardconfig das Netzwerk mit genau den gleichen Werten eingerichtet, und siehe da - es lief.

Bin ein wenig ratlos,
Hat jemand eine Ahnung wo der Fehler liegen könnte?
 
Editier mal deine /etc/hosts auf dem Client.

Was auch sein könnte:
Hast du vielleicht /etc/hosts.allow bzw. deny gesetzt, das du nur von bestimmten IP's den Zugriff auf den Server erlaubst ?
 
Hi, ich hab nochmal beide /etc/hosts kontrolliert (Client wie server), scheint alles ok zu sein
in beiden steht folgendes:
Code: 
127.0.0.1       localhost
192.168.1.11    KingNothing kingnothing.bsd.net
192.168.1.10    server server.bsd.net

Code: 
[B]$ ssh -vv 192.168.1.10[/B]
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.10 [192.168.1.10] port 22.
debug1: Connection established.
debug1: identity file /home/ottodavid/.ssh/identity type -1
debug1: identity file /home/ottodavid/.ssh/id_rsa type -1
debug1: identity file /home/ottodavid/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 Fre
eBSD-20040419
debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up14-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,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
tr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
tr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,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-sha1,diffie-hellman-gro
up1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
tr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
tr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: 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: 128/256
debug2: bits set: 487/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.10' is known and matches the DSA host key.
debug1: Found key in /home/ottodavid/.ssh/known_hosts:1
debug2: bits set: 507/1024
debug1: ssh_dss_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/ottodavid/.ssh/identity ((nil))
debug2: key: /home/ottodavid/.ssh/id_rsa ((nil))
debug2: key: /home/ottodavid/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ottodavid/.ssh/identity
debug1: Trying private key: /home/ottodavid/.ssh/id_rsa
debug1: Trying private key: /home/ottodavid/.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: [Password]
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
 
Bei mir gab es auch Probleme bei der Authentisierung. Meine Empfehlung ist,
nicht direkt zu debuggen, sondern beim Verbindungsaufbau per tcpdump mal
nachzuschauen, was auf dem Netz so pasiiert. Da siehst du dann, bei welcher
Namensauflösung es hakt.

Viele Grüße

Rainer
 
Dank Tulkas bin hab ich nun rausgefunden, dass es die Namensauflösung ist,
ohne resolv.conf klappts einwandfrei, anscheined fragt er den dns bevor er in die /etc/hosts schaut, wie kann ich dass ändern?
 
In host.conf hab ich nixx geändert-es steht genauso dort, wie im wiki, auch alles andere ist so wie dort eingerichtet....
 
Hast du in deiner resolv.conf deinen Router oder die Nameserver deines Providers drin?

Habe mal festgestellt, das wenn der eigene Router die Namensauflösung macht, nslookup auch nichtmehr funktioniert.
 
Des er zuerst in der hosts nachfragt ist so gewollt, das lässt sich nicht ändern.

Dein SSH-Deamon startet aber schon ohne Fehlermeldungen oder? Du versuchst auch nicht als Root drauf zuzugreifen oder?
 
@SirraX:
Ähm, er schaut nicht zuerst in der /etc/hosts, und genau hier liegt auch dass Problem.
Ich hab alles so konfiguriert wie es im wiki steht, bzw wie es nach der installation von FreeBSD ist, und es funzt nicht, wenn ich die resolv.conf entferne funzt alles einwandfrei.

sshd startet ohne fehlermeldungen, ich kann von dem server selber auch einwandfrei mit ssh ottodavid@localhost darauf zugreifen.
 
nein, die "loesung" des problems ist, dass du keine hostnamen verwendest, die dir nicht gehoeren.

schon schlimm, was heutzutage so alles als "problemloesung" durchgeht. </rant>

edit: ich gehe natuerlich davon auss, dass dir bsd.net tatsaechlich nicht gehoert. moeglich ist dann die verwendung nichtexistenter tlds, wie zb .lan oder .intern oder der extra fuer (global) ungueltige hostnamen gedachten .invalid. alternativ kannst du auch eine subdomain einer dir gehoerenden domain nehmen, wie zb .lan.domain.de.
 
Zuletzt bearbeitet:
hab mir 3 Tage lang den Kopf zerbrochen und mich gefragt warum der ssh nicht funktioniert hat. hatte auch mitbekommen, das das was mit dem dns-lookup zu tun hat, aber weiter bin ich nicht gekommen.
Mittels UseDNS nofunzt es jetzt 1a. Auch wenn es ein Workaround ist.
Tjo, aber dass allein bringts trotzdem nich, ich hatte z.b. "bsdnet" als domain versucht, ging aber auch nich.
Zum Vergrößern anklicken....
Dem kann ich nur zustimmen. Ich verwende intern auch tld's dies nicht gibt, aber irgendwie wollte das nicht funzen. Wobei mir gerade während des tippens einfällt, das bei uns der Router getauscht wurde. Evtl. kann das auch daran liegen. Auf jedenn fall kann ich jetzt wieder gescheit arbeiten...

Gruss schibumi
 
Ja nur mal so als Feedback - ich habs immernoch so am laufen und nie Probleme damit gehabt, also warum soll ichs ändern.
Bin richtig zufrieden mit FreeBSD, bei einem Server kommt mir (fürs erste) nichts anderes auf die Platte.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben