Problème connexion client / Tunnel SSH SmartHomeEntry

[Beboon]

Bonjour à tous,

Voilà, ça y est je me suis lancé dans l’aventure Nextcloud…

Avant d’exposer le problème voici la configuration mise en place :

• Un PC Lenovo Thinkcentre AMD PRO A10, 8 Go de mémoire, SSD 100Go
• OS : Ubuntu Server 24.04
• NextCloud : Nextcloud Hub 26 Spring (34.0.3)
• Un tunnel SSH (SmartHomeEntry)

En local tout allait bien. Mais l’idée c’est quand même d’avoir accès à Nextcloud à l’extérieur…

Voici le problème :

Le relai de SME marche quand je rentre l’URL dans un explorateur internet (Firefox, Edge), en local comme à l’extérieur. Par contre dès que je passé par une client (appli Nextcloud sur Android ou le desktop pour windows, il ne trouve pas le serveur… Avez-vous une idée du problème ?

Sur le client du téléphone le message c’est “Aucune instance du serveur n’a été trouvée”… Puis débrouille toi avec ça.

Et sur l’ordinateur, “La connexion sécurisée a échoué. Vous pouvez ajouter un certificat client et réessayer”. Et “Échec de la connexion à Nextcloud sur https://mon_url.smarthomeentry.com : Nous n’avons pas trouvé ce que vous cherchiez. Il a peut-être été déplacé ou supprimé. Si vous avez besoin d’aide, contactez l’administrateur de votre serveur.”

J’ai également envoyé un mail au support réactif de Smart Home Entry pour savoir si jamais ça venait d’eux. En attente de réponse.

Avez-vous une idée ? une réponse ? une solution ?

Merci d’avance pour votre intérêt.

[vincen]

Salut
Comment tu accèdes à ton Nextcloud ? via son adresse ip non ? Je ne crois pas que le client de synchro accepte une connection sur une IP et en HTTP en plus non ?

[Beboon]

Bonjour,

En local, je rentrais l’adresse IP du serveur. Il s’y connectait de la forme https://XX.XX.XX.XX/.

Et depuis l’extérieur, avec le tunnel SSH de SHE, c’est une adresse https://nom_du_serveur.smarthomeentry.com/ qui redirige vers l’adresse IP locale du serveur via un port.

En tout cas, quand on regarde la page de connexion du client Android, il attend bien un HTTPS.

Et sur le client desktop de windows c’est pareil : il attend un HTTPS :

L’idée du tunnel SSH c’était pour avoir une connexion au serveur depuis l’extérieur sans avoir a ouvrir de port sur ma box… Pour faire ce choix je me suis basé sur cet article et cet article.

A l’heure actuelle j’attends toujours une réponse de SHE. Elle devrait tomber dans la matinée.

Je vais essayé de réinstaller le serveur. Pour repartir sur une config propre.

Si vous avez des idées je reste preneur…

[Beboon]

Voici les messages que l’on obtient sur le client desktop de Windows lors d’une tentative de connexion :

Ça peut peut-être aider à savoir d’où vient le problème ? Chez SHE avec la gestion de leur tunnel ? Dans le paramétrage de ma box qui est resté inchangé ? Une configuration de Ubuntu Server comme l’autosignation du certificat https (pour qu’il fonctionne sur le réseau local) ? Paramétrage de Nextcloud ?

[vincen]

@Beboon

Et depuis l’extérieur, avec le tunnel SSH de SHE, c’est une adresse https://nom_du_serveur.smarthomeentry.com/ qui redirige vers l’adresse IP locale du serveur via un port.

oui mais ça ça ne marchera pas une redirection avec les clients de synchro ! il doit pouvoir se connecter directement au serveur Nextcloud !

@Beboon

Je vais essayé de réinstaller le serveur. Pour repartir sur une config propre.

Euh non Nextcloud c’est pas Windows et si Nextcloud marche bien en local, rien à réinstaller

[Beboon]

@vincen

oui mais ça ça ne marchera pas une redirection avec les clients de synchro ! il doit pouvoir se connecter directement au serveur Nextcloud !

Ah bon ? Bah pourquoi ils en parlent dans les articles ?! Est-ce que tu aurais la source de ce que tu annonces que je la transfert au contact que j’ai chez SHE s’il te plait ?

Donc si je comprends bien, il n’y a pas d’autre choix que de faire du transfert de port d’un domaine public au serveur privé c’est ça ? Quel est le moyen le plus sécurisé et le plus pratique pour accéder à son serveur privé depuis l’extérieur ?

@vincen

Euh non Nextcloud c’est pas Windows et si Nextcloud marche bien en local, rien à réinstaller

Oui oui je sais C’est pas tant Nextcloud que je veux réinstaller mais Ubuntu Server car j’ai fait plein de manipulations et je me dis que j’ai peut être touché à des trucs qui créent des problèmes (changement des le fichier config.php, le server SSH, auto signature du certificat, etc…). Et étant novice, je suis incapable de remettre tout ça au propre autrement.

Bon puis pour être honnête on ne parle que d’installer Ubuntu Server avec un Nextcloud dessus. Tant que tout ça ne tourne pas niquel, je n’attaque pas la configuration du Nextcloud.

[vincen]

@Beboon

Ah bon ? Bah pourquoi ils en parlent dans les articles ?! Est-ce que tu aurais la source de ce que tu annonces que je la transfert au contact que j’ai chez SHE s’il te plait ?

Non aucune source à te citer, juste mon expérience de plus de dix ans avec NC

@Beboon

Donc si je comprends bien, il n’y a pas d’autre choix que de faire du transfert de port d’un domaine public au serveur privé c’est ça ? Quel est le moyen le plus sécurisé et le plus pratique pour accéder à son serveur privé depuis l’extérieur ?

Effectivement si tu disposes bien d’une ipv4 publique avec ta connexion Internet, tu fais un transfert de port et voilà Il te faudra au pire implémenter un dyndns ou équivalent si l’ip publique n’est pas fixe.

@Beboon

Oui oui je sais C’est pas tant Nextcloud que je veux réinstaller mais Ubuntu Server car j’ai fait plein de manipulations et je me dis que j’ai peut être touché à des trucs qui créent des problèmes (changement des le fichier config.php, le server SSH, auto signature du certificat, etc…). Et étant novice, je suis incapable de remettre tout ça au propre autrement.

ah oki, bon amusement alors, perso uniquement Debian, Ubuntu y’a trop de cochonneries douteuses de Canonical dedans

@Beboon

Bon puis pour être honnête on ne parle que d’installer Ubuntu Server avec un Nextcloud dessus. Tant que tout ça ne tourne pas niquel, je n’attaque pas la configuration du Nextcloud.

Oui très bonne procédure effectivement, oublie pas aussi d’implémenter une procédure de sauvegarde automatique et efficace du nextcloud (au moins la db et le dossier data) et prends garde à ce que le dossier data soit hors espace web pour des raisons de sécurité.

[Beboon]

@vincen

Non aucune source à te citer, juste mon expérience de plus de dix ans avec NC

OK. Aucun problème à te faire confiance là dessus. De toute manière, pas d’autre réponse ni sur le forum ni de la part de SHE…

@vincen

Effectivement si tu disposes bien d’une ipv4 publique avec ta connexion Internet, tu fais un transfert de port et voilà Il te faudra au pire implémenter un dyndns ou équivalent si l’ip publique n’est pas fixe.

Oui j’ai vu des trucs comme ça à faire passer à droite à gauche… Je suis vraiment novice dans les serveurs et leurs sécurité donc bah j’avance step by step…

@vincen

perso uniquement Debian, Ubuntu y’a trop de cochonneries douteuses de Canonical dedans

J’etais jeune quand j’avais installé mes première Debian, ça fait longtemps… Puis sur mes ordis je suis passé à ubuntu donc sans remettre ça en question je suis resté là dessus… Mais je vais essaye avec la dernier Debian 13 tiens… pour tester et voir.

@vincen

oublie pas aussi d’implémenter une procédure de sauvegarde automatique et efficace du nextcloud (au moins la db et le dossier data) et prends garde à ce que le dossier data soit hors espace web pour des raisons de sécurité.

oui merci. Pareil j’ai vu ça passer… faut que je regarde comment faire.

Bon en tout cas merci ! Je vais noter ce sujet comme résolu.

Pour résumer : pourquoi les clients ne se connectent pas au serveur NextCloud via une tunnel SSH ? C’est parce qu’ils n’acceptent pas les redirections.

[vincen]

@Beboon

Oui j’ai vu des trucs comme ça à faire passer à droite à gauche… Je suis vraiment novice dans les serveurs et leurs sécurité donc bah j’avance step by step…

oui je comprends, basiquement il faut faire les choses suivantes:
→ avoir un nom de domaine si possible, cela simplifie les étapes suivantes.
→ vérifier que ta connection internet dispose bien d’une IPv4 publique
→ ouvrir le port 80 et 443 dans la box et les faire pointer sur l’ip du serveur nextcloud (attention à mettre la machine qui héberge ton NC en ip fixe dans ton réseau local)
→ modifier chez ton registrar une entrée de ton dns pour la faire pointer sur ton ip publique de ta connexion internet
→ activer dans ton serveur web l’entrée DNS en question et y installer un certificat Let’s Encrypt
→ activer dans ton routeur internet la résolution locale pour l’entrée DNS

@Beboon

oui merci. Pareil j’ai vu ça passer… faut que je regarde comment faire.
Bon en tout cas merci ! Je vais noter ce sujet comme résolu.

Oui le backup il faut absolument avoir quelque chose en place parce que le pépin matériel c’est une réalité sans parler de la terrible fausse manip ou au pire d’un problème de sécurité et une fois en place il faut tester la restauration pour être sûr que le backup est utilisble !

[Beboon]

Merci beaucoup Vincen pour tous tes précieux conseils ! Je note ça précieusement. Et bien évidement que le backup sera mis en place en temps et en heure

D’ailleurs Debian 13 est déjà installé en suivant la pédagogie de ce site. Je continue…

Par contre, de nouveau rebondissement quant à cette histoire de tunnel SSH… J’ai eu une réponse de Grzegorz Mruk de Smart Home Entry (Hyper cool ce gars aussi). Voici la partie concernant le problème :

Les clients de synchronisation fonctionnent parfaitement à travers un tunnel SSH — il n’y a pas de redirection, le tunnel transporte le trafic tel quel. Nous l’avons vérifié sur votre propre installation : les clients bureau, Android et iOS obtenaient tous une réponse normale du serveur.

Le problème était ailleurs : votre sous-domaine avait changé. En réinstallant l’agent, vous en avez reçu un nouveau (beboon-43699f), alors que vos clients de synchronisation pointaient toujours vers l’ancien (beboon-949990) — celui que je vous avais indiqué dans mon message précédent, et qui n’existait plus. Nos journaux montrent 83 tentatives de connexion vers cette ancienne adresse, toutes en erreur 404. C’est exactement le message affiché sur vos captures d’écran : « nous n’avons pas trouvé ce que vous cherchez, il a peut-être été déplacé ou supprimé ».

Autrement dit : il aurait suffi de corriger l’adresse dans les clients. Que vous n’ayez pas pu le deviner est de notre faute — réinstaller un agent ne devrait pas changer votre adresse, et nous allons corriger ce comportement.

Donc il y avait bien une boulette de mon coté… Et lui, visiblement confirme que ça marche…

Bon. j’ai quand même l’impression qu’il va falloir aller plus loin dans cette histoire pour savoir réellement si ça fonctionne. Comme ils m’ont remboursé et qu’ils se servent de cette configuration pour corriger et améliorer leur service, je vais prendre juste un mois (surement négocier avec eux…) pour tester cette histoire de tunnel SSH. Ça ne va pas nous couter grand chose et on sera définitivement fixé.

[vincen]

@Beboon

Par contre, de nouveau rebondissement quant à cette histoire de tunnel SSH… J’ai eu une réponse de Grzegorz Mruk de Smart Home Entry (Hyper cool ce gars aussi). Voici la partie concernant le problème :

ah cool et merci pour l’info, bon à savoir, je ne pensais pas que cela était possible et du coup effectivement pratique si tu ne veux pas que ton NC soit directement exposé ou que tu n’en as pas besoin

[Beboon]

Complément d’information par Grzegorz Mruk concernant ce problème :

La cause principale était chez nous, dans la configuration de notre relais : une règle bloquait toute adresse se terminant par .php et renvoyait une erreur 404 — y compris /status.php, précisément l’adresse que les clients Nextcloud interrogent en premier pour détecter le serveur.

C’est ce qui explique le comportement qui vous paraissait absurde : le navigateur fonctionnait, les clients de synchronisation non. / et /index.php/login ne se terminent pas par .php, donc ils passaient. /status.php, si — donc il était bloqué. Par nous, avant même d’atteindre votre serveur.

J’ai corrigé cette règle hier soir. La preuve, tirée de nos journaux : la même requête /status.php mettait 0,000 s avant la correction — nous la rejetions sur place — et 0,280 s après, le temps d’aller jusqu’à une machine cliente et de revenir.

Donc : les clients de synchronisation fonctionnent bien à travers un tunnel SSH, le forum avait tort sur ce point — mais la raison de votre panne était notre propre pare-feu applicatif, pas votre configuration. Si vous voulez rectifier votre message sur le forum, voilà la version exacte, et n’hésitez pas à citer que l’erreur venait de nous.

Le changement de sous-domaine a bien joué un rôle, mais plus tard : vos clients continuaient d’interroger l’ancienne adresse, d’où les 83 erreurs 404 que je vous mentionnais.

Voilà les raisons de ce blocage ! Tout s’éclaire…

Vendredi soir prochain, avec Grzegorz, on teste le tunnel SSH de SmartHomeEntry avec la version proprement installée du serveur en Debian 13 avec le NextCloud dessus. Voici ce qu’on s’est convenu de tester :

1. Installation propre sur Debian 13 — je veux voir ce que voit un nouveau client, sans raccourcis
2. Navigateur, puis client bureau, puis Android — dans cet ordre, pour isoler chaque étape
3. Synchronisation réelle : un dossier, quelques fichiers, un gros fichier — c’est le vrai test, pas la page de connexion
4. Redémarrage du serveur — vérifier que l’agent revient seul
5. Partage de lien public et applications (Calendrier, Contacts) si vous les utilisez

Après tout ça, si ça vous intéresse, je vous ferai un retour de tous ces tests et donc de cette configuration (serveur local physique NextCloud accessible via tunnel SSH depuis l’extérieur avec l’offre de SmartHomeEntry).