SSH IP port : le guide complet pour connecter et configurer vos serveurs dans les réseaux

En fait, dans n’importe quel réseau un peu sérieux, la combinaison ssh ip port revient tout le temps. Que vous administriez un serveur Linux derrière un routeur, que vous poussiez du code sur GitHub ou que vous ouvriez un accès distant pour un collègue, vous finissez par manipuler une adresse IP, un numéro de port et le protocole SSH. C’est simple en apparence, mais quand on creuse un peu la pile réseau, on voit vite pourquoi il faut comprendre comment tout ça s’emboîte.

L’adresse IP identifie la machine sur le réseau. Le port, lui, précise quel service exactement on veut joindre sur cette machine. SSH écoute par défaut sur le port TCP 22, un port « well-known » attribué depuis des lustres. Du coup, la plupart des clients essaient d’abord ce port. Mais rien n’oblige à rester là-dessus.

Comment fonctionne l’IP et le port avec SSH dans la pratique

Imaginons un serveur Ubuntu installé sur une IP privée 192.168.1.42. Sans le concept de port, cette IP ne pourrait proposer qu’un seul service à la fois. Avec les ports, la même machine peut faire tourner un serveur web sur le 443, un base de données sur le 5432 et SSH sur le 22 (ou ailleurs). C’est la couche transport TCP qui multiplexe tout ça.

Quand vous tapez une commande SSH, le client ouvre une connexion TCP vers l’IP cible sur le port indiqué. Le démon sshd de l’autre côté accepte la connexion, négocie le chiffrement et vous donne un shell. Si le port ne correspond pas, ou si le pare-feu bloque, vous avez droit à un « Connection refused » ou à un timeout. Rien de magique, juste de la mécanique réseau.

La commande exacte pour se connecter en SSH à une IP sur un port précis

Le client OpenSSH reste d’une simplicité déconcertante. Pour une connexion classique sur le port 22 :

ssh utilisateur@192.168.1.42

Si le serveur écoute sur un autre port, par exemple 2222, vous ajoutez simplement l’option -p :

ssh utilisateur@192.168.1.42 -p 2222

Ou dans l’autre ordre, ça marche aussi :

ssh -p 2222 utilisateur@192.168.1.42

Le -p est facultatif quand on reste sur le 22, mais dès qu’on change, il devient obligatoire. Et honnêtement, c’est l’une des options les plus utilisées au quotidien.

Un exemple concret qui revient souvent : GitHub propose un accès SSH sur le port 443 (celui d’HTTPS) pour contourner les firewalls d’entreprise qui bloquent le 22. Vous testez d’abord avec :

ssh -T -p 443 git@ssh.github.com

Si ça répond « Hi username ! You’ve successfully authenticated… », c’est bon. Ensuite vous pouvez configurer votre ~/.ssh/config pour que ce soit transparent :

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

Et vous continuez à faire git clone git@github.com:… sans y penser. Pratique quand le réseau sortant est verrouillé.

Changer le port SSH par défaut sur votre serveur

Beaucoup d’administrateurs changent le port 22 pour limiter un peu les scans automatisés. Les bots qui ratissent internet commencent presque toujours par le 22. Passer à 2222, 8022 ou n’importe quel port au-dessus de 1024 ralentit déjà pas mal les attaques opportunistes.

Sur un serveur Ubuntu ou Debian récent, la meilleure pratique est d’éviter de toucher directement /etc/ssh/sshd_config (qui peut être écrasé lors des mises à jour). Vous créez plutôt un fichier dans le dossier sshd_config.d :

sudo nano /etc/ssh/sshd_config.d/99-custom-port.conf

Vous y mettez simplement :

Port 2222

Puis vous rechargez la configuration sans couper les sessions existantes :

sudo systemctl reload ssh

Vérifiez que le démon écoute bien sur le nouveau port :

ss -tuln | grep 2222

Et n’oubliez pas d’ouvrir le port dans le pare-feu :

sudo ufw allow 2222/tcp
sudo ufw reload

Testez toujours depuis une autre machine avant de fermer l’ancien port. Histoire de ne pas vous retrouver coincé avec un serveur muet.

Vous pouvez aussi restreindre l’écoute à une IP précise avec la directive ListenAddress dans le même fichier de configuration. C’est utile sur une machine qui a plusieurs interfaces.

Accéder à SSH derrière un NAT ou un routeur d’entreprise

C’est le cas classique dans les réseaux informatiques réels. Votre serveur a une IP privée. De l’extérieur, vous n’avez que l’IP publique du routeur ou du pare-feu.

Solution : la redirection de port (port forwarding). Sur le routeur, vous mappez par exemple le port externe 2222 vers l’IP interne 192.168.1.42:2222 (ou :22 si vous n’avez pas changé le port interne).

Ensuite, depuis l’extérieur :

ssh utilisateur@IP-publique-du-routeur -p 2222

Le routeur fait le relais TCP. Ça marche très bien pour un accès ponctuel, mais pour un usage régulier, un VPN (WireGuard ou OpenVPN) reste souvent plus propre et plus sécurisé. Moins de ports exposés, meilleure segmentation du réseau.

Aller plus loin : sécuriser vraiment vos accès SSH

Changer le port, c’est bien, mais ce n’est qu’une couche. Les vrais gains viennent d’ailleurs :

• Authentification par clés SSH (et désactivation des mots de passe)
• Outil comme fail2ban qui bannit les IP après X tentatives ratées
• Restriction par IP source dans le pare-feu ou via AllowUsers / Match dans sshd_config
• Désactivation du login root
• Surveillance des logs /var/log/auth.log

Le point c’est que SSH est un outil formidable, mais exposé sur internet il devient une cible. Dans un réseau d’entreprise un peu mature, on préfère souvent ne pas l’exposer du tout et passer par un bastion ou un VPN.

Et si vous gérez plusieurs serveurs, le fichier ~/.ssh/config devient vite votre meilleur ami. Vous y centralisez les ports, les utilisateurs, les clés et même les sauts via des jump hosts. Plus besoin de se souvenir de « ah oui, celui-là c’est le port 2222 et l’utilisateur deploy ».

Bref, la maîtrise de la triplette IP + port + SSH vous donne un contrôle fin sur qui peut parler à quoi dans votre infrastructure. Testez, documentez vos choix de ports, et gardez toujours un accès de secours (console IPMI, KVM, ou un deuxième utilisateur avec clé). C’est comme ça qu’on dort tranquille.