[FreeBSD]ssh connect traag (> 3 min)

Pagina: 1
Acties:

  • Shagura
  • Registratie: Augustus 2001
  • Laatst online: 19-02 14:34
Ik heb een FreeBSD router die sshd draait. Nu duurt het connecten naar de client bij het opstarten langer dan 3 min.
Nu zal iedereen waarschijnlijk gelijk gaan zeggen dat het een dns probleem is, maar dat is het volgens mij niet.

zo haalt het adden van de hostname van degene die connect in /etc/hosts helemaal niks uit.
Ook maakt het niet uit of ik de optie verifyReverseMapping uit zet in /etc/ssh/sshd_config

Daar komt bij dat als ik vanaf de router zelf 'ssh localhost' of 'ssh 192.168.1.5' (het ip-adres van hemzelf) doe het ook langer dan 3 minuten duurt om te connecten.

Zodra ik echter
code:
1
route delete default
doe werkt alles als een zonnetje. Deze gateway wordt gegeven door mijn dhcp server (mn wanadoo cable eurodocsis modem :r), maar ik snap niet dat het deleten hiervan uit kan maken. Ook als ik bijv. met inet connect (waardoor de default route wordt veranderd) werkt het goed.

Ik vraag me echter af of dit het echte probleem is, want wat maakt het uit of er een gateway is ingesteld voor ssh? Ook wordt deze default route dus elke keer als ik met ssh verbind weer door de dhcp server doorgegeven en elke keer als mijn lease time verloopt zou ik dus weer handmatig op de server de default route moeten deleten, wat voglens mij totaal niet handig is.

Dus nu vroeg ik me af of misschien iemand een echte oplossing heeft :)

[ Voor 4% gewijzigd door Shagura op 08-03-2004 20:24 ]


Verwijderd

Begin eens met het posten van je route tabellen, de ipadressen van de machines waarvandaan je probeert te verbinden en eventueel tcpdump output en ssh -vvv output van een sessie.

  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 11-01 23:32

Nvidiot

notepad!

Ik heb precies hetzelfde probleem, met het verschil dat als mijn internet verbinding eruit ligt (en dus dns) het LANG duurt. Is dns er wel duurt het niet lang. Ik zie met tcpdump dat er een dns request verstuurd wordt voor 192.168.0.3 (waarvandaan ik probeer te connecten)

* Nvidiot bookmarked dit topic

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


  • blender
  • Registratie: Juni 2001
  • Niet online
ssh probeert een reverse dns lookup te doen. Dat lukt niet dus pas als dat getimedout is (mooi woord >:) ) gaat hij verder... wat je kunt doen is met vaste ip adressen werken en een /etc/hosts aanmaken. Dan nog je /etc/resolv.conf aanpassen zodat hij eerst /etc/hosts gaat bekijken en je probleem is waarschijnlijk opgelost.

  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 11-01 23:32

Nvidiot

notepad!

Hoe moet je /etc/resolv.conf aanpassen zodat ie hosts eerst gebruikt ?

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


Verwijderd

hosts wordt standaard al als eerste gebruikt. Hiervoor zou je dus niets hoeven aan te passen. Ik zou gewoon je resolv.conf goed instellen dan moet het probleem ook zijn verholpen. Of de reverselookup van sshd disablen.

  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 11-01 23:32

Nvidiot

notepad!

Bij mij staat de reverse lookup uit in /etc/shh/sshd_config en hosts wordt voor zover ik weet nooit gebruikt voor reverse lookups. Toch zie ik altijd een reverse lookup wanneer ik inlog vanaf 192.168.0.3 naar 192.168.0.1. :(

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


  • serkoon
  • Registratie: April 2000
  • Niet online

serkoon

mekker.

Sinds OpenSSH privilege seperation gebruikt, moet je /etc/resolv.conf aanmaken binnen de chroot die sshd gebruikt. Onder Free is dat /var/empty.

Als die resolv.conf mist, gaat sshd proberen te resolven bij 127.0.0.1, waar met wat pech helemaal geen DNS-server op draait :)

  • blender
  • Registratie: Juni 2001
  • Niet online
serkoon schreef op 09 maart 2004 @ 21:24:
Sinds OpenSSH privilege seperation gebruikt, moet je /etc/resolv.conf aanmaken binnen de chroot die sshd gebruikt. Onder Free is dat /var/empty.

Als die resolv.conf mist, gaat sshd proberen te resolven bij 127.0.0.1, waar met wat pech helemaal geen DNS-server op draait :)
Een chrooted jail is wat anders dan privilege separation... ik draai OpenSSH hier op een OpenBSD bak en die is echt niet chrooted.

  • blaataaps
  • Registratie: Juli 2001
  • Niet online
blender schreef op 09 maart 2004 @ 23:09:
[...]

Een chrooted jail is wat anders dan privilege separation... ik draai OpenSSH hier op een OpenBSD bak en die is echt niet chrooted.
Ik kan me anders nog wel herinneren dat het bij de invoering van privsep zeker een issue was, en dat een /var/empty/etc/resolv.conf maken dat gewoon oploste. Bij latere versies van openssh en freebsd geen last meer van gehad, dus ik vermoed dat ze het opgelost hebben. Zie bijvoorbeeld ook http://lists.freebsd.org/...rity/2003-May/000290.html (overigens een mailtje van iemand die me erg bekend voorkomt ; )
This is becoming a FAQ. Current OpenSSH daemons implement a feature
called 'privilege seperation', which splits the daemon in two: one part
running as root, the other as user 'sshd' (or whatever you define),
minimalizing security threats. One disadvantage though: /etc/resolv.conf
is read AFTER chroot()ing to the directory '/var/empty' (talking about
OpenSSH in base). If resolv.conf can't be found there, sshd will lookup
IP's via 127.0.0.1, generating those log_in_vain messages you see.

How to solve? Well.. copy /etc/resolv.conf to /var/empty/etc/.

[ Voor 3% gewijzigd door blaataaps op 09-03-2004 23:19 ]


  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 11-01 23:32

Nvidiot

notepad!

Daar staat dat ie localhost gaat gebruiken als DNS server. Dat is niet wat er bij mij gebeurt. Bij mij vraagt ie aan de eerste nameserver uit /etc/resolv.conf welke hostname bij 192.168.0.3 hoort. En dat is nou net het probleem, als je verbinding eruit ligt moet je wachten totdat die poging mislukt.

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


  • arikkert
  • Registratie: Juli 2002
  • Laatst online: 17-02 12:23
/etc/nsswitch.conf, vroeger /etc/host.conf bepaalt de nameresolv volgorde.
als je nu gewoon paar dummy entries maakt voor de hosts die resolved moeten worden, dan zou resolv via dns (voor die hosts) niet meer nodig moeten zijn lijkt me.

  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 11-01 23:32

Nvidiot

notepad!

in host.conf staat al dat ie eerst /etc/hosts moet gebruiken en daarna bind. In /etc/hosts heb ik 192.168.0.3 desktop staan. Als ie dus reverse lookups zou doen via /etc/hosts zou dit moeten werken. Doet ie dus niet :( Iemand nog een briljant idee ?

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


  • silentsnake
  • Registratie: September 2003
  • Laatst online: 04-02 04:29
Ik moet op mijn bak de DNS server van Chello invullen anders doet SSH het bij mij helemaal niet, dus misschien is dat het proberen waard.

  • AVL
  • Registratie: Januari 2000
  • Laatst online: 25-09-2022

AVL

OHMSS

1) Zorg ervoor dat je /etc/hosts in ieder geval goede entries voor de lokale machine bevat:
code:
1
2
3
127.0.0.1     localhost localhost.my.domain
127.0.0.1     hostname hostname.my.domain
127.0.0.1     hostname.my.domain.

Achter de laatste regel staat een extra punt (.). Deze wordt gebruikt bij reverse lookups.
edit:
overbodig hoop ik, maar hostname dus vervangen door de output van 'hostname -s', en hostname.my.domain door de output van 'hostname'


2) Start sshd met de optie -u0 om waar mogelijk DNS lookups uit te schakelen. Dus in je /etc/rc.conf:
code:
1
2
sshd_enable="YES"
sshd_flags="-u0"


Zie sshd( 8 ) voor meer info.

[ Voor 18% gewijzigd door AVL op 10-03-2004 22:37 ]

"I'd rather have a bottle in front of me than a frontal lobotomy."

Pagina: 1