Aller au contenu

Shell Prompt Dans L'interface Dsm


Messages recommandés

Bon, j'ai a moitié résolu mon pb de certif, grace à ce post :http://code.google.com/p/shellinabox/issues/detail?id=59

J'ai donc regénéré, et je peux maintenant me connecter en httpS sur le 4200,

Mais la redirection marche plus sur le /shell , (j'ai pas touché au vhost) et marche si je désactive le SSL ...

Lien vers le commentaire
Partager sur d’autres sites

  • Réponses 82
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

C'est vrai que c'est sympatique d'avoir un shell dans un environnement DSM. Personnellement je préfère une approche VPN qui me permet d'accéder à toutes mes ressources réseau depuis l'extérieur et j'utilise les outils natifs de l'autre coté. C'est à mon avis beaucoup plus transparent et plus facile à mettre en oeuvre! non ?

Patrick

Lien vers le commentaire
Partager sur d’autres sites

Bon, j'ai a moitié résolu mon pb de certif, grace à ce post :http://code.google.c...es/detail?id=59

J'ai donc regénéré, et je peux maintenant me connecter en httpS sur le 4200,

Mais la redirection marche plus sur le /shell , (j'ai pas touché au vhost) et marche si je désactive le SSL ...

Quelle tache que je suis: je viens de m'apercevoir que j'avais laissé ssl désactivé pour mes tests!

Et d'ailleurs en fait, avec le proxy on peut rester comme cela.

Lorsque l'on se connecte en https avec l'url "https://<adddresse syno>/shell", le traffic entre le monde extérieur et le syno est bien crypté SSL. Ce n'est que le traffic local (sur localhost) qui est en clair donc pas vraiment de probleme.

J'ai pu vérifier tout ca avec une capture de packet (tcpdump)

C'est vrai que c'est sympatique d'avoir un shell dans un environnement DSM. Personnellement je préfère une approche VPN qui me permet d'accéder à toutes mes ressources réseau depuis l'extérieur et j'utilise les outils natifs de l'autre coté. C'est à mon avis beaucoup plus transparent et plus facile à mettre en oeuvre! non ?

A mon avis c'est complémentaire, par exemple avec le shell dans le navigateur je pourrais me connecter de mon taf en shell sur mon syno (sous réserve d'avoir ajouté la ligne "allow from" qui va bien), alors que le VPN est hors de question, n'étant pas admin sur mon PC pro.

[edit]

et en VPN difficile de faire un /usr/syno/etc/rc.d/<service>.sh restart par exemple.

[edit#2]

de toutes façons admin ou pas, derrière un proxy, le VPN, hein .... :(

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

A mon avis c'est complémentaire, par exemple avec le shell dans le navigateur je pourrais me connecter de mon taf en shell sur mon syno (sous réserve d'avoir ajouté la ligne "allow from" qui va bien), alors que le VPN est hors de question, n'étant pas admin sur mon PC pro.

Je suis d'accord avec toi qu'il faut installer un client sur le PC...

[edit]

et en VPN difficile de faire un /usr/syno/etc/rc.d/<service>.sh restart par exemple.

Si le VPN est fait sur le routeur je ne vois pas où est le problème !

[edit#2]

de toutes façons admin ou pas, derrière un proxy, le VPN, hein .... :(

Mon VPN passe parfaitement le proxy !

Patrick

Lien vers le commentaire
Partager sur d’autres sites

Quelle tache que je suis: je viens de m'apercevoir que j'avais laissé ssl désactivé pour mes tests!

Et d'ailleurs en fait, avec le proxy on peut rester comme cela.

Lorsque l'on se connecte en https avec l'url "https://<adddresse syno>/shell", le traffic entre le monde extérieur et le syno est bien crypté SSL. Ce n'est que le traffic local (sur localhost) qui est en clair donc pas vraiment de probleme.

J'ai pu vérifier tout ca avec une capture de packet (tcpdump)

Mon souci c'est que justement, "httpS://..../shell" fonctionne pas et "httpS://IP:4200" fonctionne

J'ai tenté d'activer les logs apache, mais rien d'anormal dedans

Lien vers le commentaire
Partager sur d’autres sites

Mon souci c'est que justement, "httpS://..../shell" fonctionne pas et "httpS://IP:4200" fonctionne

J'ai tenté d'activer les logs apache, mais rien d'anormal dedans

C'est que la config proxy n'est pas prise en compte:

Le fichier contenant les lignes:

<Location /siab>
ProxyPass http://localhost:4200
Order deny,allow
deny from all
allow from etc ...
</Location>

Doit être inclus directement ou indirectement par un des fichiers de conf apache.

Pour ma part, à la fin de "/usr/syno/apache/conf/httpd.conf-user" j'ai ajouté une ligne "#include" du fichier ci dessus.

Suffit de relancer apache pour que cela soit pris en compte:

/usr/syno/etc/rc.d/S97apache-user.sh restart

Lien vers le commentaire
Partager sur d’autres sites

J'ai mis ce Location dans le fichier apache-user directement

(Ainsi que les if module)

Je vais faire un fichier de conf a part et faire l'include alors :)

Par contre, petite question sur le "allow from" :

Vu que SIAB ne sera lancé en localhost-only , j'ai pas besoin de spécifier de deny / allow du coup ?

(je voulais le limiter en "allow from localhost")

Lien vers le commentaire
Partager sur d’autres sites

Mon VPN passe parfaitement le proxy !

Je ne bénéficie pas de cette fonctionnalité : notre proxy est configuré pour supporter uniquement HTTP et FTP (et encore de façon limitée).

En outre, comme je ne suis pas admin réseau à ma boite, la config du proxy ne dépend pas de moi (et même si c'était le cas nous avons des règles de sécurité qui m'empècheraient de faire tout ce que l'on veux).

Cela dit, va falloir que je vérifie aussi que shellinabox fonctionne à travers notre proxy (qui n'est pas de la première jeunesse en outre)

J'ai mis ce Location dans le fichier apache-user directement

(Ainsi que les if module)

Je vais faire un fichier de conf a part et faire l'include alors :)

Dans ce cas, ça ne devrait pas faire de différence, le probleme est ailleurs alors.

Tu as bien relancé apache au moins?

Par contre, petite question sur le "allow from" :

Vu que SIAB ne sera lancé en localhost-only , j'ai pas besoin de spécifier de deny / allow du coup ?

(je voulais le limiter en "allow from localhost")

Ah non pas du tout, la restriction d'ip se fait *en amont* du proxy, c'est l'ip externe qui est validée

[edit]

je pense a un truc d'un coup: suivant comment ta box fait les redirections de port, lorsque tu te connectes sur place en utilisant l'ip externe il est possible que ca coince.

Dans le cas d'une freebox, ça fonctionne et la connexion va sembler provenir de la freebox (a prendre en compte dans le "allow from"

Essaie pour voir avec l'ip *interne* du syno:

https://<ip_interne>/shell

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Tout mes tests sont pour l'instant fait qu'en réseau local (je procède par étapes :P)

Du coup, je n'ai tenté que avec httpS://ip.local/shell

(si je tente en http, il me redirige vers le httpS puis erreur)

As-tu bien activé le ssl sur webstation? (panneau de configuration->services web->service http->activer https?)

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

As-tu bien activé le ssl sur webstation? (panneau de configuration->services web->service http->activer https?)

Bien vu !!!!

Et je vais te dire le pire : je n'avais pas activé web station jusqu'à ce matin (donc après mes tests) et çà fonctionnait (a moitié, certes)

Le vhost marche beaucoup mieux maintenant (local et externe)

Par contre, le proxy du boulot ne veux rien savoir :

Je pointe mon navigateur sur http://mon.dyndns/shell la redirection se passe bien vers le httpS, puis "SSL connection error"

(La même manip depuis mon tel en 3G fonctionne)

Autre question, plus ou moins lié :

Comment avoir l'interface DSM sur le port 80 (au lieu de la redir vers le 5000)

Lien vers le commentaire
Partager sur d’autres sites

salut bud,

je travaille effectivement sur une idée similaire mais sur la base de gateone. L'idée est de pouvoir ouvrir un shell dans le DSM depuis un navigateur du travail ; seuls les ports 80 (HTTP) et 443 (HTTPS) sont ouverts.

Pour éviter de voir passer des identifiants en clair, il est primordial d'accéder au DSM en HTTPS.

Voici l'architecture que j'imagine (et qui fonctionne à quelques détails prêts) :

- depuis le navigateur du travail, je me connecte à https://dsm.domaine.synology.me/

- le flux arrive sur mon routeur ADSL à la maison

- le port 443 est redirigé vers le port 30443 géré par haproxy (reverse proxy qui travail sur le nom du serveur appelé pour rediriger vers le bon service à l'intérieur de mon réseau)

- haproxy reconnaît dsm.domaine.synology.me dans l'adresse appelée. il redirige vers mon syno, sur le port 5001

- le DSM apparaît en retour sur le navigateur de mon travail

- dans le DSM, demande d'ouverture de gateone sur l'url https://gateone.domaine.synology.me/

- même natage vers haproxy sur mon routeur

- haproxy reconnaît gateone.domaine.synology.me comme nom du serveur appelé, il redirige la requête vers le port 20443 qui correspond à gateone

- gateone apparaît en retour dans le navigateur du travail

Cela fonctionne grâce aux principes suivants, pré-requis indispensables :

- routage de l'ensemble des requêtes HTTPS vers haproxy, c'est cet outil qui a la charge de ventiler les requêtes vers le bon serveur TCP

- haproxy reconnaît sans problème le sni dans le flux HTTPS, ce qui lui permet d'orienter les requêtes en fonction du nom du serveur appelé (l'URL après le nom du serveur est chiffrée en HTTPS, on ne peut donc pas se baser sur cela)

- haproxy gère très bien les websockets, indispensable pour un bon fonctionnement de gateone qui fonctionne en HTML5

A noter que cette architecture permet également d'ouvrir un flux ssh au travers de haproxy, il suffit alors à haproxy de rediriger sur le port 22 du syno dans le cas où le protocole d'appel n'est pas du HTTPS.

Maintenant les bonnes nouvelles : haproxy et gateone devraient pouvoir être proposés sur le repo SynoCommunity, le temps de faire tout cela proprement...

Lien vers le commentaire
Partager sur d’autres sites

Merci pour l'info Nours !

Diaoul m'avait bien prévenu, mais je me disais, vu que tu avais l'air plutôt occupé, j'aurais ptet réussi à faire marcher tout çà (SIAB) avant que tu ai fini le package

A voir tout ce que je dois encore réaliser pour arriver à mes fins (ce que ton package gère directement) ben j'en ai encore pour 1 mois XD

En attendant le package, je vais quand même essayer de trouver (et d'apprendre surtout) pour ma culture personnelle :D

Lien vers le commentaire
Partager sur d’autres sites

Comment avoir l'interface DSM sur le port 80 (au lieu de la redir vers le 5000)

virtualhost! (cf le tuto de PatrickH)

Dans le fichier ou tu as defini le block "location" pour SIAB (ou un autre si tu veux), tu met ceci:

(remplacer dans la suite "MONDOMAINE" par le nom DNS externe, par exemple: "monnasamoi.myds.me" si enregistré ainsi en dynamique chez synology)


#+
# Les "loadmodules" semblent faire double emploi avec ceux de la conf SIAB
# mais on s'en br^h^hfout grase au IfModule
#-
<IfModule !proxy_module>
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
</IfModule>

NameVirtualHost *:

<VirtualHost *:>
ServerName webman.MONDOMAINE
ProxyRequests Off
ProxyVia Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:5000/
ProxyPassReverse / http://localhost:5000/
</VirtualHost>

#
# SSL
#
NameVirtualHost *:443

<VirtualHost *:443>
ServerName webman.MONDOMAINE
SSLCipherSuite HIGH:MEDIUM
SSLProtocol all -SSLv2
SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt
SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key
SSLEngine on
SSLProxyEngine on
ProxyRequests Off
ProxyVia Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / https://localhost:5001/
ProxyPassReverse / https://localhost:5001/
</VirtualHost>

Et voila, tu peux te connecter maintenant sur l'interface DSM avec l'url http://webman.MONDOMAINE et https://webman.MONDOMAINE en ssl.

PS: en général faire comme ici des virtualhosts basés sur le nom en SSL n'est pas préconisé.

Si tu veux gérer strictement le certificat de site ça va poser des problemes. Mais si l'objectif est uniquement de chiffrer le traffic c'est suffisant.

Bien entendu on peut choisir ce qu'on veut comme nom de sous-domaine à la place de "webman".

Il est possible de procéder de façon similaire pour filestation, downloadstation, audiostation.

Cela dit, en installant haproxy je pense que l'on pourra se passer du proxy apache, ce qui rend tout cela obsolète.

A suivre donc

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

J'étais justement en train de regarder ce tuto sur le site de PH, mais il indique en prérequis "nom de domaine"

Moi, je n'ai qu'un domaine dynamique (dyndns.org)

Attention, depuis DSM 4.0, paramétrer des vhosts en reverseproxy casse les sauvegardes rsync.

En plus, le fait de bricoler des fichiers de configuration du DSM pour induire des effets de bords non maîtrisés lors d'un changement d'une mise à jour du système.

J'en suis pleinement conscient, et je suis encore en 3.2 au moins jusqu'a la sortie de la 4.1 :D

Dans tout les cas, je conserver toujours les originaux de mes fichiers, au cas ou ^^

Lien vers le commentaire
Partager sur d’autres sites

Attention, depuis DSM 4.0, paramétrer des vhosts en reverseproxy casse les sauvegardes rsync.

Savais pas,

Suis étonné en plus: comment les sauvegardes rsync peuvent dépendre de conf apache ?

En plus, le fait de bricoler des fichiers de configuration du DSM pour induire des effets de bords non maîtrisés lors d'un changement d'une mise à jour du système.

Oh, Il s'agit d'une toute petite modif de rien du tout: ajout d'une simple ligne dans "/usr/syno/apache/conf/httpd.conf-user":

include <dossier perso dans /volume1/conf.d/*.conf[/CODE]

Si la MAJ écrase la modif, suffit de la rajouter.

Lien vers le commentaire
Partager sur d’autres sites

J'étais justement en train de regarder ce tuto sur le site de PH, mais il indique en prérequis "nom de domaine"

Moi, je n'ai qu'un domaine dynamique (dyndns.org)

Etant donné que ça marche avec les nom de domaines dynamiques fourni par syno ("myds.me" par exemple). Pas de raison que ce soit différent avec dyndns.

je viens de vérifier:

m29W3.png

Lien vers le commentaire
Partager sur d’autres sites

Savais pas,

Suis étonné en plus: comment les sauvegardes rsync peuvent dépendre de conf apache ?

Oh, Il s'agit d'une toute petite modif de rien du tout: ajout d'une simple ligne dans "/usr/syno/apache/conf/httpd.conf-user":

include <dossier perso dans /volume1/conf.d/*.conf[/CODE]

Si la MAJ écrase la modif, suffit de la rajouter.

regarde là :

Lien vers le commentaire
Partager sur d’autres sites

Bien sur que je connais: j'ai posté dans ce fil! (et dans un autre auquel il fait référence)

En effet, depuis la DSM 4, il fait éviter de trifouiller les fichiers /usr/syno/etc/httpd-ssl-vhost.conf-user et /usr/syno/etc/httpd-vhost.conf-user c'est pourquoi depuis je préconise de se contenter du "include" dans "/usr/syno/apache/conf/httpd.conf-user"

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Bon, j'ai utilisé tes préconisations Raoul

J'ai donc crée un /volume1/apache.conf/ et j'y dépose mes différents fichiers, et j'ai juste rajouté un Include dans le apache user (en retirant ce que j'ai mis hier)

J'ai donc 2 fichiers, 1 pour la location /shell, et 1 pour le vhost

Dans ce fichier de vhost, j'ai donc modifié le ServerName pour y mettre "dsm.domaine.dyndns.org" (en 80 et 443)

J'ai relancé l'apache, et là ...

L'url http://dsm.domaine.dyndns.org n'existe pas , mais par contre, l'url http://domaine.dyndns.org me renvoi bien sur la page de login ...

Bon, çà me dérange pas, mais je comprends pas trop pourquoi

(J'ai pas pu tester le 443 car je ne l'ai pas encore ouvert sur ma bobox)

Lien vers le commentaire
Partager sur d’autres sites

L'url http://dsm.domaine.dyndns.org n'existe pas , mais par contre, l'url http://domaine.dyndns.org me renvoi bien sur la page de login ...

Bon, çà me dérange pas, mais je comprends pas trop pourquoi

(J'ai pas pu tester le 443 car je ne l'ai pas encore ouvert sur ma bobox)

Essaie la commande "nslookup dsm.domaine.dyndns.org" (ou n'importe quoi a la place de "dsm")

si ca ne te donne pas ton ip externe, c'est que dyndns ne gère pas le "catchall" pour les sous domaines, ce qui est bien ennuyeux pour toi.

Avec myds.me, une fois que l'on a enregistré son nom (monsyno.myds.me) *toutes* les requetes en <nimportequoi>.monsyno.myds.me sont résolues avec l'ip de base.

On dispose donc d'un nombre de sous domaines infini.

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Essaie la commande "nslookup dsm.domaine.dyndns.org" (ou n'importe quoi a la place de "dsm")

si ca ne te donne pas ton ip externe, c'est que dyndns ne gère pas le "catchall" pour les sous domaines, ce qui est bien ennuyeux pour toi.

C'est bien çà, pas de "catchall" pour moi :(

Lien vers le commentaire
Partager sur d’autres sites

C'est bien çà, pas de "catchall" pour moi :(

Tu peux peut-etre basculer la gestion DDNS du syno vers synology tout en conservant ton nom chez dyndns.

Si tu a en plus une IP fixe, pas besoin d'avoir de mise a jour auto chez dyndns et tu beneficiera des deux noms (.dyndns.org et .myds.me)

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.


×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.