Bonjour je suis a la recherche d'une méthode sécurisée pour administrer des serveurs en ssh.
Aujourd'hui les serveurs (virtuels) qui contiennent des données clients sont dans un datacenter, sur un vlan dédié.
L'idée est qu'on a pas d'accès direct sur ces serveurs: pour des raisons de sécurité, on doit se connecter (en rdp) sur une machine d'un vlan d'administration, et de là se connecter via putty au serveur. La raison invoquée est que la machine depuis laquelle on se connecte au bureau peut être vérolée et que si elle a un accès direct sur la machine du client elle peut l'infecter.
Le problème que cela me pose est que c'est pas vraiment pratique, depuis ma machine linux, de me connecter en rdp sur une machine windows, puis d'utiliser putty pour me reconnecter sur une machine linux. Seulement n'étant pas expert réseau, je ne sais pas quelle alternative je pourrais proposer.
Des idées?
# ssh sur Windows
Posté par jame_s . Évalué à 3.
Tu pourrais installer un serveur SSH sur Windows si tu as assez de droit sur ton compte Windows et si le firewall l'autorise. Ensuite tu peux utiliser Bélier pour te connecter de façon transparente.
# je ne comprends pas la logique ....
Posté par totof2000 . Évalué à 4.
???? Une machine Windows qui infecterait une machine Linux ? Faudrait qu'on m'explique.
[^] # Re: je ne comprends pas la logique ....
Posté par nanard . Évalué à 3.
Une machine windows vérolé qui log mon activité ? Faudrait qu'on m'explique.
Allez tous vous faire spéculer.
[^] # Re: je ne comprends pas la logique ....
Posté par totof2000 . Évalué à 3.
En quoi le fait d'utiliser un TSE change quelque chose ? Si la machine est capable de logger, elle loggera que ce soit du TSE ou n'importe quoi d'autre.
[^] # Re: je ne comprends pas la logique ....
Posté par yohann (site web personnel) . Évalué à 1.
Merci c'est typiquement le genre de commentaire qui me permet d'avancer, (même si une fois formulé ça parait si évident que j'aurai pu y penser tout seul)
# quand je comprend pas, je fais un schema
Posté par NeoX . Évalué à 5.
en gros on te propose de te connecter selon le schema suivant :
toi (linux) -> RDP -> machine administration (windows) -> SSH -> le serveur à gerer
car ta machine n'est pas sur le meme VLAN que le serveur.
deja pour simplifier, demande leur de te faire une machine linux comme machine d'administration
1°) tu pourras faire du rebond SSH dessus
2°) y aura moins de virus
3°) ce sera plus securisé que RDP, quoique le RDP recent avec un LDAP et des certificats ca doit quand meme bien limiter.
[^] # Re: quand je comprend pas, je fais un schema
Posté par yohann (site web personnel) . Évalué à 1.
Merci, ton schema décris exactement la configuration dans laquelle je me trouve.
Une machine linux dans le vlan d'admin serais sans doute la meilleur transposition de ce qui est fais avec windows actuellement.
# En pratique
Posté par nono14 (site web personnel) . Évalué à 4.
Perso, j'ai jamais eu de soucis en se connectant en direct. ( firewall + durcissement d'os )
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: En pratique
Posté par yohann (site web personnel) . Évalué à 0.
Moi non plus dans la gestion de mon serveur perso, (mais je crois que mes connexions depuis un windows se compte sur les doigts d'une main)
# ssh -R
Posté par Bernez . Évalué à 6. Dernière modification le 23 septembre 2013 à 22:42.
Si ton serveur peut accéder en SSH à ton poste client, utilise un tunnel SSH. Depuis ton serveur, lance :
ssh -R 2222:localhost:22 login_client@adresse_de_ton_client
Tu peux lancer cette commande depuis screen pour pouvoir le détacher du terminal.
Ensuite, depuis ton client tu te connectes avec :
ssh -p 2222 login_serveur@localhost
Tu peux utiliser n'importe quel port à la place de 2222, du moment qu'il est libre sur ton client.
[^] # Re: ssh -R
Posté par yohann (site web personnel) . Évalué à 1.
Très bonne idée et peu invasif, malheureusement je n'ai pas la possibilité de joindre mon client depuis le serveur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.