SSH sessie verbroken?

[CrankyGamerOG]

Heren,

Ik heb thuis een server staan achter een 20mbit lijn van Tele2 (10mbit effectief).
Als ik vanaf ergens anders inlog op mijn server middels ssh, dan gaat dit gewoon zonder problemen.

Echter tijdens de verbinding als ik iets paste in de shell dan "hangt" de verbinding en na een tijdje loop ik tegen een (helaas consequente) time-out aan.

Iemand enig idee of dit aan instellingen ligt op mijn linux server, of dat dit gewoon het nadeel is van de lage upstream snelheid van Tele2?

[Matis]

Het kan te maken hebben met de buffergrootte van je ssh-client en/of ssh-server (hoogstwaarschijnlijk je client). Daarnaast kunnen hoge pingtijden er voor zorgen dat de client-server-communicatie te lang doet over de reactie en daardoor dus een timeout geeft.

[CrankyGamerOG]

ping tijden zijn het imho niet ,althans ze zijn niet schrikbarend hoog.

code:

64 bytes from thuis: icmp_seq=4 ttl=56 time=43.991 ms
64 bytes from thuis: icmp_seq=5 ttl=56 time=43.061 ms
64 bytes from thuis: icmp_seq=6 ttl=56 time=71.065 ms
64 bytes from thuis: icmp_seq=7 ttl=56 time=84.100 ms

Het is zelfs zo erg dat ik niet eens bijvoorbeeld niet eens /etc/ssh/ssh_config kan openen


edit :

Op mijn Macbook het volgende veranderen werkt al iets beter

in /ets/ssh_config

ServerAliveInterval 5 naar 2 gezet.

edit 2 : helaas werkt het dus niet beter

[ Voor 31% gewijzigd door CrankyGamerOG op 17-12-2010 10:27 ]

[Wolfboy]

Er zit niet iets van een traffic shaper ertussen die bursts tot een bepaalde hoeveelheid toelaat en daarna dropt?

Dit klinkt mij iig als het werk van overactieve shaping

[CrankyGamerOG]

Hmmm Wolfboy als je weer mij een oplossing aandraagt ben je vanaf heden mijn held !

Ik zal eens gaan rond kijken op de server, want er word wel aan shaping gedaan idd.


Edit :

Blijkbaar heb ik dit toch niet meer aanstaan ,en is dat het probleem dus ook niet

Even een situatie schets

code:

Tele2Modem ------> Linux server ------> switch ------ rest van netwerk.

Ik connect dus als volgt

code:

Ik ------> Tele2Modem -----> Linux server

Aangezien het Davolink modem geen bridging aankan, heb ik het ip van de linux server(192.168.1.6) als DMZ in de router(Davolink) gezet.
De Davolink doet GEEN DHCP of andere dingen, hij forward puur alles naar de server.
De server doet de routering op het netwerk.

[ Voor 62% gewijzigd door CrankyGamerOG op 17-12-2010 10:47 ]

[Verwijderd]

Aan gezien de IP van de Linux Server een 192.168.*.* is, neem ik aan dat je Linux Server lokaal (= thuis) staat?
En ik neem aan dat je extern PuTTY gebruikt?
Daar heb ik ook problemen mee op school en op het werk, maar als ik een Linux Live CD erin doe, en daar de Terminal opstart (of thuis in de Terminal), heb ik onbeperkt verbinding.

Aangezien dit bij mij alleen met PuTTY zo is, raad ik je aan om de Terminal op je Macbook eens te proberen, en dan zie je dat het niet bij zowel Tele2, als je server ligt.

PS: Ik weet dat je begon met "Heren", maar ik wou ook een beetje kunnen helpen.

[CrankyGamerOG]

Ik gebruik geen Putty, maar de lokale terminal van mijn Macbook idd
Dus dat kan het probleem ook niet zijn, ik heb zelfs bij de client side config (dus /etc/ssh_config) ServerAliveInterval van 5 naar 2 gezet.
Ook dit helpt helaas niks.

Kan het niet zijn dat mijn Tele2 lijn te weinig upspeed heeft om de sessie open te houden?
(wat ik dan vreemd vind want dan zou ik ook niet lagfree moeten kunnen gamen online e.d.)


De server staat bij mij thuis in mijn netwerk, de server fungeert als router/gateway voor mijn lan.


PS : Ook vrouwen mogen wel reageren hoor , ben alleen niet gewend dat vrouwen verstand hebben van terminals,shell,etc.

[ Voor 8% gewijzigd door CrankyGamerOG op 17-12-2010 14:04 ]

[Verwijderd]

>>Def!ance
Wel raar dan dat het bij jou niet doet.
Ik zou kunnen zeggen:
1. Ga naar een kennis of zo (die bij een andere provider zit), en test daar je SSH verbinding.
2. Als je nog tot een andere server toegang hebt, die niet bij jou thuis staat, test die dan als je thuis bent.

Resultaat: Werkt het nu wel goed?
* 1 = Ja.
* 2 = Nee.
Conclussie: Ligt aan je server (configuratie).

* 1 = Nee.
* 2 = Ja.
Conclussie: Ligt aan Tele2 (mogelijk laat die geen servers toe).

Overige resultaten maken het nog meer een raadsel.

PS: Als computers sinds mijn 7de een van mijn grootste hobbies zijn, dan kun je zelfs als vrouw er veel over weten.

[ Voor 1% gewijzigd door Verwijderd op 17-12-2010 15:04 . Reden: Even snel "Oplossing" in "Conclussie" veranderd. ]

[Wolfboy]

Def!ance: kan je misschien eens proberen ssh op een andere (niet-standaard) poort te draaien?

Probeer bijvoorbeeld 443 eens, de meeste internet providers filteren daar in ieder geval niet op

offtopic:
@YamiHoshi.nl: altijd leuk om te zien dat vrouwen zich ook in de shell durven te begeven
PS: conclusie heeft maar 1 s

[0xDEADBEEF]

Wellicht wordt je wat wijzer als je in plaats van "ssh", "ssh -v" gebruikt:

http://www.openbsd.org/cg...n.cgi?query=ssh&sektion=1

-v Verbose mode. Causes ssh to print debugging messages about its
progress. This is helpful in debugging connection,
authentication, and configuration problems. Multiple -v options
increase the verbosity. The maximum is 3.

[blaataaps]

MTU-problemen al uitgesloten?

[CrankyGamerOG]

0xDEADBEEF schreef op vrijdag 17 december 2010 @ 18:20:
Wellicht wordt je wat wijzer als je in plaats van "ssh", "ssh -v" gebruikt:

http://www.openbsd.org/cg...n.cgi?query=ssh&sektion=1

[...]

Damn , waarom heb ik daar zelf niet aan gedacht.
thnx!

blaataaps schreef op vrijdag 17 december 2010 @ 19:19:
MTU-problemen al uitgesloten?

explain plz?


edit :

Ik zie dat ik trouwens nergens gemeld heb dat ik het probleem lokaal niet heb.
(in mijn eigen netwerk dus).
Dus het is alleen vanaf buiten naar binnen.

[ Voor 149% gewijzigd door CrankyGamerOG op 17-12-2010 19:42 ]

[H!GHGuY]

blaataaps schreef op vrijdag 17 december 2010 @ 19:19:
MTU-problemen al uitgesloten?

Was ook het eerste wat ik dacht.

Zolang je kleine hoeveelheden data verscheept gaat alles goed. Vanaf dat de data in hoeveelheden groter dan de MTU verzonden wordt is het gedaan met de connectie.

Kijk dus even MTU's en bijhorende settings voor jumbo packets en andere na.

[jurp5]

Dit probleem heeft waarschijnlijk iets te maken met de KeepAlive instellingen van je SSH-server en/of client

http://www.brandonhutchin..._ClientAliveInterval.html

en er is ook nog een instelling die heet 'TCPKeepAlive'

Edit: Schijnbaar is die optie niet zo slim: http://fredericiana.com/2...connecting-automatically/

Dit loste voor mij altijd de problemen op

[ Voor 19% gewijzigd door jurp5 op 19-12-2010 21:30 ]

[CrankyGamerOG]

jurp5 schreef op zondag 19 december 2010 @ 21:28:
Dit probleem heeft waarschijnlijk iets te maken met de KeepAlive instellingen van je SSH-server en/of client

http://www.brandonhutchin..._ClientAliveInterval.html

en er is ook nog een instelling die heet 'TCPKeepAlive'

Edit: Schijnbaar is die optie niet zo slim: http://fredericiana.com/2...connecting-automatically/

Dit loste voor mij altijd de problemen op

Dankje, maar dit kan het niet zijn
Het probleem is niet dat ik tegen een timeout aanloop na lang niks doen namelijk als je goed had gelezen.
De connectie blijft netjes opent *totdat* ik veel data(relatief weinig nog) verstuur naar de ssh sessie.
Dan dropt de verbinding en timed out.

H!GHGuY schreef op vrijdag 17 december 2010 @ 20:06:
[...]


Was ook het eerste wat ik dacht.

Zolang je kleine hoeveelheden data verscheept gaat alles goed. Vanaf dat de data in hoeveelheden groter dan de MTU verzonden wordt is het gedaan met de connectie.

Kijk dus even MTU's en bijhorende settings voor jumbo packets en andere na.

Waar zou ik dit moeten zoeken, op de server , op het modem? nergens heb ik namelijk jumboframes noch een hogere MTU ingesteld staan.

[ Voor 24% gewijzigd door CrankyGamerOG op 20-12-2010 10:22 ]

[Verwijderd]

CrankyGamerOG schreef op maandag 20 december 2010 @ 10:21:

Waar zou ik dit moeten zoeken, op de server , op het modem? nergens heb ik namelijk jumboframes noch een hogere MTU ingesteld staan.

Op je server op 2 manieren:

code:

/sbin/ifconfig eth0 mtu 1492

en om vast te zetten:

code:

iface eth0 inet static
                address 192.168.1.***
                netmask 255.255.255.0
                network 192.168.1.1
                broadcast 192.168.1.***
                gateway 192.168.1.1
                mtu 1492

Hoop dat je er iets aan hebt!

[CrankyGamerOG]

Ik heb even met tcpdump (op mijn macbook) een dump gemaakt om te zien wat er gebeurt op het moment dat de verbinding wegvalt.
Ik word er alleen helaas niet wijs uit

code:

11:19:22.263240 IP XxXXXXX.ssh > 10.0.0.224.60549: Flags [.], ack 3270, win 95, options [nop,nop,TS val 228876036 ecr 119803915], length 0
11:19:23.219793 IP 10.0.0.224.60549 > XXx.XXX.XXX.XXX.ssh: Flags [F.], seq 3270, ack 3517, win 65535, options [nop,nop,TS val 119803925 ecr 228872989,nop,nop,sack 1 {4965:5021}], length 0
11:19:23.303649 IP XX.XX.XX.XX.ssh > 10.0.0.224.60549: Flags [.], ack 3271, win 95, options [nop,nop,TS val 228877077 ecr 119803925], length 0
11:19:23.303711 IP 10.0.0.224.60549 > XX.XX.XX.XX.ssh: Flags [.], ack 3517, win 65535, options [nop,nop,TS val 119803925 ecr 228872989,nop,nop,sack 1 {4965:5021}], length 0
11:19:23.510066 IP XX.XX.XX.XX.ssh > 10.0.0.224.60549: Flags [FP.], seq 5021:5117, ack 3271, win 95, options [nop,nop,TS val 228877281 ecr 119803925], length 96
11:19:23.510127 IP 10.0.0.224.60549 > XX.XX.XX.XX.ssh: Flags [R], seq 1606236233, win 0, length 0

Waar xx.xx.xx.xx = mijn server ip

10.0.0.224 = niet lokaal bij de server, maar lokaal aan deze zijde.
(het ligt niet aan deze zijde, want ik kan overal normaal naartoe sshen behalve thuis)

Verwijderd schreef op maandag 20 december 2010 @ 11:06:
[...]

Op je server op 2 manieren:

code:

/sbin/ifconfig eth0 mtu 1492

en om vast te zetten:

code:

iface eth0 inet static
                address 192.168.1.***
                netmask 255.255.255.0
                network 192.168.1.1
                broadcast 192.168.1.***
                gateway 192.168.1.1
                mtu 1492

Hoop dat je er iets aan hebt!

Zoals ik al zei, ik heb overal standaard MTU waarden (vziw 1500)
Dus dat kan het niet zijn

[ Voor 30% gewijzigd door CrankyGamerOG op 20-12-2010 11:40 ]

[pkwarts]

Ik heb niet helemaal thuis in netwerken, maar de window size van je server is niet erg groot (95bytes). Probeer eens een ping met een hogere packet size? (ping -s <bytes>)

[CrankyGamerOG]

pkwarts schreef op maandag 20 december 2010 @ 12:43:
Ik heb niet helemaal thuis in netwerken, maar de window size van je server is niet erg groot (95bytes). Probeer eens een ping met een hogere packet size? (ping -s <bytes>)

Ping gaat niks mis mee?
Ik kan zelfs blijven pingen als de timeout optreed, dus er is niks mis in principe met de route tussen mij en de server.

Helaas kan ik ook niet eens nu iets aapassen omdat ik niet eens een bestand kan openen (dan knalt de verbinding eruit).
Dus kan het ook niet testen helaas...

[ Voor 15% gewijzigd door CrankyGamerOG op 20-12-2010 13:34 ]

[deadinspace]

pkwarts schreef op maandag 20 december 2010 @ 12:43:
Ik heb niet helemaal thuis in netwerken, maar de window size van je server is niet erg groot (95bytes). Probeer eens een ping met een hogere packet size? (ping -s <bytes>)

95 betekent niet noodzakelijk 95 bytes, dankzij TCP window scaling. Maar dat is wel een interessant punt, want er waren wel eens issues met TCP window scaling en bepaalde routers, zie lwn.net/Artciles/92727/ .

Pingen met verschillende packetgroottes is een goed idee, dat kan ook helpen bij het vaststellen van MTU problemen

CrankyGamerOG schreef op maandag 20 december 2010 @ 13:25:
Ping gaat niks mis mee?

Hij zegt dan ook dat je moet proberen te pingen met verschillende packet sizes. Standaard pings zijn erg klein.

[Verwijderd]

deadinspace schreef op maandag 20 december 2010 @ 14:09:
Pingen met verschillende packetgroottes is een goed idee, dat kan ook helpen bij het vaststellen van MTU problemen

Mits je de -D* optie gebruikt, anders weet je nog steeds niet wanneer je tegen een afwijkende max MTU aanloopt.

En houd er rekening mee dat de ping size die je meegeeft alleen de payload betreft. Daar komen nog eens de ICMP header (8byte) en TCP header (20byte) boven op. Als je dus overal een MTU van 1500 hebt, kun je daar maximaal pings met een payload van 1472byte ongefragmenteerd overheen sturen.

*Set the Don't Fragment bit in the IP header. This can be used to determine the path MTU.

[ Voor 25% gewijzigd door Verwijderd op 21-12-2010 13:24 ]

[Verwijderd]

Als je op een lokaal netwerk met standaard configuratie geen problemen hebt, kan ik me voorstellen dat je provider je gewoon geen goede dienst wil verlenen of niet voldoende middelen heeft om dit te doen. Oplossing: schrijf een programma die om het filter van je provider heengaat of switch van ISP.

Je kunt ook contact opnemen met je ISP. Als ze geen antwoord kunnen geven, switch je ook van ISP. Sim-pel.

[CrankyGamerOG]

Ik heb als test de SSHD poort verplaatst van 22 naar 2222.
Het lijkt beter te gaan

@gang-ster bedankt iig alvast

[ Voor 8% gewijzigd door CrankyGamerOG op 22-12-2010 15:15 ]

[CAPSLOCK2000]

Ik zou even een klacht naar Tele2 sturen. Ik vermoed dat ze traffic-shaping doen en dat er iets fout gaat.
Het is niet geheel ongebruikelijk om poort 22 voorrang te geven over ander verkeer aangezien de sysadmin die poort nodig heeft als er problemen moeten worden opgelost.
Het lijkt er op dat Tele2 een foutje heeft gemaakt en poort 22 benadeelt.

[CrankyGamerOG]

Nah laat maar, dit is een bevredigende oplossing voor mij

En daarbij is het ook nog iets veiliger om ssh op een niet standaard poort te zetten.