[Ubuntu] SSH/SFTP connection timed out poort 22

[Zoolander]

Ik heb een server (Ubuntu 9.04 met open-ssh) waarbij ik SSH en SFTP op poort 22 mogelijk heb gemaakt.
Vanaf locatie A (Putten) kom ik er prima in met SSH en SFTP.
Echter, vanaf locatie B (Utrecht) kom ik er niet in en dan krijg ik: "connection timed out"
Dat is dan in FileZilla, maar de terminal (OS X) zegt deze ongeveer hetzelfde.

Nu vermoed ik: het ligt niet aan mijn server maar aan de locatie.
Ik ben hier echter niet zeker van. De /var/log/auth.log geeft de andere locatie niet eens weer.
Dus hij kan de server gewoon niet vinden. Pingen lukt wel, maar SSH of SFTP dus niet.

Ik heb geprobeerd:
- UPnP aan te zetten op locatie B
- via IP adres te SSHen (user@ip-adres)
- /var/log/auth.log doorgespit
- gezocht naar blacklists op de server (niet gevonden, heb ik ook niet geinstalleerd)
- username's 10x over te tikken
- poorten in sshd_config aan te passen, maar dan kom ik er thuis ook niet meer in (wat ik raar vond)

Kan iemand zeggen of het inderdaad niet aan de server ligt ja of nee.
En wat ik bij ja of nee kan doen?

Enkel SSH conf regels:

code:

# What ports, IPs and protocols we listen for
Port 22 
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

UsePAM yes

Match group sftp
    ChrootDirectory /home/%u
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

[Sallin]

Het klinkt als een firewall probleem. Is locatie A misschien ook het lokale netwerk van je server? kijk eens met shields up of de poort uberhaupt open staat.

[ Voor 12% gewijzigd door Sallin op 03-02-2010 11:24 ]

[himlims_]

/etc/host allow/deny ? (was bij mij wel eens vaker de oorzaak)

[swbr]

Klinkt inderdaad alsof locatie B het verkeer naar poort 22 blocked. Mogelijke workaround is om je ssh server ook op poort 443 te laten luisteren (dus de regel 'Port 443' toevoegen onder de regel waar 'Port 22' staat), en dan op die spoort connecten. Meeste firewalls laten encrypted traffic over poort 443 wel toe.

[Zoolander]

Sallin schreef op woensdag 03 februari 2010 @ 11:22:
Het klinkt als een firewall probleem. Is locatie A misschien ook het lokale netwerk van je server? kijk eens met shields up of de poort uberhaupt open staat.

Nee, de server staat weer op locatie C (weet ik veel waar )
Ga even naar shields up kijken, maar kan je daar uitgaande poorten mee checken?

[Zoolander]

himlims_ schreef op woensdag 03 februari 2010 @ 11:26:
/etc/host allow/deny ? (was bij mij wel eens vaker de oorzaak)

Leeg bij mij (op #comments na)

[Zoolander]

Antaresje schreef op woensdag 03 februari 2010 @ 11:27:
Klinkt inderdaad alsof locatie B het verkeer naar poort 22 blocked. Mogelijke workaround is om je ssh server ook op poort 443 te laten luisteren (dus de regel 'Port 443' toevoegen onder de regel waar 'Port 22' staat), en dan op die spoort connecten. Meeste firewalls laten encrypted traffic over poort 443 wel toe.

Heb nu staan

code:

Port 22
Port 443

en dat werkt! Dus dank zo ver

Conflicteerd dit niet met SSL / https en Apache die hier op luisterd? Of is het zo omdat het SSH is
dat hij dat wel snapt en niet verward met een http request over SSL?

Kan ik niet beter een andere (algemene) poort kiezen, sowieso voor het algeme poort-scan verhaal op 22 en 443?

[ Voor 16% gewijzigd door Zoolander op 03-02-2010 11:37 ]

[JaQ]

Zoolander schreef op woensdag 03 februari 2010 @ 11:31:
Conflicteerd dit niet met SSL / https en Apache die hier op luisterd? Of is het zo omdat het SSH is
dat hij dat wel snapt en niet verward met een http request over SSL?

Als jij een apache op poort 443 wil draaien, dan heb je nu inderdaad een probleem. Kwestie van keuzes maken

Zoolander schreef op woensdag 03 februari 2010 @ 11:31:
Kan ik niet beter een andere (algemene) poort kiezen, sowieso voor het algeme poort-scan verhaal op 22 en 443?

De symptomen die je beschrijft suggereren dat op locatie B de uitgaande firewall bepaalde poorten blokkeert. Als je die niet zelf kan aanpassen zit je waarschijnlijk vast aan 80 en 443.

Overigens geloof ik niet in het draaien van daemons op obscure poorten, maar dat is een ander verhaal.

[Zoolander]

Shit. Moet ik die mensen gaan uitleggen dat het aan hun ligt en dan zeggen ze:
ja maar FTP lukt gewoon wel. Ja, maar dat is niet veilig...
Nu snap ik waarom alle hosters nog FTP aanbieden....

Andere poortsuggesties nog?

[JaQ]

Zoolander schreef op woensdag 03 februari 2010 @ 12:26:
Shit. Moet ik die mensen gaan uitleggen dat het aan hun ligt en dan zeggen ze:
ja maar FTP lukt gewoon wel. Ja, maar dat is niet veilig...

Is locatie A een school of een bedrijf? Zo ja, dan zal je echt met de firewall-beheerder van locatie A moeten praten. Je kan uiteraard ongelimiteerd poorten proberen, maar wil je dat wel?

Zoolander schreef op woensdag 03 februari 2010 @ 12:26:
Nu snap ik waarom alle hosters nog FTP aanbieden....

Waarom dan? De meeste afnemers van hoogwaardige ICT-diensten zijn niet in staat zijn om de gevolgen van gebruik van een dienst te doorgronden. Dat geldt zelfs voor professionals in de ict-sector.

[Orion84]

Zoolander schreef op woensdag 03 februari 2010 @ 12:26:
Shit. Moet ik die mensen gaan uitleggen dat het aan hun ligt en dan zeggen ze:
ja maar FTP lukt gewoon wel. Ja, maar dat is niet veilig...
Nu snap ik waarom alle hosters nog FTP aanbieden....

Andere poortsuggesties nog?

poort 21? Als jij toch geen FTP server hebt draaien omdat je het onveilig vindt, maar je vanaf dat netwerk wel over poort 21 naar buiten mag lijkt me dat een prima kandidaat?

[Zoolander]

JaQ schreef op woensdag 03 februari 2010 @ 12:37:
[...]

Is locatie A een school of een bedrijf? Zo ja, dan zal je echt met de firewall-beheerder van locatie A moeten praten. Je kan uiteraard ongelimiteerd poorten proberen, maar wil je dat wel?


[...]

Waarom dan? De meeste afnemers van hoogwaardige ICT-diensten zijn niet in staat zijn om de gevolgen van gebruik van een dienst te doorgronden. Dat geldt zelfs voor professionals in de ict-sector.

Omdat het gezeur opleverd en het hun niet kan schelen als het account gehacked wordt omdat FTP plain alles over de lijn stuurt, vermoed ik...

[swbr]

Zoolander schreef op woensdag 03 februari 2010 @ 12:26:
Shit. Moet ik die mensen gaan uitleggen dat het aan hun ligt en dan zeggen ze:
ja maar FTP lukt gewoon wel. Ja, maar dat is niet veilig...
Nu snap ik waarom alle hosters nog FTP aanbieden....

Andere poortsuggesties nog?

Als ftp wel mag, en je hebt daar genoeg aan, dan zet installeer je toch gewoon een ftp server? Zorg dat je met virtuele users werkt en chroot de deamon, en je bent al een heel eind op weg qua veiligheid. Tenzij de data die over het lijntje gaat ook niet te sniffen mag zijn.

[Zoolander]

Orion84 schreef op woensdag 03 februari 2010 @ 12:40:
[...]

poort 21? Als jij toch geen FTP server hebt draaien omdat je het onveilig vindt, maar je vanaf dat netwerk wel over poort 21 naar buiten mag lijkt me dat een prima kandidaat?

Dat accepteerd hij bij mij niet. Krijg ik ook connection timed out

[Zoolander]

Antaresje schreef op woensdag 03 februari 2010 @ 12:46:
[...]


Als ftp wel mag, en je hebt daar genoeg aan, dan zet installeer je toch gewoon een ftp server? Zorg dat je met virtuele users werkt en chroot de deamon, en je bent al een heel eind op weg qua veiligheid. Tenzij de data die over het lijntje gaat ook niet te sniffen mag zijn.

Als je bijvoorbeeld content aanbied die enkel op aanvraag te verkrijgen is maar omdat je FTP gebruikt dus feitelijk gewoon op straat ligt....
Heb zelf nog nooit FTP hack meegemaakt, maar weet dat het gevaar op de loer ligt.

[Orion84]

Zoolander schreef op woensdag 03 februari 2010 @ 12:48:
[...]


Dat accepteerd hij bij mij niet. Krijg ik ook connection timed out

Het zou natuurlijk kunnen dat de firewall waar je achter zit wat verder kijkt dan enkel de poort en daadwerkelijk alleen FTP verkeer toestaat op poort 21. Dan gaat het inderdaad niet werken.

[Zoolander]

Ik vraag me af hoe andere hosters dat doen die geen FTP willen.
Ik dacht altijd dat FTP verleden tijd zou worden vanwege de plain-text verbindingen.
Maar ik heb het nu op 3 andere locaties getest: ook port 22 niet beschikbaar.
Lijkt standaard een probleem te zijn voor de meeste thuis-locaties.

Wat vinden jullie daar van dan?

[Orion84]

Ik weet niet wat voor situaties jij precies getest hebt en hoe je precies aan het testen bent, maar ik ken eigenlijk geen enkele thuissituatie waar je niet via poort 22 een server op het internet kan benaderen.

De enige plekken waar ik zo'n strenge firewall zou verwachten zijn scholen en bedrijven? Maar zelfs daar zal poort 22 echt niet een van de eerste dingen zijn die een beheerder op slot gooit lijkt me?

Verder gebruiken de meeste hosters denk ik nog gewoon FTP? Zo dramatisch is het ook allemaal niet. Ja, je passwords gaan plaintext over het netwerk, maar de kans dat een password wordt onderschept door een virus (keylogger oid) is vele maten groter dan dat iemand het voor elkaar krijgt om jouw netwerkverbinding te sniffen. Zo triviaal is dat namelijk helemaal niet.
Daarnaast is het maar de vraag of hosters zulke grote problemen ondervinden als er eens een FTP account "gekraakt" wordt.

[ Voor 50% gewijzigd door Orion84 op 03-02-2010 16:40 ]

[Zoolander]

Maar suggereer je dan dat het wel aan mijn server ligt, of dat ik gewoon 4x pech heb gehad met mensen die mijn server niet kondern bereiken op poort 22 en wel op 443?

toch aan mijn kant zoeken?

[Orion84]

Geef in elk geval even aan hoe je dat precies hebt getest, of plaats hier wat gegevens zodat wij het ook eens kunnen proberen

[gertvdijk]

Nee op jouw server is poort 22 gewoon open. Als jij vanaf een bepaalde locatie niet kan verbinden daarop en op andere wel is het toch duidelijk dat het ligt aan die locatie waar blijkbaar poort 22 uitgaand dichtstaat?

[TwOkkie]

Even een concrete vraag: Kun je vanaf locatie B (Utrecht) wel bij andere ssh-servers komen? Je zou dit kunnen testen door bijvoorbeeld eens te connecten met shell.xs4all.nl. En nee, je krijgt m'n wachtwoord niet. ;-)

Ik heb eens een "vreemd firewallprobleem" opgelost waarbij een bepaalde applicatie geen mail kon versturen. De uitgaande firewall had een voor mij en mijn collega's onbekende web-interface en we zochten het probleem dan ook daar. Waarom kon de ene PC nou wel SMTP uitgaand doen en de andere niet? Bleek uiteindelijk een overijverige virusscanner op die ene PC te zijn die stilletjes voorkwam dat Apllicatie.EXE uitgaande connecties maakt naar poort 25. Het zou maar een spambot kunnen zijn, he.

Moraal van dit verhaal: onderzoek iedere stap in de keten.

[ Voor 56% gewijzigd door TwOkkie op 04-02-2010 10:46 ]

[Zoolander]

TwOkkie schreef op donderdag 04 februari 2010 @ 10:42:
Even een concrete vraag: Kun je vanaf locatie B (Utrecht) wel bij andere ssh-servers komen? Je zou dit kunnen testen door bijvoorbeeld eens te connecten met shell.xs4all.nl. En nee, je krijgt m'n wachtwoord niet. ;-)

Ik heb eens een "vreemd firewallprobleem" opgelost waarbij een bepaalde applicatie geen mail kon versturen. De uitgaande firewall had een voor mij en mijn collega's onbekende web-interface en we zochten het probleem dan ook daar. Waarom kon de ene PC nou wel SMTP uitgaand doen en de andere niet? Bleek uiteindelijk een overijverige virusscanner op die ene PC te zijn die stilletjes voorkwam dat Apllicatie.EXE uitgaande connecties maakt naar poort 25. Het zou maar een spambot kunnen zijn, he.

Moraal van dit verhaal: onderzoek iedere stap in de keten.

Hee, dank daar voor.
Persoon kan WEL

code:

ssh shell.xs4all.nl

Maar NIET

code:

ssh username@domein

Krijgt deze een time-out op poort 22.

Ligt het dan toch aan mij? (ik hoop het)

[TwOkkie]

Dit:

code:

ssh shell.xs4all.nl

en dit:

code:

ssh username@domein

Is technisch gesproken precies hetzelfde. Het feit dat je user@ voor het domein zet, betekent alleen maar dat de naam alvast wordt doorgegeven op het moment dat de inlogfase begint.

Het is mij niet helemaal duidelijk wat je nu bedoelt. Lukt 'ssh domein' wel en 'ssh username@domein' niet? Dan vraag ik me af of je al wel een TCP-connectie krijgt, maar er in de inlogfase iets mis gaat. Je kan een hoop zien door 'ssh -v username@domein' te doen. Je kan dan zien waar die blijft hangen.

Als je bedoelt dat ssh naar xs4all wel, maar naar putten niet lukt, dan kun je nu stellen dat er in principe niks mis is met de machine in utrecht, tenzij deze iets speciaals doet om naar Putten te routeren. Zit er een VPN tussen, bijvoorbeeld? Heb je nog meer informatie die van belang kan zijn?

Edit: ik zie nu dat de server niet in Putten staat. Waar staat deze wel, en van waaruit test je deze commando's? Kun je wel andere services van 'de server' bereiken vanuit de plek waar je ssh probeert?

[ Voor 10% gewijzigd door TwOkkie op 05-02-2010 09:59 . Reden: startpost nog een keer gelezen ]

[Zoolander]

TwOkkie schreef op vrijdag 05 februari 2010 @ 09:55:
Dit:

code:

ssh shell.xs4all.nl

en dit:

code:

ssh username@domein

Is technisch gesproken precies hetzelfde. Het feit dat je user@ voor het domein zet, betekent alleen maar dat de naam alvast wordt doorgegeven op het moment dat de inlogfase begint.

......

Ik zet mijn domeinnaam hier niet omdat ik dat veiliger vind... misschien onzinnig. Maar in ieder geval:

code:

ssh shell.xs4all.nl

vraagt om password netjes vanuit Utrecht

code:

ssh mijndomein.nl

geeft timed out over poort 22.

Dus er zit iets bij mij toch niet goed denk ik, ondanks dat ik WEL over poort 22 kan connecten.
Toch?

De server van mijndomein.nl staat ergens gehost gewoon. Die hebben standaard geen firewall aan staan.
(het is een VPS)

[swbr]

Zoolander schreef op vrijdag 05 februari 2010 @ 15:14:
[...]


Ik zet mijn domeinnaam hier niet omdat ik dat veiliger vind... misschien onzinnig. Maar in ieder geval:

code:

ssh shell.xs4all.nl

vraagt om password netjes vanuit Utrecht

code:

ssh mijndomein.nl

geeft timed out over poort 22.

Dus er zit iets bij mij toch niet goed denk ik, ondanks dat ik WEL over poort 22 kan connecten.
Toch?

De server van mijndomein.nl staat ergens gehost gewoon. Die hebben standaard geen firewall aan staan.
(het is een VPS)

Wat is dat voor lokatie waarvan je dat probeert? Bedrijf, school, iets anders?

Het kan natuurlijk zijn dat er een netwerk admin zit met een xs4all account die voor zichzelf een uitzondering heeft gemaakt

[Orion84]

Probeer eens of je vanaf die locatie(s) die problemen geeft/geven wel verbinding met home.orion84.nl kan maken?

En mocht je iemand anders willen laten testen, zet dan even Direct messages aan in je forumvoorkeuren, dan kan je iemand achter de schermen even de domeinnaam geven om eens te testen.

[TwOkkie]

Even samenvattend omdat ik wat vragen stelde die eerder al beantwoord waren:

A = Putten thuis, B = Utrecht op je werk, C = Virtuele server bij Ergens Inc.

1) A -> C:22 werkt.
2) B -> C:22 werkt niet
3) B -> C:443 werkt wel
4) B -> xs4all:22 werkt wel

Uit 1 kun je afleiden dat connecties naar 22 goed gaan. 2 is je probleem. 3 zegt dat de routering in ieder geval goed is en 4 zegt dat er aan de kant van B geen uitgaande filtering op poort 22 is. Of er is inderdaad een uitzondering gemaakt voor xs4all. Anders zou ik toch eens kijken of de hoster van je domain misschien ssh alleen toestaat vanaf IP's die jij als bonafide beheerder hebt opgegeven.

[Zoolander]

TwOkkie schreef op vrijdag 05 februari 2010 @ 18:34:
Even samenvattend omdat ik wat vragen stelde die eerder al beantwoord waren:

A = Putten thuis, B = Utrecht op je werk, C = Virtuele server bij Ergens Inc.

1) A -> C:22 werkt.
2) B -> C:22 werkt niet
3) B -> C:443 werkt wel
4) B -> xs4all:22 werkt wel

Uit 1 kun je afleiden dat connecties naar 22 goed gaan. 2 is je probleem. 3 zegt dat de routering in ieder geval goed is en 4 zegt dat er aan de kant van B geen uitgaande filtering op poort 22 is. Of er is inderdaad een uitzondering gemaakt voor xs4all. Anders zou ik toch eens kijken of de hoster van je domain misschien ssh alleen toestaat vanaf IP's die jij als bonafide beheerder hebt opgegeven.

Het is het laatste. Er was inderdaad een firewall ingesteld op mijn IP adres alleen. Dat niemand het lukte behalve ik vond ik al zo raar. Gewoon een rule die mijn IP toestond, rest niet.

Super bedankt voor de hulp, dankzij de testjes kon ik achterhalen wat het probleem was.
Nog niet zo goed in linux dus.... maar snel lerdend op het moment.

Topic closed wat mij betreft.