Skip to main content

Ik gebruik mijn Raspberry Pi 4 als kleine webserver en dat werkt perfect. Als ik echter via SSH toegang wil moet ik steeds eerst de Pi opnieuw opstarten. Daarna kan ik gewoon via SSH mijn ding doen en alles werkt dan voor een dag of zo zoals verwacht. SSH is standaard bij opstart enabled en gestart, maar na een tijdje wordt volgens mij de toegang geblokkeerd. Tot twee maanden geleden zat ik bij T-Mobile op een ander type modem, en daar had ik (wat dit betreft) geen problemen, dus ik verwacht niet dat het aan de instellingen van de Pi ligt; daar heb ik sindsdien niet aan gezeten. Is het bekend of de Sagemcom F5359 een tijdlimiet heeft op SSH-verbindingen, en zo ja, hoe dat uit te zetten? Iedere keer als ik de Pi opnieuw opstart is mijn website een paar seconden offline.

Sagemcom F5359


Een Experia Box V12
De KPN naam voor die Sagemcom F5359 modem/router:
https://toonwiki.nl/docs/kpn-experiabox-v12/


Wat is een V12?

Een Sagemcom F5359.


Dankjewel.
Ik kan daarop geen specifieke instellingen voor SSH vinden, alleen PortForwarding waar handmatige regels kunnen worden toegevoegd (maar die zijn leeg) en DMZ (volgens mij alleen voor de webserver die het prima blijft doen).

 


Ik had in eerste instantie het idee dat je van buitenaf een ssh verbinding wilde opzetten maar we praten alleen over lokaal binnen het thuisnetwerk.

Dat zou geen enkel probleem mogen zijn en de V12 zou hier ook helemaal niets in mogen blokkeren.


Ik had in eerste instantie het idee dat je van buitenaf een ssh verbinding wilde opzetten maar we prsten alleen over lokaal binnen het thuisnetwerk.

Dat zou geen enkel probleem mogen zijn en de V12 zou hier ook helemaal niets in mogen blokkeren.


Dankjewel voor die uitleg. Dan begrijp je nu ook mijn frustratie dat het niet blijft werken. Heb je iets aan mijn screenshots, staat daar iets verkeerd of moet ik iets doen?


Voor verbindingen binnen het LAN hoeft niets ingesteld te worden.


Ok,
Dan blijf ik mn Raspberry Pi en mn printer maar steeds opnieuw opstarten, gelukkig is dat secondenwerk en heb ik er geen streamingdienst op draaien.
En dat hij niet op zolder staat is ook mooi meegenomen.
Mensen, bedankt voor jullie tips en adviezen, ik heb weer een hoop geleerd. Blijf gezond (lees: werk thuis) en veel geluk


Ik kan daarop geen specifieke instellingen voor SSH vinden, alleen PortForwarding waar handmatige regels kunnen worden toegevoegd (maar die zijn leeg) en DMZ (volgens mij alleen voor de webserver die het prima blijft doen).

Als je het nu eens andersom doet.  DMZ uit.  Dat is alleen bedoeld voor verkeer naar een 2e router.
Niet om er achterliggende servers en apparaten mee te verbinden. Worden namelijk veel meer poorten geopend, die je binnen je interne LAN gebruikt, waardoor je internetverbinding misbruikt kan worden voor andere doeleinden. Dus kan me voorstellen dat het om die reden door het “abuse-team” geblokkeerd zou kunnen worden?

Stel alleen port forwarders in voor de services die je ook werkelijk van buitenaf wilt benaderen.

Als dat om een web-server gaat poort 80 (http) en 443 (https).
En die SSH zou je mogelijk “aan de buitenkant” beter een andere poort gebruiken dan 22,
die je intern dan weer doorstuurt naar poort 22 voor SSH.

EDIT: Met wat ik nu inmiddels van voorgaander berichten lees, gebruik je SSH al helemaal niet extern.. Is daarvoor ook geen extra port forwarding instelling voor nodig.


Zo?
 

De website is nog steeds bereikbaar en een SSH-verbinding kan ik hiermee ook leggen. Denk je dat dat blijft werken zo? Ik gebruik SSH alleen lokaal, dus aan de poortinstellingen heb ik niets veranderd.


Alleen voor externe verbindingen naar een interne service, heb je port forwarding nodig.
Als je van buitenaf geen SSH-verbinding nodig hebt, is die port forwarding niet nodig.

Als het wel de bedoeling is die van buitenaf te bereiken, voor de "publieke” poort zou ik daar wel een andere poort voor kiezen dan poort 22.  Dat is namelijk de poort waar wereldwijd de meeste aandacht voor is door hackers. Je internetverbinding zal dan continue worden bezocht met geautomatiseerde wachtwoord tools om te proberen bij je binnen te komen. Gebruik je dan ook nog eens een standaard “admin” gebruikersnaam, en een niet te lang wachtwoord, is het helemaal feest voor die gasten.


Ok dan haal ik die weer weg.

't Lijkt goed te gaan, dus alvast bedankt voor het advies. We gaan morgen eens kijken of t allemaal nog werkt.


Andere poort kiezen haalt niets uit hoor. Als je hem op een andere poort zet word die ook zo gevonden. Bovendien moet je zelf altijd dat stomme poortnummer erbij zetten met inloggen. Ziet er rommelig uit. Vooral ook als je nog meer services host, ook allemaal op een afwijkend poortnummer, dan word het een puinhoop waar je zelf op een gegeven moment van in de war raakt. Dat moet niet nodig zijn.

Je kunt beter gebruik maken van private/public key authentication en password authenticatie uitschakelen. En zorgen dat je software up-to-date is.


Andere poort kiezen haalt niets uit hoor. Als je hem op een andere poort zet word die ook zo gevonden.

Het gaat er niet zozeer om dat ze een andere poort mogelijk ook zouden kunnen vinden, maar de achterliggende service die eraan gekoppeld is. Bij vele services is men niet geïnteresseerd om daar connectie mee te hebben. Gaat men de moeite er ook niet insteken om zo nodig daar proberen op binnen te komen. Dus het heeft wel degelijk zin andere poortnummers te gebruiken.


Dat lijkt mij een ander topic waard.

Ik ga niet van buitenaf SSHën.


... en DMZ (volgens mij alleen voor de webserver die het prima blijft doen).

DMZ is per definitie voor de complete Pi. Als je dat echt aan hebt staan, is het geen wonder dat er zich problemen voordoen. De reclame in je signoff werkt zo ook in je nadeel.

 


... en DMZ (volgens mij alleen voor de webserver die het prima blijft doen).

DMZ is per definitie voor de complete Pi. Als je dat echt aan hebt staan, is het geen wonder dat er zich problemen voordoen. De reclame in je signoff werkt zo ook in je nadeel.

 


Ik heb DMZ gisteren uitgeschakeld en ben op advies van @Babylonia overgeschakeld naar Port Forwarding. Voor SSH had ik een aparte regel gemaakt, maar dat werd vervolgens afgeraden, dus weer weggehaald. De enige regel die vannacht heeft gedraaid was Port Forwarding HTTPS. Vandaag is de Pi gewoon weer onbereikbaar, dat is jammer, maar ik heb me er inmiddels bij neergelegd.


... en DMZ (volgens mij alleen voor de webserver die het prima blijft doen).

DMZ is per definitie voor de complete Pi. Als je dat echt aan hebt staan, is het geen wonder dat er zich problemen voordoen. De reclame in je signoff werkt zo ook in je nadeel.

 


Ik begrijp niet zo goed waarom die "reclame in mijn signoff" in mijn nadeel werkt (behalve dat iedereen hier dat inmiddels wel weet en het een beetje irritant wordt)


Vandaag is de Pi gewoon weer onbereikbaar, dat is jammer, maar ik heb me er inmiddels bij neergelegd.

Ik neem aan dat je bedoelt dat hij onbereikbaar is voor ssh. Jouw site is immers gewoon nog bereikbaar.

Ik zie overigens dat jij Let's Encrypt gebruikt voor jouw SSL certificaat.

Ik neem aan dat jij een script hebt draaien op jouw Pi die het certificaat automatisch update voordat deze verloopt.

Voor het updaten van SSL certificaten van Let's Encrypt moet je ook TCP poort 80 (http) naar jouw Pi forwarden.

 

Heb je het IP adres van jouw Pi ook vastgezet met een reserved address bij de DHCP leases?

Wat is de foutmelding die je krijgt als je een ssh verbinding probeert op te zetten?


Ik neem aan dat je bedoelt dat hij onbereikbaar is voor ssh. Jouw site is immers gewoon nog bereikbaar.

Ik zie overigens dat jij Let's Encrypt gebruikt voor jouw SSL certificaat.

Ik neem aan dat jij een script hebt draaien op jouw Pi die het certificaat automatisch update voordat deze verloopt.

Voor het updaten van SSL certificaten van Let's Encrypt moet je ook TCP poort 80 (http) naar jouw Pi forwarden.

 

Heb je het IP adres van jouw Pi ook vastgezet met een reserved address bij de DHCP leases?

Wat is de foutmelding die je krijgt als je een ssh verbinding probeert op te zetten?

Ja sorry, ik ben een beetje laconiek geworden, alleen de SSH-verbinding kan niet meer worden opgezet (en ook de printer is onvindbaar, hoewel die nog steeds gewoon aan staat en meldt dat de netwerkverbinding in orde is).

De commandline zegt:
>maestraccio@HPLaRosa ~]$ sudo ssh 192.168.2.7

>sudo] wachtwoord voor maestraccio:

ssh: connect to host 192.168.2.7 port 22: No route to host

 

vwb letsencrypt, dat updatet idd automatisch


Dus de melding is "No route to host".

Als je met een andere computer, telefoon of tablet een ssh verbinding opzet naar jouw Pi, krijg je dan ook "No route to host"?

Is de printer vanaf meerdere apparaten onvindbaar?

 

vwb letsencrypt, dat updatet idd automatisch

Dan moet je wel TCP poort 80 gaan forwarden naar jouw Pi want die wordt gebruikt bij het vernieuwen van het certificaat.


Dus de melding is "No route to host".

Als je met een andere computer, telefoon of tablet een ssh verbinding opzet naar jouw Pi, krijg je dan ook "No route to host"?


Inderdaad, ik probeer het nog eens vanaf mijn Android telefoon.
Ja, die geeft er ook een nummer bij:
connection error (1005)
No route to host


Dus de melding is "No route to host".

Als je met een andere computer, telefoon of tablet een ssh verbinding opzet naar jouw Pi, krijg je dan ook "No route to host"?

Inderdaad, ik probeer het nog eens vanaf mijn Android telefoon.
Ja, die geeft er ook een nummer bij:
connection error (1005)
No route to host

Dan hoop ik dat iemand van KPN dit eens verder zal laten onderzoeken.

Dit lijkt dan toch echt op een probleem met DHCP/ARP op de V12.


Dan hoop ik dat iemand van KPN dit eens verder zal laten onderzoeken.

Dit lijkt toch echt op een DHCP/ARP probleem op de V12.

Toen ik die hierover in eerste instantie probeerde te benaderen kwam ik destijds op dit forum uit…
Niks ten nadele van jullie trouwens, maar ik ben wel weer terug bij start


Kan jij vanaf die computer of een telefoon/tablet wel in de browser naar http://192.168.2.7?


Kan jij vanaf die computer of een telefoon/tablet wel in de browser naar http://192.168.2.7?


Ja dat is geen probleem.

 

Ik heb zojuist vanaf de KPN website een system reset op de V12 uitgevoerd, die test gaf zelf aan dat er iets verbeterd kon worden (maar ik vermoed dat dat een generieke tekst is om een kanaalwisseling te verantwoorden).