PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ssh DNS lookup



Jorge
05.11.02, 09:51
Hallo,

wenn ich mich per ssh auf einen Rechner in meinem Netzwerk verbinde und dies über einen Aliasnamen des Rechners geschieht, löst mein lokaler DNS Server einen DNS lookup zum nächsten DNS Server aus und initiiert somit eine Einwahl meines Routers.
Wenn ich allerdings per nslookup meinen DNS Server abfrage, funktioniert alles, auch die Alias Abfragen ohne das ein DNS lookup ins Internet geht.

Ein ssh connect mit dem FQDN funktioniert dagegen wie erwartet.

Jemand einen Tipp?

geronet
05.11.02, 17:28
Kannst du mal den Traffic per tcpdump oder "snort -dvi" mitschneiden? Wär ganz interessant..

Grüsse, Stefan

Jorge
05.11.02, 17:30
Hm, nicht wirklich, da ich beide Tools erst übersetzen und installieren müsste (LFS). Ich schau mir heute Abend man ssh -v an, vielleicht sieht man ja da etwas...

Jasper
05.11.02, 18:06
Original geschrieben von Jorge
Hallo,

wenn ich mich per ssh auf einen Rechner in meinem Netzwerk verbinde und dies über einen Aliasnamen des Rechners geschieht, löst mein lokaler DNS Server einen DNS lookup zum nächsten DNS Server aus und initiiert somit eine Einwahl meines Routers.
Wenn ich allerdings per nslookup meinen DNS Server abfrage, funktioniert alles, auch die Alias Abfragen ohne das ein DNS lookup ins Internet geht.

Ein ssh connect mit dem FQDN funktioniert dagegen wie erwartet.

Jemand einen Tipp?

hast du alle versuche mit leerem cache gemacht?
schneid mal beim dns-server die requests mit, damit man mal sieht, was er so gefragt wird.

-j

Jorge
09.11.02, 18:05
Hier nun also der Outpout fon ssh -vvv:



carsten@[cws-lx:~]# ssh -vvv cfs-lx
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 1000 geteuid 0 anon 1
debug1: Connecting to cfs-lx [192.168.0.10] port 22.
debug1: temporarily_use_uid: 1000/500 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 1000/500 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/carsten/.ssh/identity type -1
debug1: identity file /home/carsten/.ssh/id_rsa type -1
debug1: identity file /home/carsten/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.0.2p1
debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
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-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,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 128/256
debug1: bits set: 1610/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/carsten/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'cfs-lx' is known and matches the RSA host key.
debug1: Found key in /home/carsten/.ssh/known_hosts:1
debug1: bits set: 1573/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/carsten/.ssh/identity
debug3: no such identity: /home/carsten/.ssh/identity
debug1: try privkey: /home/carsten/.ssh/id_rsa
debug3: no such identity: /home/carsten/.ssh/id_rsa
debug1: try privkey: /home/carsten/.ssh/id_dsa
debug3: no such identity: /home/carsten/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: next auth method to try is keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
carsten@cfs-lx's password:

Nach Ausgabe der oben fett dargestellten Zeile stockt der Verbindungsaufbau kurz, mein Router wählt sich ein und danach geht es weiter. Wenn ich selbiges mit dem FQDN mache, sehen die Ausgaben identisch aus, bis darauf, daß keine Pause eingelegt wird.

Hm, werde jetzt mal noch bei meinem named die das logging aktivieren.

geronet
09.11.02, 18:11
Vielleicht irgendwas mit NIS und dem getuid?

Jorge
09.11.02, 18:37
Original geschrieben von geronet
Vielleicht irgendwas mit NIS und dem getuid?

Es ist kein NIS konfiguriert, bzw. aktiv.

Hier nun das logging meines BIND:



client 192.168.0.1#32789: query: cfs-lx.matrix.lan IN AAAA
client 192.168.0.1#32789: query: cfs-lx IN AAAA
client 192.168.0.1#32789: query: cfs-lx.matrix.lan IN A


Was bedeuten die "AAAA"? Ansonsten macht ssh erst einen lookup auf den FQDN und dann auf den Alias und nochmals auf den FQDN. Ich werde da nicht schlau draus... :confused:

Jasper
10.11.02, 00:54
Original geschrieben von Jorge
Es ist kein NIS konfiguriert, bzw. aktiv.

Hier nun das logging meines BIND:



client 192.168.0.1#32789: query: cfs-lx.matrix.lan IN AAAA
client 192.168.0.1#32789: query: cfs-lx IN AAAA
client 192.168.0.1#32789: query: cfs-lx.matrix.lan IN A


Was bedeuten die "AAAA"? Ansonsten macht ssh erst einen lookup auf den FQDN und dann auf den Alias und nochmals auf den FQDN. Ich werde da nicht schlau draus... :confused:

AAAA sind IPv6 A-records. verwendest du zufällig suse?

die ersten beiden lassen sich durch ausschalten von IPv6 oder einrichten von ipv6-zonen beheben. jetzt wäre interessant, welche queries den dialout triggern. sinds die ersten beiden (vermutlich), wäre das problem damit gelöst. ists der letzte, stimmt was mit deiner bind/resolver-config nicht.

-j

geronet
10.11.02, 10:50
Nein er verwendet LFS, aber wenn du IPv6 aktiviert hast könnte das schon so sein ;)

Wie sieht denn deine resolv.conf auf den Rechnern aus (auf dem wo der DNS läuft auch)?
Und deine Hosts-Dateien?

Jorge
10.11.02, 11:59
Original geschrieben von geronet
Nein er verwendet LFS, aber wenn du IPv6 aktiviert hast könnte das schon so sein ;)

Nein IPv6 habe ich nicht aktiv.


Wie sieht denn deine resolv.conf auf den Rechnern aus (auf dem wo der DNS läuft auch)?
Und deine Hosts-Dateien?



carsten@[cws-lx:~]# more /etc/resolv.conf
# /etc/resolv.conf
# Stand 24/08/01
#
nameserver 192.168.0.10
search matrix.lan
carsten@[cws-lx:~]# cfs-lx
root@cfs-lx.matrix.lan's password:
Last login: Sat Nov 9 19:50:21 2002 from cws-lx.matrix.lan

##### ##### #### # # #
# # # # # #
# #### ### ### # ##
# # # # # #
##### # #### ##### # #

root@[cfs-lx:~]# more /etc/resolv.conf
nameserver 192.168.0.10
search matrix.lan
root@[cfs-lx:~]# logout
Connection to cfs-lx.matrix.lan closed.
carsten@[cws-lx:~]# more /etc/hosts
#
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server. Just add the names, addresses
# and any aliases to this file...
#

127.0.0.1 localhost.matrix.lan localhost

# End of hosts.
carsten@[cws-lx:~]# cfs
root@cfs-lx.matrix.lan's password:
Last login: Sun Nov 10 11:55:04 2002 from cws-lx.matrix.lan

##### ##### #### # # #
# # # # # #
# #### ### ### # ##
# # # # # #
##### # #### ##### # #

root@[cfs-lx:~]# more /etc/hosts
# Begin /etc/hosts
#
# Syntax:
# IP-Adress FQDN Hostname/Alias

127.0.0.1 localhost
192.168.0.10 cfs-lx.matrix.lan cfs-lx
root@[cfs-lx:~]#logout
Connection to cfs-lx.matrix.lan closed.
carsten@[cws-lx:~]#

Jasper
10.11.02, 12:43
Original geschrieben von Jorge
Nein IPv6 habe ich nicht aktiv.


sshd auch ohne ipv6 kompiliert?

-j

Jorge
10.11.02, 13:12
Original geschrieben von Jasper
sshd auch ohne ipv6 kompiliert?


Hm, wenn ich ehrlich bin, keine Ahnung mehr. Ich werde mal den aktuellen SSHD kompilieren und das ganze nochmals testen.

geronet
10.11.02, 14:25
Dein Nameserver läuft auf cfs-lx oder? Wenn ja sollte doch in der Datei resolv.conf auf ihm nicht die IP-Adresse von eth0 stehen sondern 127.0.0.1 also so:

root@[cfs-lx:~]# more /etc/resolv.conf
nameserver 127.0.0.1
search matrix.lan

Der Nameserver sollte natürlich auch drauf lauschen.

Verdammt die wichtigste Datei hab ich vergessen, wie sehen die /etc/nsswitch.conf bei beiden aus?

Grüsse, Stefan

Jorge
10.11.02, 14:53
Original geschrieben von geronet
Dein Nameserver läuft auf cfs-lx oder?

Ja, cfs-lx ist mein zentraler Server daheim, welcher NFS, Samba, Exim, DNS als Dienste anbietet.


Wenn ja sollte doch in der Datei resolv.conf auf ihm nicht die IP-Adresse von eth0 stehen sondern 127.0.0.1 also so:

root@[cfs-lx:~]# more /etc/resolv.conf
nameserver 127.0.0.1
search matrix.lan


Theortisch ist das richtig, aber es kann mit dem loopback-device zu Problemen kommen. Das ist auch der Grund, warum in der /etc/hosts der cfs-lx drin steht, im Gegensatz zum CLient, welcher nur das loopback-device hat.


Verdammt die wichtigste Datei hab ich vergessen, wie sehen die /etc/nsswitch.conf bei beiden aus?


Auf dem cfs-lx:
hosts: files dns

Auf dem Client:
hosts: dns files


Grüsse, Stefan [/B][/QUOTE]

geronet
10.11.02, 14:58
Der Fehler kann ja nur beim DNS-Server liegen, denn er dürfte keine Anfrage auf den nächsten Server schicken weil er ja über die Zone bescheid weiss...

hmm..

Mach mal nen anderen Test indem du nicht ssh als Dienst verwendest sondern telnet, nfs, ping, nslookup oder sonstwas du weisst schon was ich meine.. und schau ob er damit auch eine Einwahl auslöst wenn du den FQDN oder nur den Teilnamen nimmst.

Grüsse, Stefan

Jorge
10.11.02, 15:16
Original geschrieben von geronet
Der Fehler kann ja nur beim DNS-Server liegen, denn er dürfte keine Anfrage auf den nächsten Server schicken weil er ja über die Zone bescheid weiss...

Ich habe langsam den sshd selbst im Verdacht, daß der eben keine aliase mag...



Mach mal nen anderen Test indem du nicht ssh als Dienst verwendest sondern telnet, nfs, ping, nslookup oder sonstwas du weisst schon was ich meine.. und schau ob er damit auch eine Einwahl auslöst wenn du den FQDN oder nur den Teilnamen nimmst.


Telnet wird schwierig -> nicht installiert und wird auch nicht installiert :)



carsten@[cws-lx:~]# ping -c1 cfs-lx
PING cfs-lx.matrix.lan (192.168.0.10): 56 octets data
64 octets from 192.168.0.10: icmp_seq=0 ttl=255 time=0.1 ms

--- cfs-lx.matrix.lan ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.1 ms
carsten@[cws-lx:~]# nslookup -sil
> cfs-lx
Server: 192.168.0.10
Address: 192.168.0.10#53

Name: cfs-lx.matrix.lan
Address: 192.168.0.10
> cfs-lx.matrix.lan
Server: 192.168.0.10
Address: 192.168.0.10#53

Name: cfs-lx.matrix.lan
Address: 192.168.0.10
> ntp
Server: 192.168.0.10
Address: 192.168.0.10#53

ntp.matrix.lan canonical name = cfs-lx.matrix.lan.
Name: cfs-lx.matrix.lan
Address: 192.168.0.10
> ntp.matrix.lan
Server: 192.168.0.10
Address: 192.168.0.10#53

ntp.matrix.lan canonical name = cfs-lx.matrix.lan.
Name: cfs-lx.matrix.lan
Address: 192.168.0.10
> exit

carsten@[cws-lx:~]#

Alles ohne Einwahl des Routers....

Bin gerade dabei den aktuellen SSH und SSL zu installieren, werde berichten.

Jorge
10.11.02, 16:08
So, habe nun OpenSSL 0.9.6g und OpenSSH_3.5p1 installiert, aber das Verhalten ist immer noch das selbe. SSH hat per default IPv4 aktiviert.

Kann es also sein, daß der sshd keine aliase mag?

geronet
10.11.02, 16:42
man resolv.conf:

domain Local domain name. Most queries for names within this domain
can use short names relative to the local domain. If no domain
entry is present, the domain is determined from the local host
name returned by gethostname(2); the domain part is taken to be
everything after the first `.'. Finally, if the host name does
not contain a domain part, the root domain is assumed.

Es kann sein dass gethostname() dir dazwischenfunkt.. also schreib mal in deine resolv.conf auf dem Client das

domain matrix.lan

rein und versuchs nochmal.

Grüsse, Stefan

Jorge
10.11.02, 19:03
Original geschrieben von geronet

Es kann sein dass gethostname() dir dazwischenfunkt.. also schreib mal in deine resolv.conf auf dem Client das

domain matrix.lan

rein und versuchs nochmal.


Bringt nix. :(

Jorge
11.11.02, 21:48
Das Problem tritt nicht auf, wenn man ssh zwingt IPv4 zu nutzen. Lösung ist also ssh -4 ...

geronet
11.11.02, 21:53
alias ssh='ssh -4'

hehe :)