[FreeBSD 5.3] Connecten met SSH traag (zelfde subnet)

[CmdrKeen]

Hallo Probleempje met een verse install van FreeBSD 5.3 dat ik normaal *niet* heb met dit OS: als ik een connectie via SSH naar de server maak (vanuit hetzelfde subnet, machines zitten fysiek aan dezelfde switch) dan duurt het heel erg lang voordat er een connectie is. Twee minuten voordat er überhaupt een verbinding is en dan nog eens twee minuten voordat er om een pwd gevraagd wordt. Daarna nog zoiets voordat ik een command prompt krijg en dan is de verbinding op normale snelheid.

Het schijnt dat meer mensen dit probleem hebben gehad. Naar aanleiding van diverse probleembeschrijvingen en antwoorden hierop heb ik de volgende dingen geprobeerd:

- op de FreeBSD-server in het bestand /etc/hosts deze regels toegevoegd:

code:

# deze entry bestond al
127.0.0.1 localhost
192.168.66.105 MijnClient
192.168.66.108 FreeBsdServer

(Waarbij MijnClient en FreeBsdServer natuurlijk hun respectievelijke namen zijn.)

- op de Windows XP Pro-client in het bestand c:\windows\system32\drivers\etc\hosts. dezelfde regels als hierboven toegevoegd (je weet maar nooit)

- op de FreeBSD-server in het bestand /etc/hosts.allow gecontroleerd dat ALLOW : ALLOW : ALL stond (dat stond er)

- alternatieve SSH-clients op de client geprobeerd (PuTTY 0.57 en OpenSSH 3.8.1p1)

- fysieke netwerkconfig aangepast: eerst liep de verbinding door diverse switches en gedeeltelijk draadloos, nu zijn beide machines fysiek op dezelfde swicth aangesloten.

Fysieke netwerkproblemen sluit ik uit omdat de verbinding uiteindelijk wel tot stand komt op normale snelheid, alleen bij het tot stand brengen van een SSH-verbinding duurt het erg lang. Een ping komt gewoon in minder dan 1ms terug en tijdens de SSH-sessie is er niets aan de hand. Beide clients kunnen lokaal overal bij en op het internet, geen probleem. Het probleem verandert niet en is dus reproduceerbaar - een tijdelijke "dip" in het netwerk (je weet het maar niet) is het blijkbaar ook niet.

Zoals gezegd heb ik op het net wel wat mensen met hetzelfde probleem gevonden, alleen helpen hun oplossingen mij niet. Is er misschien nog iets anders waar ik op moet letten?

[Paul]

Ondanks dat je je hosts-bestanden goed hebt gezet:
Waarop benader je hem? Hostname of ip? Als je de andere neemt, bestaat het probleem dan nog steeds?

[CmdrKeen]

Geprobeerd op hostname en op IP. In beide gevallen hetzelfde probleem.

[GrooV]

Heeft dit niet iets te maken dat de client zich moet authoriseren zelfs al voordat er een username komt? Misschien helpt het als je ff je firewall uitzet?

[CmdrKeen]

GrooV, als het een security-instelling zou zijn, dan zou de sessie toch gewoon helemaal niet tot stand moeten komen?

De firewall op mijn Windows XP-client heb ik (om te testen) uitgezet. De firewall op de FreeBSD-server staat aan maar ik neem aan (das gevaarlijk, dat weet ik) dat als iets door de firewall geblokkeerd wordt, het er niet twee minuten later alsnog door mag.

Dat de sessie uiteindelijk tot stand komt is er de reden van dat ik het niet in de security-hoek gezocht heb.

[stefklep]

Je dns instellingen staan ook allemaal goed enzo en gateway eventuweel ? Want ik heb daar wel eens probelemen mee gehad. Staat er voor de rest niks in je logs of dmesg ? Mischien kan je een stukje uit je rc.conf geven van je netwerk config en je sshd config.

[ Voor 21% gewijzigd door stefklep op 26-03-2005 16:50 ]

[CmdrKeen]

Ok.. jullie vragen nogal wat. Ik heb wel wat met FreeBSD gedaan maar dit kost me toch wel enige moeite. Ik ga mijn best doen om alles te beantwoorden.

De firewall staat compleet verkeerd geconfigd (totaal verkeerde IP-ranges, enz.). De FreeBSD-machien is echter geen gateway en zoals gezegd: de SSH-sessie wordt *wel* gewoon tot stand gebracht. Hoewel ik niet helemaal zeker weet of dit problemen geeft, vermoed ik dat dit wel in orde is. Op andere FreeBSD-installaties (zelfde versie) werkte het in ieder geval altijd zonder problemen.

DNS is ingesteld op het DNS-adres van mijn ISP. Dit lijkt me de enige juiste instelling aangezien ik zelf geen DNS draai. /etc/hosts bevat de namen en adressen van mijn netwerkclients.

Gateway is goed ingesteld want ik heb wel internettoegang. Dit lijkt me niet relevant want de SSH-server en -client zitten in hetzelfde subnet en fysiek aan dezelfde switch.

Dit staat in /etc/rc.conf:

code:

defaultrouter="192.168.66.1"
hostname="bones.huijgen"
ifconfig_fxp0="inet 192.168.66.108  netmask 255.255.255.0"
linux_enable="YES"
saver="logo"
sshd_enable="YES"
usbd_enable="YES"
saver="daemon"
moused_enable="YES"

Wat wil je precies weten van de netwerkconfig? Fysiek of logisch? Fysiek: gewoon kabeltjes naar een switch en een hardwarerouter Logisch: subnet = 255.255.255.0, ip's staan hierboven. DNS-adressen zijn van ISP XS4ALL; in het netwerk is wel een Windows 2000-server maar die draait geen Active Directory dus geen DNS. "huijgen" is de naam van mijn werkgroep.

In /etc/ssh/sshd_config staat alleen Subsystem sftp /usr/libexec/sftp-server, de rest is allemaal uitgecommentarieerd.

Deze config is allemaal standaard. Het enige dat ik na installatie veranderd heb, is dat ik USB aan heb gezet en het netwerk heb geconfigged.

Waar vind ik ook alweer logs en dmesg? Ik ga het ondertussen wel even opzoeken trouwens. Ik post het zo, als ik het gevonden heb

/Edit:
Logs en dmesg gevonden Welke logfile moet ik precies in kijken? Ik heb in een paar zitten neuzen maar ik vind eigenlijk niets dat met ssh te maken heeft. Ik heb de logs eruit gepikt die het laatst gewijzigd zijn.

Dmesg laat enkel dingen over hardware zien (welke cardbus, ACPI, monitor-info, enz). Geen foutmeldingen o.i.d..

[ Voor 17% gewijzigd door CmdrKeen op 26-03-2005 18:40 ]

[CmdrKeen]

Enkele dagen later...

Ik heb de server inmiddels opnieuw geïnstalleerd. Weer de eerdergenoemde dingen aangepast (/etc/host e.d.) en het probleem bestaat alweer/nog steeds. Soms krijg ik zelfs een timeout bij SSH. FreeBSD zegt dan dat er een time-out vóór authenticatie is opgetreden (kan ff de precieze melding niet meer vinden).

Deze melding heb ik met Google opgezocht en ik kom uit bij dezelfde oplossingen als voor alleen de trage connectie.

Ik ben een beetje door m'n opties heen, dus maar een trap naar boven (m'n eerste en laatste trap hoor ).

/Edit:
De precieze foutmelding is:
sshd[523]: fatal: Timeout before authentication for 192.168.66.103

Dat IP is het IP van m'n client.

[ Voor 15% gewijzigd door CmdrKeen op 02-04-2005 22:17 ]

[Verwijderd]

De traagheid heb ik ook last van gehad met onze nieuwste server, eerste server met FreeBSD 5.3.. Ook 4.11 heeft dit gehad maar lostte zichzelf op, nu met 5.3 na een re-install ook opgelost.

Het lijkt wel gelukschieten, na een paar keer reinstalleren werkt het ineens.

[serkoon]

Meestal is het gewoon een DNS-issue aan de serverkant, zowel je forward- als reverse mapping moet resolven of iig niet timeouten. Alleen een forwardmapping maken dmv een hosts file heeft dus wat betreft de reverse weinig zin.

[CmdrKeen]

Serkoon, ik begrijp wat je bedoelt maar ik zit in een LAN (zelfde subnet, zelfde switch) en draai geen DNS. Geeneens WINS. Er staan vier computers in dit netwerk. De DNS-server die ik op FreeBSD heb ingesteld, is die van m'n ISP. Daar kan ik dus geen reverse mappings maken

Het gekke is dat eerdere installs *wel* snel SSH-toegang gaven!

Denk je dat ik lokaal DNS moet gaan draaien om dit probleem op te lossen?

[Verwijderd]

Je zou kunnen proberen Bind9 te installeren e.d.

Dit was bij ons niet het probleem maar proberen kan altijd.

[TrailBlazer]

post eens de inhoud van /etc/resolv.conf (is een wilde gok gen freebsd totaal niet) maar als je daar in de volgorde eerst DNS en dan files staat kna je hostfiles aanpassen tot je een ons weeg denk ik

[serkoon]

Vilenin schreef op zondag 03 april 2005 @ 08:26:
Serkoon, ik begrijp wat je bedoelt maar ik zit in een LAN (zelfde subnet, zelfde switch) en draai geen DNS. Geeneens WINS. Er staan vier computers in dit netwerk. De DNS-server die ik op FreeBSD heb ingesteld, is die van m'n ISP. Daar kan ik dus geen reverse mappings maken

Nouja, een reverse mapping maken hoeft ook niet per se, als DNS maar niet timeout hoeft te gaan. Je zou nog kunnen proberen eens wat te resolven op de nameservers van je ISP. Soms wil het wel eens gebeuren dat de bovenste in je resolv.conf niet meer werkt en je dus alsnog gezeik krijgt (uitgaande van meerdere nameservers, dus).

Andere opties zijn met truss, ktrace, strace of misschien zelfs ltrace te gaan kijken wat je sshd proces doet op het moment dat je inlogt. Misschien dat je daar iets uit kunt destilleren.

[begintmeta]

je kunt ook de client met -vv verbose output laten geven, misschien geeft dat nog wat aanwijzingen over de communicatie vanuit de client.

[smokalot]

om erachter te komen of het aan je server of aan je client ligt zou je een andere client kunnen proberen, een andere machine, of een knoppix-cd ofzo.

[Verwijderd]

En je kan ook tcpdump laten lopen op de server om te zien wat er qua netwerkverkeer gebeurt en op welk gedeelte van de login gestopt wordt.

[AVL]

Maak in je /etc/hosts ook eens reverse mappings aan, dus met een punt erachter:

code:

192.168.0.1 mijnserver.domain.com mijnserver
192.168.0.1 mijnserver.domain.com.
192.168.0.2 client.domain.com client
192.168.0.2 client.domain.com.

Als dat niet werkt, start ssh eens met de optie '-u0', zodat er geen reverse DNS mapping wordt geprobeerd. Vanaf de prompt:

code:

# killall sshd
# sshd -u0

Of in je /etc/rc.conf:

code:

sshd_flags="-u0"

[avatar]

kijk maar eens goed naar je firewall rules. Die waren bij mij (FreeBSD 5.3 met PF) de boosdoener

[Surfer]

Ik lees in je startpost dat je het ook met PuTTY kunt proberen? Wat je dan even kunt doen is connecten naar die machine, helemaal inloggen en dan met je rechtermuisknop op het PuTTY menubalkje klikken en "Event Log" kiezen. Daar kun je zien welk stapje van het inloggen niet goed gaat.

Het zou trouwens best kunnen zijn dat er iets mis is met je firewall instellingen, maar dat ie alsnog doorgaat hoor. Hij kan bijvoorbeeld geen reverse lookup doen, maar in de sshd_config staat dat ie dan alsnog door mag gaan, dat soort dingen...

[Verwijderd]

Wat staat er in /etc/nsswitch.conf (Als die bestaat op FreeBSD).
In ieder geval staat daarin op een hoop *nix systemen de volgorde van bv hostname lookups...
In jou geval zou daar het volgende tenminste in moeten staan:
hosts: files [NOTFOUND=continue] dns
Dit hoeft niet het probleem te zijn maar het zou kunnen..
Iets in /etc/hosts zetten wil niet zeggen dat dat altijd geldt...
Als de machine eerst bij dns gaat opzoeken kan dat altijd lang duren...
Tevens zou /etc/resolv.conf een probleem zijn...
Als daar een foute dns server instaat? of een domain?

[CmdrKeen]

Iedereen bedankt voor de reacties. Jammergenoeg heb ik de laatste tijd niet veel tijd gehad om te testen aangezien ik aan het verbouwen ben. Ik heb toch het e.e.a. tussendoor kunnen doen, hier zijn de resultaten.

TrailBlazer schreef op zondag 03 april 2005 @ 10:12:
post eens de inhoud van /etc/resolv.conf (is een wilde gok gen freebsd totaal niet) maar als je daar in de volgorde eerst DNS en dan files staat kna je hostfiles aanpassen tot je een ons weeg denk ik

/etc/resolv.conf:
hosts
nameserver 194.109.104104
nameserver 194.109.9.99
nameserver 194.109.6.66

smokalot schreef op zondag 03 april 2005 @ 13:55:
om erachter te komen of het aan je server of aan je client ligt zou je een andere client kunnen proberen, een andere machine, of een knoppix-cd ofzo.

Gedaan. Compleet nieuwe installatie op m'n werk met een andere server. FreeBSD 5.4, zelfde symptonen.

SrFr schreef op maandag 04 april 2005 @ 09:19:
Ik lees in je startpost dat je het ook met PuTTY kunt proberen? Wat je dan even kunt doen is connecten naar die machine, helemaal inloggen en dan met je rechtermuisknop op het PuTTY menubalkje klikken en "Event Log" kiezen. Daar kun je zien welk stapje van het inloggen niet goed gaat.

2005-04-08 14:50:39 Looking up host "10.0.0.69"
2005-04-08 14:50:39 Connecting to 10.0.0.69 port 22
2005-04-08 14:51:00 Failed to connect to 10.0.0.69: Network error: Connection timed out
2005-04-08 14:51:00 Network error: Connection timed out

Verwijderd schreef op maandag 04 april 2005 @ 09:34:
Wat staat er in /etc/nsswitch.conf (Als die bestaat op FreeBSD).
In ieder geval staat daarin op een hoop *nix systemen de volgorde van bv hostname lookups...
In jou geval zou daar het volgende tenminste in moeten staan:
hosts: files [NOTFOUND=continue] dns
Dit hoeft niet het probleem te zijn maar het zou kunnen..
Iets in /etc/hosts zetten wil niet zeggen dat dat altijd geldt...
Als de machine eerst bij dns gaat opzoeken kan dat altijd lang duren...
Tevens zou /etc/resolv.conf een probleem zijn...
Als daar een foute dns server instaat? of een domain?

/etc/nsswitch.conf aangepast naar wat je zegt. Dat heeft alleen jammergenoeg geen resultaat.

Ik ga nu de rest van de suggesties proberen, waar ik niet zo 1-2-3 uitkom, met het FreeBSD-handbook in de hand..

/edit
Ok, die firewall, allemaal leuk en aardig, maar die filtert voornamelijk subnetoverschrijdend verkeer. Ik connect vanuit hetzelfde subnet en heb dus vrijwel niet met de firewall te maken. Ik heb 'm nu goed geconfigged, maar hij is nog steeds niet actief - want de machien is een client op het netwerk en geen gateway. Zou het dan nog steeds aan de firewall (/etc/rc.firewall) kunnen liggen?

[ Voor 8% gewijzigd door CmdrKeen op 08-04-2005 15:39 ]