Version imprimable
Bonjour à tous
j'ai intégré une applet java dans mon site web qui sert de client SSH.
La question que je me pose est la suivante (je n'y connais pas grand chose en java) : quelle adresse IP va prendre mon applet ? l'adresse IP du serveur qui l'héberge ou celle de la personne qui se connecte sur le site ?
Dans le deuxieme cas, existerait-il un moyen de repasser au premier cas ?
(je voudrais pouvoir utiliser "localhost" pour me connecter à ce serveur via l'applet...)
merci
Nicolas
Bonjour,
L'applet s’exécute coté client, donc ton serveur verra un client SSH avec l'ip du poste client qui essai de se connecter.
Ca n'a pas de sens, pourquoi tu veux faire ça ?Citation:
(je voudrais pouvoir utiliser "localhost" pour me connecter à ce serveur via l'applet...)
En fait mon idée initiale était d'utiliser une page du type AjaxtermCitation:
Envoyé par Jimmy_
pour ne pas avoir à ouvrir de port SSH vers l'exterieur étant donné que dans ce cas, l'adresse serait drectement celle du serveur où est hébergée la page web... mais devant quelques problèmes techniques rencontrés, je me suis rabattu sur l'applet java du client SSH MindTerm.
n'oubliez pas qu'un applet s'exécute coté client, donc tout utilisateur de votre site a maintenant une accès ssh sur votre serveur puisque les user/pass sont dans l'applet, êtes vous sûr que c'est ce que vous voulez? :?
Négatif (enfin si j'en crois les specs...) car il ne s'agit pas d'une interface spécifique à mon serveur, mais d'un client SSH2 classique... sous JAVA.Citation:
Envoyé par tchize_
Ainsi [en principe] rien n'est marqué en dur dans le code de l'applet, car rien ne m'empeche de me connecter à un autre serveur, ou encore avec d'autres identifiants. Si quelqu'un récupère le .jar (d'ailleurs c'est peut-etre une autre extension, je ne sais plus...l'applet quoi...) la personne aura normalement juste un client SSH à dispo, en aucun cas (j'espère réellement encore une fois) un identifiant ou password.
De plus, le formulaire de ma page web étant transmis en HTTPS/SSL et les données via SSH2, et la page elle-même étant protégée par mot de passe (utilisant le SDK du serveur SYNOLOGY, donc pas de bidouillage...), j'espère avoir minimisé les risques...
Reste à savoir comment ne pas mettre en cache du tout l'applet, mais pour ca, j'attends vos suggestions :o)
Néanmoins, je pense (et je croise les doigts) avoir sécurisé un max mon installation.
Bye
Nico
Ce que je veux dire c'est que votre utilisateur à accès au user/pass que vous utilisez pour votre ssh. Puisque ca s'exécute coté client. Maintenant si chaque user à ses propres identifiants sur votre serveur ssh et qu'il est normal qu'il les connaisse, pas de soucis évidement ;)
euh... je ne comprends pas... :roll:Citation:
Envoyé par tchize_
Dans le cas présent, chaque utilisateur, pour se connecter à la page web elle-même doit etre enregistré dans le serveur; C'est avec ces memes credentials qu'il peut se connecter au SSH avec ses propres droits, donc normal ou pas... ? :P
Ben a priori oui alors :)
Ce qu'il faut éviter c'est que N users différent partagent via l'applet le même crédential :ccool:
pour cela (hormis un problème d'usurpation de session), ce cas ne se produirait que si les personnes passaient sur le même poste physique, n'est-ce pas ?
Dans votre cas je ne sais pas si c'est possible. C'est juste que certains devs ont parfois tendance à oublier que l'applet est exécutée coté client et d'envoyer un mot de passe à l'applet sans penser que du coup l'utilisateur peut le lire, alors que ce mot de passe est supposé secret et le même pour tout le monde. Donc je voulais vous éviter cette erreur ;)
Je ne compte plus le nombre de fois sur ce forum où les gens envoient directement le mot de passe d'accès root à la base de donnée dans une applet, histoire que n'importe quel utilisateur puisse foutre le bordel dans les tables :aie:
La principale faille de sécurité de ce type de connexion.
Outre le keylogger, c'est la fameuse 'canne à pêche'.
Il est assez simple de créer une applet semblable de récupérer le mot de passe et de connecter l'utilisateur ni vu ni connu.
Le seul moyen est de passer à l'authentification forte avec un token comme SecureID par exemple.
dans mon cas, le shéma est le suivant
CLIENT <- HTTPS -> page PHP (protégée par sessions & identifiants stockés sur le serveur en utilisant SDK de synology) avec applet JAVA MindTerm <-> SSH2 <-> SERVEUR
so... qu'en pensez vous ?
Nico
en faisant du phishing ? l'accès à ma page ne se fait qu'après authentification par le serveur... donc si l'utilisateur arrive sur la page (celle qui contient l'applet), elle ne verra celle ci que s'il est identifié; sinon, il verra la formulaire de login. Donc s'il s'agit de cette faille de sécu, je peux accepter le risque; de plus, je suis censé etre le seul utilisateur... :PCitation:
Envoyé par Jimmy_
pas possible ici, je n'ai pas de serveur RSA chez moi :)Citation:
Envoyé par Jimmy_
oui
Créer l'applet semblable est facile, d'autant plus qu'il utilise une applet fortement distribué. Par contre, arriver à l'afficher au milieu d'un page SSL négociée avec son serveur est impossible sans avoir au préalable foutu en l'air le SSL, auquel cas, de toutes façons, on a déjà pu récupérer le login/pass et on va pas en plus s'emmerder avec l'applet.Citation:
Envoyé par Jimmy_
De toutes façons, le client peut aussi utiliser directement son propre client ssh (openssh sous linux, putty sous windows)
ce qui voudrait dire avoir cracké SSL + écouté l'info circulant en SSH2...Citation:
Envoyé par tchize_
ca fait pas un peu beaucoup de complications pour un pirate qui voudrait juste un accès sur un serveur perso ? :D
Nico
Non, je parle du client qui a le droit de faire le ssh (celui qui recois l'applet qui lui est destinée), il a rien a cracker toute est dans l'applet et ses paramètres ;)Citation:
Envoyé par Nicopilami
eh eh, à priori même pas.. :lol:Citation:
Envoyé par tchize_
En réalité les parametres ne sont passées à l'applet que s'il passe par la page web sur laquelle il s'est authentifié.
Si l'utilisateur ne récupère que le .jar (ou la partie java quoi), il s'agira alors d'un client SSH tout ce qu'il y a de plus simple... pas de crédential en dur :)
En revanche, s'il s'authentifie sur la page, il peut effectivement regarder le code source... qui contiendra ce qu'il connait déjà puisqu'il s'est authentifié pour y accéder :D
Après, évidemment s'il marque ses identifiants sur un post-it... :mouarf:
Nico