Ouvrir le port 22 de la BBOX pour connection SSH

Support Debian
#1

Bonsoir,

Je reviens vers vous car j’ai un problème concernant le port 22 de ma Bbox pour l’utilisation d’un petit serveur maison avec ssh.

Actuellement j’ai 2 ordis, un serveur sous Debian avec openssh-server d’installé et un ordi sous Crunchbang avec openssh-client d’installé;

pour une connexion en local aucun problème, de Crunchbang à Debian :

ssh root@192.168.1.6 -----> fonctionne parfaitement.

j’ai donc essayé une connexion extérieure de mon portable Crunchbang vers Debian en utilisant bien sur mon IP public :

ssh root@89.X.X.X ------> un message d’erreur du type : “port 22: No route to host”

bon ok, donc je chine à droite à gauche et j’apprends qu’il faut ouvrir le port 22 dans sa box/routeur.

je vais donc dans ma Bbox (bouygues télécom), puis dans configuration du routeur et enfin NAT/PAT et je rentre ceci :

“nom de la règle” = serveur
"protocole" = TCP
"Choix Port/plage de ports" = port
"Port(s) source(s)" = 22
"@ IP de destination ou nom de l’ordinateur" = 192.168.1.6 (l’IP local du serveur Debian donc)
“Port de destination” = 22
et enfin j’ai coché la case “Toujours attribuer cette règle à cet ordinateur”.

j’enregistre puis sur mon portable Crunchbang (client), je fais un nmap 192.168.1.6 qui m’affiche :

Interesting ports on new-host-4.home (192.168.1.6): Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind

mais quand je fais un nmap 89.X.X.X (IP public de ma box redirigé par le port 22 sur mon serveur Debian) ca m’affiche :

Interesting ports on FAST3504 (89.X.X.X): Not shown: 994 closed ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 2222/tcp open unknown 8080/tcp open http-proxy 8443/tcp open https-alt 8888/tcp open sun-answerbook

comme je n’ai pas la possibilité de tester en “extérieur” comme bon me semble une connexion ssh, avant ma prochaine tentative pouvez-vous me dire si je suis sur la bonne route ou si le fais que la ligne :
“22/tcp open ssh” n’apparaisse pas dans le nmap de mon IP public soit un problème ?

voici le contenu de sshd_config :

[code]# What ports, IPs and protocols we listen for
Port 22

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM yes[/code]

merci d’avance pour vos suggestions et votre aide.

#2

Déjà ouvrir le port 22 sur l’extérieur n’est pas recommandé.
Pour ma part j’utilise un subterfuge “SSLH” qui permet d’avoir un serveur HTTPS et SSH sur le même port (443).
Il ne faut pas prendre ça comme une solution de sécurité fiable mais c’est un bon début.
Après le portknocking est un cran au dessus.

Et sinon, as tu des règles IPTABLES ?

#3

Salut presqueanonyme,

En fait, de prime abord, le serveur fonctionne. Tu arrives à te connecter en local en SSH sur cette machine ce qui veut dire qu’elle est bien configurée. On peut donc “en premier lieu” éviter de modifier quelque chose à ce niveau.

En fait, truc tout con, il faudrait que tu essayes de te connecter à ton serveur, mais de l’extérieur, pas d’un poste faisant partie du même réseau que ce dernier.

Je m’explique :

Chez Free (je ne connais pas le cas de Bouygues), on ne peut pas faire une boucle sortant vers “'l’internet” et revenant au point de départ (ton IP publique). Hors c’est ce que tu essayes de faire. Chez toi -> Internet -> Retour chez toi

En gros, quand tu es chez toi, utilises alors l’IP locale du serveur (192.168.1.5)
Quand tu es à l’extérieur, utilises l’IP publique (89.xx.xxx.xx)

Je ne peux garantir que ce soit exactement le problème que tu rencontres, mais ça vaut le coup d’essayer. J’ai eu le même cas (je suis chez Free), et j’avais passé quelques heures à retourner le problème dans tous le sens alors qu’il n’y en avait pas (tout était déjà fonctionnel).

Cordialement :slightly_smiling:

#4

:open_mouth: Je suis chez Free et j’arrive tout a fait a me connecté a mon serveur avec l’adresse IP publique. Soit je passe par le nom DNS mais ça revient au même.

Aussi bien avec la machine en DMZ ou pas.

D’ailleurs j’ai quelques soucis de connexion HTTTP. Quand j’accède a mon web mail il faut que je tente 5/6 connexion avant d’avoir la mire d’identification, ou tout autre page web que j’héberge … bizarre.Il faut que j’essaye en faisant repasser la machine en non-DMZ et une redirection des plages de port. :017

#5

@Mimoza

Je confirmes :slightly_smiling: A moins que tu n’utilises pas la freebox comme routeur et que tu utilises ton propre matos?

Un sujet équivalent où le problème venait bien de là

ps : faut que je retrouve l’appellation correcte de cette fonctionnalité. Je l’appelle à chaque fois “boucle” mais c’est pas le terme technique. On m’avait déjà soufflé le vrai nom mais m’en rappelle plus :083

#6

adrese de loop back ?

#7

perso j’utilise le site là pour faire des scans et vérifier si mes ports sont accessible de l’exterieur, si ça peut aider.

#8

@manslipkorn : En fait avant j’avais la v5 et dès que le serveur était en DMZ il n’était plus du tout accessible. Et je pensais naïvement qu’avec la v6 le problème serait réglé … pas complètement à priori

#9

Merci à vous tous pour vos réponses;

alors ma manip’ était correcte et j’ai pu avoir l’occasion de me connecter en ssh en exterieur sans aucun problème;

merci à GRICGRIC pour ton lien, effectivement il a pu confirmer que le port 22 était bien ouvert.

merci

#10

Résolu? => Coche verte!

#11

[quote=“Mimoza”]Déjà ouvrir le port 22 sur l’extérieur n’est pas recommandé.
Pour ma part j’utilise un subterfuge “SSLH” qui permet d’avoir un serveur HTTPS et SSH sur le même port (443).
Il ne faut pas prendre ça comme une solution de sécurité fiable mais c’est un bon début.
Après le portknocking est un cran au dessus.

Et sinon, as tu des règles IPTABLES ?[/quote]

Le mieux pour la sécurité question port n’est t’il pas d’utiliser des ports non standarts, je pense que cela supprimé déjà une bonne partie des attaques par robots.

moi je met par exemple du 2222 pour le SSH

#12

[quote=“canaillou2k5”][quote=“Mimoza”]Déjà ouvrir le port 22 sur l’extérieur n’est pas recommandé.
Pour ma part j’utilise un subterfuge “SSLH” qui permet d’avoir un serveur HTTPS et SSH sur le même port (443).
Il ne faut pas prendre ça comme une solution de sécurité fiable mais c’est un bon début.
Après le portknocking est un cran au dessus.

Et sinon, as tu des règles IPTABLES ?[/quote]

Le mieux pour la sécurité question port n’est t’il pas d’utiliser des ports non standarts, je pense que cela supprimé déjà une bonne partie des attaques par robots.

moi je met par exemple du 2222 pour le SSH[/quote]

D’après moi changer le port SSH est une bonne chose, et encore que si c’est pour mettre du 222 ou du 2222 ce doivent être les ports qui sont scanner directement après un scanne du port 22 :005 :005

Le port knocking c’est un peu extrême mais très rassurant lorsque l’on est obligé de laisser un port SSH accessible ( le VPN est une autre possibilité ), le transit vie le port https 443 est aussi une bonne solution.

Le sujet à déjà été abordé à plusieurs reprises sur le forum.

Liste de ports recensés et déjà utilisés

#13

Non : sécurité par l’obscurité.

Qui n’ont aucune chance de réussir par ailleurs si le service est bien sécurisé. Le seul intérêt est d’alléger les logs.

#14

[quote=“canaillou2k5”]
Le mieux pour la sécurité question port n’est t’il pas d’utiliser des ports non standarts, je pense que cela supprimé déjà une bonne partie des attaques par robots.

moi je met par exemple du 2222 pour le SSH[/quote]
J’ai adopté cette solution pour passer les proxy d’entreprise qui en général n’autorise que le 80 & 443 au minimum. Avec cette solution j’ai 95% de chance de passer. En général il faut que je couple avec cNTML pour passer l’authentification réseau Windows.

Changer le port standard oblige l’attaquant a faire un scan des ports, donc plus visible mais pas insurmontable.

Le port knocking est un poil plus efficace que la restriction par adresse MAC des réseau Wifi. Comme dit PH, c’est de la sécurité par le secret, ça ne tient jamais longtemps. Un simple snif du réseau donne le code du knocking.

Après si on empile toutes ses mesure + une bonne sécurisation du service, même les pus parano pourraient dormir sur leurs 2 oreilles

#15

Bonjour à tous,
Je me permet de rebondir sur le sujet.
Je possède une bbox sensation “fibre” et depuis quelques mois j’ai perdu l’accès depuis l’extérieur. @presque_anonyme, as-tu configuré quelque chose de particulier notamment au niveau du pare-feu (désactivé peut être?) ?

#16

@presque_anonyme: testez votre accès ssh depuis ce site externe: http://www.infobyip.com/sshservertest.php