j’ai yunohost sur un serveur dédié qui tourne bien. Sauf que j’aimerais m’en servir aussi pour me permettre de sortir de certains réseaux à proxy relou.
Sur le sujet j’ai vu le post de Genma ainsi que SSLH : HTTPS et SSH sur le même port qui m’intéressent grave (une fois un accès ssh accessible en 443 je pourrais faire des tunnels…).
Vu que Yunohost utilise nginx et non pas Apache, j’ai aussi trouvé https://memo-linux.com/sslh-avec-nginx-sslssh-sur-le-meme-port-443/. Dans ce dernier on dit de modifier la conf nginx à coup de “sed”. Pourquoi pas, mais cela ne va probablement pas fonctionner pour les futures applis…
Est-ce qu’il n’y a pas un bout de conf dans un coin où yunohost note sur quel port est nginx et s’en sert lors des installs ?
J’avoue que j’ai un peu de mal à me lancer pour tester vu que ça touche à ssh (et que sur un dédié la perte su ssh peut s’avérer galère).
Quelqu’un l’a déjà fait et pourrait partager son expérience ?
J’ai regardé. Pour le port, il est indiqué dans le fichier de configuration de nginx correspondant au port. Si tu as un sous domaine, par exemple rss.mondomaine.org, tu auras un fichier de conf nginx pour mondomaine.org. Ces deux fichiers pour nginx contiennent la référence au port 443. Les fichiers de configuration liés aux applications eux ne contiennent que la partie de configuration nginx qui leur est dédiée.
Le soucis avec SSLH est qu’il prend l’écoute sur le port 443 quelque soit le domaine (ou sous domaine) de ce que je comprends. Donc tu dois modifier tous les fichiers nginx liés à ton domaine et sous domaine. MAis ça n’inpacte pas les applications que tu mets sur tes domaines.
Si tu testes, ne fais pas la partie du tuto “supprimer la règle iptables du port SSH” de suite. Ainsi tu auras toujours SSH en écoute sur ton port habituel. SSLSSH écoutera sur le 443 et si il voit du SSH arrivée, il te redigera vers SSH. Mais tant que le port SSH classique est ouvert sur l’extérieur, tu pourras aussi faire ssh sur ce port. (tu auras donc 2 ports SSH ouvert).
Merci pour la réponse Genma. Effectivement je n’avais pas réalisé qu’en ne faisant pas la partie iptable ça limitait grandement les risques. J’aurais pu me lancer dès hier. ^^'
Je viens de tester : cela fonctionne sans problème ! (à noter juste que la commande sed n’est pas à exécuter dans /etc/nginx/site-availables mais dans /etc/nginx/conf.d)
Et comme tu le fais remarquer y’a une différence entre applications et domaines. Vu que j’ajoute pas des domaines bien souvent le risque est bien plus faible je le pensait.
Il faut juste que je garde à l’esprit d’aller modifier le fichier de conf du nouveau domaine si j’en ajoute un.
Mais la question reste tout de même ouverte (bien que ça soit moins nécessaire que si ça touchait les applications) : y’a pas un fichier de conf quelque part où on pourrait dire à yunohost que les nouveaux domaines doivent être config sur le port X quand il config nginx ?
Bonjour à tous !
Je réouvre le sujet, car chez moi ca fonctionne… presque.
Dans ma config sslh écoute 443 et forward vers 10443 et 10022.
J’ai modifié tous (je crois) les fichiers .conf afin que nginx écoute l’ https sur le port 10443 (j’ai laissé l’ http sur le port 80, la redirection semble ok).
En gros tout fonctionne à part certains boutons d’accès aux applications, dans l’écran d’acceuil “https://…/yunohost/sso/”:
quand je clique sur le bouton Mastodon, ca me renvoie bien vers https://…/web/getting-started
Idem avec Nextcloud, vers https://…/nc/index.php/apps/files/?dir=/&fileid=20
alors que quand je clique sur Roundcube, ca m’envoie vers https://…/mail (ce qui serait normal),
ca attend un moment sans réagir… puis firefox m’affiche une page d’erreur “Problem loading page” “The connection has timed out”. Et là je vois que l’addresse s’est changé en https://…:10443/mail
J’ai tenté plusieurs modif dans “/etc/ssowat/conf.json”, mais pour le moment sans succès.
J’ai fait un test en utilisant le mode développeur de Firefox.
Y a bien une redirection 301, entre …/yunohost/sso/ et l’application installée en …/dl/
J’ai essayé en rajoutant : "portal_port": "443",
dans : /etc/ssowat/conf.json.persistent
Mais pour le moment, nope.
Bonjour la communauté.
Bon, alors je pense que j’ai trouvé : le problème vient du fait que la page des applications pointe vers des ressources et pas des répertoires (lien sans / final). Ce qui est très bien…
…Sauf que dans les ‘location’ de certaines configurations nginx, c’est le folder qui est défini.
Du coup j’ai rajouté ces lignes dans transmission.conf :
Je déterre cet ancien sujet. J’ai installé SSLH et je suis confronté au même problème de port qui ce rajoute dans l’URL. Toutefois, je n’ai pas trouvé de fichier transmission.conf.
D’autre part, lorsque j’active le mode transparent de SSLH plus rien ne fonctionne.
Je suis preneur de toute solution ou piste.
Petite particularité, le serveur SSH n’est pas sur la même machine. La ligne de commande pour lancer le service est :
usr/bin/sslh --user sslh --listen ip1:443 --ssh ip2:22 --openvpn ip2:1194 --tls ip1:10443 -n --pidfile /var/run/sslh/sslh.pid
