SSH

OpenSSH est une version libre de la suite de protocole de SSH, des outils de connectivité de réseau sur lesquels un nombre croissant de personnes sur l'Internet viennent s'appuyer. Beaucoup d'utilisateurs de Telnet, Rlogin, FTP, ou d'autres programmes identiques, ne se rendent pas compte que leur mot de passe est transmis à travers les réseaux en clair. OpenSSH chiffre tout le trafic (mots de passe y compris). OpenSSH fournit également une variété de méthodes d'authentification. Comme son nom l'indique, OpenSSH est développé dans le cadre du projet OpenBSD

Si vous voulez accéder à votre PC depuis un autre endroit vous devez le transformer en serveur au préalable.

installez le paquet openssh-server sur votre poste.

Par défaut, il se lance au démarrage.

Pour l'activer après une fausse manipulation :

sudo /etc/init.d/ssh start

Pour l'arrêter :

sudo /etc/init.d/ssh stop

Sur le poste client (qui va prendre l'accès à distance) openssh-client installé par défaut sous Ubuntu doit être présent. Si vous devez prendre le contrôle sur un poste équipé de Windows vous pouvez installer PuTTY qui est disponible sous licence MIT (type BSD).

Pour copier un fichier à partir d'un ordinateur sur un autre avec SSH, vous devrez utiliser la commande scp. Cela ressemblera à ceci :

scp <fichier> <username>@<ipaddress>:<DestinationDirectory>
scp -6 <élément> <nom>@[addresse ipv6]:<destination>  

Ou en termes profanes, si je désirais copier un fichier d'un de mes ordinateurs à l'autre, je procède de cette manière :

scp fichier.txt hornbeck@192.168.1.103:/home/hornbeck 
scp -6 fichier.txt albertine@[2a01:e35:2431::2a34]:/home/albertine 

Ou copier un répertoire vers un ordinateur :

scp -r répertoire hornbeck@192.168.1.103:/home/hornbeck/
scp -6r répertoire/ albertine@[2a01:e35:2431::2a34]:/home/albertine 

Vous pouvez aussi bien copier des fichiers à partir des ordinateurs à distance sur votre disque local :

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt .

Le point à la fin de commande indique de copier le fichier dans le répertoire courant. Vous pouvez aussi le renommer en le copiant (« mon.txt ») sur le disque local :

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt ./mon.txt

Vous pouvez très bien copier un fichier d'un ordinateur vers un autre tout en étant sur un troisième ordinateur :

scp nom@ordi1:chemin/fichier nom@ordi2:chemin/fichier

En utilisant le navigateur de fichier Nautilus, vous pouvez également accéder aux emplacements à distance par l'intermédiaire de SSH pour passer en revue, éditer et copier, des fichiers. Ouvrez Nautilus, puis dans la fenêtre emplacement (Ctrl–L), entrez l'URL suivante (remplacez username, hostname et port en conséquence) :

 ssh://username@hostname:port

La copie de fichier se fait avec le glisser-déposer dans la fenêtre de Nautilus comme sur votre système de fichier local.

Pour accéder directement à un répertoire donné (pratique avec l'utilisation des signets), il suffit de rajouter le chemin en fin d'URL :

 ssh://username@hostname:port/le/chemin/voulu/

Il est également possible d'y avoir accès dans Nautilus par : fichier > se connecter à un serveur et choisir type de service : ssh.

Le principe est similaire à celui utilisé par Nautilus, à l'exception du nom de protocole : fish. Dans la barre d'adresse, tapez :

fish://<username>@<hostname>

Une boite de dialogue apparaitra et demandera le mot de passe.

Attention, si vous ne mentionnez pas le nom d'utilisateur, c'est l'utilisateur courant sur la machine locale qui aura la main.

Pour pouvoir parcourir vos fichiers accessibles par SSH, il vous faut monter un système de fichier. Visitez la doc prévue à cet effet : SSH Filesystem.

Remarque : cette méthode permet aussi d'y accéder de manière transparente avec Nautilus ou Konqueror sans utiliser les adresses spéciales précédentes.

Parce qu'il est parfois nécessaire de faire un transfert de fichier à partir d'une machine sous MS Windows, il existe un logiciel libre nommé WinSCP qui permet de faire du SFTP (transfert de fichier par SSH) avec une interface semblable à celle des clients FTP.

Site officiel du logiciel WinSCP

Sans avoir à chercher trop loin, FileZilla, le client FTP compatible Linux, Windows et Mac OS X, permet aussi la connexion à un serveur SFTP (SSH File Transfer Protocol) depuis la version 3.

sshfs est un outil permettant d'utiliser le protocole ssh comme un système de fichier et ainsi monter un répertoire distant à travers le protocole ssh. Pour l'utiliser il vous suffit, pour cela, d'installer le paquet sshfs

sshfs <username>@<ipaddress>:/RepertoireDistant /Emplacement de montage

Pour ouvrir une session sur un ordinateur distant ayant un serveur SSH, vous devez écrire quelque chose comme ceci :

ssh <username>@<ipaddress> -p <num_port>

Exemple

ssh phyrex@192.168.23.42 -p 12345

L'option -p xxx est facultative. Si rien n'est précisé, c'est le port 22 par défaut qui sera utilisé.

Pour se connecter avec ssh en ipv6 depuis un terminal, écrire sans crochet

ssh -6 <nom>@<adresse ipv6> 

soit par exemple pour un lien internet:

ssh -6 alfred@2a01:e35:2431::2e57

ssh utilisateur@nom_machine

Il peut arriver (en entreprise, dans un cyber…) qu'il y ai un proxy http. Pour initier une connexion vers un poste de l'extérieur il est nécessaire d'utiliser l'outils connect-proxy.

Installer le paquet apt://connect-proxy

éditer le fichier ~/.ssh/config pour y ajouter les adresses ip exterieur:

host ip_du_pc_distant
ProxyCommand /usr/local/bin/connect -H adresse.du_proxy:port %h %p

Remplacer ip_du_pc_distant et adresse.du_proxy:port par si qui convient. Vous pouvez maintenant vous connecter à travers votre proxy en toute transparence, avec la commande ssh.

L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.

Suite à l'installation du paquet openssh-server il peut parfois être nécessaire de modifier le fichier de configuration « sshd_config » notamment si vous rencontrez le problème suivant :

moi@maison:~$ ssh user@domain.com
Permission denied (publickey).

Dans ce cas, il faut très basiquement modifier le fichier « /etc/ssh/sshd_config » de la manière suivante :

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes

Puis en cas de modifications, redémarrer le service avec la commande :

sudo /etc/init.d/ssh restart

Autrefois tout le monde employait l'authentification typique via identifiant-mot de passe. Cependant si quelqu'un connaît votre mot de passe, la sécurité est compromise.

Pour être débarrassé du problème, SSH offre l'Authentification par clé publique/privée au lieu des mots de passe « simples ». De cette manière, il faut être en possession de non plus une mais de deux informations pour se connecter (avoir la clé privée & connaître le mot de passe de cette clé).

Ceci peut permettre par exemple :

• à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
• de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant ssh-agent).

À moins que vous n'ayez déjà un couple de clés, vous devez d'abord en créer : exemple pour une clé utilisant le protocole de cryptage DSA. Tapez chez le client :

ssh-keygen -t dsa

Il vous sera alors demandé où sauver la clé privée (acceptez juste l'endroit par défaut : ~/.ssh, et ne changez pas le nom) puis de choisir une passphrase. Bien que non obligatoire, l'utilisation d'une passphrase est recommandé pour protéger votre clé privée. En effet toute personne qui obtiendrait l'accès à votre clé privée (non protégée) aurait alors vos permissions sur d'autres ordinateurs. Veuillez prendre un instant et choisissez une très bonne passphrase.

Votre clef publique a été créée avec la nouvelle clé privée. Elles sont habituellement localisées dans le dossier caché : « ~/.ssh/id_dsa.pub » pour la clé publique et « ~/.ssh/id_dsa » pour la clé privé.

Il faut maintenant envoyer au serveur votre clé publique pour qu'il puisse vous crypter des messages.

L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clé d'autorisation situé à « ~/.ssh/authorized_keys » sur le système distant. Employez la commande ssh-copy-id.

ssh-copy-id est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur. L'authentification par mot de passe "PasswordAuthentication yes" doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur ubuntu). Il change également les permissions des répertoires : ~/.ssh, et ~/.ssh/authorized_keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration, ce qui est le cas par défaut sur ubuntu).

ssh-copy-id -i ~/.ssh/id_dsa.pub <username>@<ipaddress>

ou si le port est différent du port standard 22

ssh-copy-id -i ~/.ssh/id_dsa.pub "-p <num_port> <username>@<ipaddress>"

Vous devrez alors donner le mot de passe utilisateur de cet ordinateur. Après que votre clé publique ait été ajoutée, vous devenez un hôte de confiance.

Si l'authentification par mot de passe est désactivée, alors vous aurez besoin de copier-coller votre clé suivant un autre moyen.

Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :

ssh login@serveur "echo $(cat ~/.ssh/id_dsa.pub) >> .ssh/authorized_keys"

Lancez :

ssh <username>@<ipaddress> -p <num_port>

Dorénavant n'utilisez plus votre mot de passe mais votre passphrase pour vous connecter. Il y a une différence entre votre mot de passe et la passphrase. Le mot de passe est situé dans /etc/passwd du système distant alors que la passphrase sert à déchiffrer votre clé privée de votre système local.

Si ça ne marche pas, c'est à dire que le mot de passe vous est quand même demandé, essayez sur votre serveur la commande :

tail -f /var/log/auth.log

tandis que vous essayez de vous connecter. Si on vous parle de "vulnkey", c'est que par malchance ssh-keygen a généré une clé vulnérable. Recommencez alors la manipulation à partir de ssh-keygen…

Pour reprendre, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé ) par authentification à clé publique par rapport à l'authentification par mot de passe classique :

1. Votre clé privée, chiffrée ;
2. Votre passphrase, utilisée pour déchiffrer votre clé privée.

Si vous choisissez de ne pas avoir de mot de passe (ce qui est possible, voyez la prochaine section), vous aurez une sécurité moindre, ainsi que si vous utilisez une authentification uniquement par mot de passe, comparé à celle que vous pouvez avoir en combinant les deux.

sudo /etc/init.d/ssh restart

tail /var/log/auth.log

Authentication refused: bad ownership or modes for directory /home/votre_login

chmod 755 $HOME

server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys

Lorsque que l'on se connecte à plusieurs serveur, certains avec clé cryptée, d'autre avec clé en clair, il faut pouvoir indiquer à ssh quelle clé on veut utiliser pour la connexion.

Pour indiquer au client ssh la clé qu'il doit utiliser pour chacun des serveurs il faut créer le fichier ~/.ssh/config (ou /etc/ssh/ssh_config pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :

Host adresse-server-sans-passphrase.com
IdentityFile ~/.ssh/key-sans-passphrase

Host adresse-server-avec-passphrase.com
IdentityFile ~/.ssh/key-avec-passphrase

Quand on utilise SSH avec l'authentification par clé, il y a d'autres dispositions. Le serveur distant peut limiter l'utilisation de certaines commandes permises. Si vous maintenez un dépôt CVS, vous pourriez utiliser des lignes comme ceci dans le fichier « authorized_keys2 » :

command="/usr/bin/cvs server" ssh-dss AAAAB3N....

Ceci permettrait que seule cette commande puisse être utilisée. Rien d'autre.

L'authentification par clé publique (voir ci-dessus) peut également être employée pour automatiser les tâches qui exigeraient habituellement l'introduction au clavier d'un mot de passe. Imaginez vouloir copier un dossier à partir d'un ordinateur distant tous les jours à minuit. Tout ce que vous avez à faire c'est d'établir la confiance entre ces deux ordinateurs. Créez un compte de service sur un ordinateur, créez une paire de clé (ssh-keygen -t dsa) et quand on vous demande de rentrer la passphrase taper juste sur la touche « Entrée ». Ceci fera que votre clé privé ne sera pas protégée. Ajoutez la clé publique de l'autre ordinateur dans le fichier « authorized_keys » (« ssh-copy-id »). Maintenant vous pouvez utiliser SSH sur cette machine sans une passphrase à taper. Ajoutez une référence à SSH dans votre crontab et vous êtes prêt.

Si vous devez fréquemment copier des fichiers avec SSH ou accéder à d'autres ordinateurs de votre réseau (ce qui est une tâche commune pour des administrateurs), vous vous demandez probablement s'il y a une manière de simplifier l'utilisation de la passphrase. En fait il y a SSH agent. Vous devez seulement entrer votre passphrase une fois en employant ssh-add et tout ce que vous commencez comme sous-processus de SSH agent se rappellera cette passphrase.

Trop théorique ? Bien, vous n'aurez pas besoin de vous inquiéter de l'agent. Votre session X est prête pour avoir le ssh-agent en session automatiquement. Tout ce que vous devez faire c'est lancer ssh-add et saisir votre passphrase. La prochaine fois que vous utiliserez SSH pour accéder à un autre ordinateur, vous n'aurez pas à entrer à nouveau votre passphrase. Cool, non ?

Par défaut, la configuration du serveur SSH (fichier « /etc/ssh/sshd_config », édition via sudo comme il se doit) d'Ubuntu est suffisante :

PermitRootLogin yes

Si ce n'était pas sous Ubuntu ce serait une très grosse faille de sécurité, mais qui pourrait vouloir affecter un mot de passe à root ?

#Banner /etc/issue.net

Vous pouvez décommenter (c'est-à-dire enlever le « # ») cette ligne. Effet : lorsque vous essayez de vous connecter à votre serveur par SSH, le fichier « /etc/issue.net » est affiché (à vous de le personnaliser).

#MaxStartups 10:30:60

Vous pouvez aussi décommenter cette ligne, effet : le 10 représente le nombre de connexions acceptées sans qu'un utilisateur ait réussi à s'identifier, si cela passe au dessus de 10, il y a 30 % de chances que les suivantes soient bloquées, et ce pourcentage augmente linéairement jusqu'à 100 % lorsque le full est atteint, à 60 connexions. Très utile pour éviter ce genre de désagrément.

AllowUsers alice bob

Ligne à ajouter, spécifie les logins des seuls utilisateurs (ici seuls Alice et Bob, pas Carole) autorisés à se connecter. Idéal pour ouvrir un compte FTP à un ami tout en restreignant l'accès au Shell via SSH.

PasswordAuthentication no

Passez de "yes" à "no" pour interdire l'utilisation du mot de passe et forcer l'usage de jeux de clefs public/privé (plus sûr).

Vous pouvez :

• utiliser MySecureShell (s'installe en plus de openssh-server),
• simplement le mode natif de openssh,
• Suivre ce tutorial qui limite l'utilisation du ssh au sftp pour des utilisateurs donnés sftp avec openssh et AppArmor (en).

Tunnéliser sa connexion web est très utile dans quelques situations :

• l'admin du réseau où vous êtes vous empêche d'accéder à certains sites ;
• votre connexion web est peu ou pas sécurisée (wifi sans encryption ou par encryption wep).

On va donc installer le serveur de médiation Squid (serveur proxy, mandataire) sur une machine Ubuntu (qui sera le serveur) à laquelle on accèdera par une machine distante possédant un client SSH et un navigateur Web. Dans l'exemple présent, ce sera un client sous Windows.

On obtiendra alors un accès sécurisé à un proxy distant (le serveur sous Ubuntu) qui se connectera aux sites web et renverra le résultat à votre navigateur.

Premièrement, il faut installer le programme Squid. Le paquet à installer est squid.

Normalement si tout se déroule bien, Squid devrait être fonctionnel. Il est probable qu'une erreur arrive car le programme de configuration n'arrivera pas à trouver le nom d'hôte de la machine. Il faut donc ouvrir le fichier de configuration de Squid et lui indiquer que la machine n'a pas de nom d'hôte. On ouvre le fichier de configuration « /etc/squid/squid.conf » et on ajoute cette ligne :

visible_hostname none

Après l'enregistrement du fichier de configuration, vous pouvez normalement générer les répertoires qui contiendront le cache de Squid par la commande :

sudo squid -z

Grâce à SSH, les connexions reçues par Squid seront des connexions provenant du serveur lui-même. Mais par défaut, Squid n'accepte que les connexions loopback. On devrait alors quand même ajouter une autorisation pour l'adresse IP non loopback (127.0.0.1) du serveur. Vous ouvrez donc le fichier de configuration et vous ajoutez ces deux lignes :

acl ordi src 192.168.1.1
http_access allow ordi

Dans l'exemple, « ordi » est le nom que j'ai donné à la règle et « 192.168.1.1 » est l'adresse IP locale de mon ordinateur. Vous pouvez donc maintenant démarrer Squid par :

sudo squid start

ou le redémarrer par

sudo squid reload

Squid est normalement prêt à recevoir les connexions venant de la machine hôte.

La partie précédente consiste à installer un proxy HTTP sur le serveur et de s'y connecter via SSH. Cependant, SSH lui-même peut jouer le rôle de proxy, ce qui évite l'installation d'un logiciel supplémentaire.

Il n'y a en principe rien à faire. Cette fonctionnalité est activée par défaut sous Ubuntu.

Cette fois, le proxy est de type SOCKS (à prendre en compte lors de la configuration du navigateur)

La configuration est la même que dans la partie précédente, sauf qu'il faut cocher la case "dynamic". La case "destination" n'est pas prise en compte et peut rester vide.

Utiliser la commande ssh avec l'option -D :

# Ouverture d'un tunnel ssh (sur le port 1234 local) vers un serveur qui autorise la connexion
# le port (1234 dans cet exemple) est choisi arbitrairement, tant qu'il n'est pas utilisé pour autre chose
ssh -D 1234 monuser@monserver.net

Configurer ensuite le navigateur, gestionnaire de courrier, …., pour utiliser un proxy type SOCKS 5, adresse: localhost, port: 1234 (selon ce que vous avez utilisé ci dessus)

La connexion fonctionnera tant que le tunnel restera ouvert (si vous fermez le terminal ayant servi à ouvrir le tunnel, vous fermerez le tunnel…) Pour vous assurer que le tunnel remplit son office, affichez une page telle que http://www.monip.org et constatez que l'IP affichée n'est pas la même que lorsque vous naviguez sans proxy.

Il est intéressant de pouvoir accéder à des ressources réseau locales (RDP, VNC, Administration périphérique réseau comme les box etc…) sans pour autant rendre ces périphérique directement accessibles depuis internet. SSH permet l'accès à ces ressources comme si on était en local (une sorte de VPN).

Je vais prendre un exemple.

Donc nous avons un réseau avec une machine sous Windows (XP, Vista…) avec comme adresse locale 192.168.1.2 où TSE est activé mais accessible uniquement en local, un serveur ssh sous ubuntu avec comme IP locale 192.168.1.3, et une Livebox (où autre) dont seul le port ssh (22) est natté pour un accès au serveur ssh depuis l'extérieur.

Nous voulons depuis l'extérieur accéder à la machine Windows via RDP.

Nous allons pour cela utiliser la tunélisation. À partir de votre station depuis l'extérieur on va tunéliser la connexion RDP de la station Windows au travers du serveur ssh :

$ ssh -L 3389:192.168.1.2:3389 username@IP_Publique_Box

Il suffit ensuite d'ouvrir le Terminal serveur client sur votre machine et de se connecter à localhost.

Nous pouvons de la même façon accéder à la configuration de notre Box sans pour autant devoir la rendre accessible depuis internet (attention seul root peut forwarder le port 80) :

# ssh -L 80:192.168.1.1:80 username@IP_Publique_Box

Puis en ouvrant son navigateur préféré et en entrant comme adresse http://localhost

Section éditée par : Havany

Si vous avez un délai de plusieurs secondes avant que la connexion SSH ne se fasse, essayez d'ajouter ceci à votre fichier ~/.ssh/config

GSSAPIAuthentication no

Ceci désactive l'identification par GSSAPI qui engendre parfois des délais lorsqu'elle n'est pas utilisée. (Source : http://www.refreshinglyblue.com/2007/5/18/long-delay-before-ssh-authentication)

Le 14 mai 2008, une mise à jour de sécurité de ssh dans les dépôts signale qu'une vulnérabilité a lieu dans le générateur de nombres aléatoires pour générer les clés. Il faut donc regénérer ses clés après avoir fait la mise à jour et redémarré. Vu que la mise à jour regénère automatiquement les clés pour la machine, il ne reste plus qu'à modifier les clés persos (pour les users) après un reboot.

Sur les pc clients :

rm ~/.ssh/known_hosts

Sur les pc serveurs :

rm ~/.ssh/authorized_keys

Puis, pour une authentification par clés, à partir du poste client :

ssh-keygen -t dsa
scp ~/.ssh/id_dsa.pub leserveur:.ssh/authorized_keys

Pour vérifier: Installer openssh-blacklist et openssh-blacklist-extra.

ssh-vulnkey

Si aucune clé n'est COMPROMISE, c'est ok :)

Retrouver l'empreinte de notre clef ssh, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :

$ ssh-keygen -l

Ensuite la commande demande le fichier de la clef publique. Sur un serveur on spécifiera /etc/ssh/ssh_host_rsa_key.pub.

En limitant l'accès aux personnes se connectant depuis un domaine de votre choix (déclaré via DynDNS ou autre…)

Un peu de sécurité dans ce monde de brutes…force.

En fait une fonction assez intéressante pour la sécurité de vos serveurs SSH existe, elle permet d'autoriser la connexion uniquement à des utilisateurs et/ou domaines prédéfinis. (J'entends certains chuchoter IP spoofing mais bon, il faut déjà savoir quelle IP est autorisée à se connecter, et de toute façons il faut encore faire du brut force ensuite… Rien n'est jamais parfait mais ça introduit tout de même un bon gain de sécurité.)

La problématique est que seules les IP semblent être acceptées par le démon de connexion SSH, dans le cas ou vous avez une IP dynamique ça limite un peu…

Du coup on va utiliser un petit script pour vérifier l'adresse IP correspondante à un nom de domaine (il faut évidement que votre IP dynamique soit associée à un nom de domaine par DynDNS par exemple.)

Le script réalise les tâches suivantes :

• Vérification de l'adresse IP correspondant au nom de domaine
• Comparaison avec l'adresse déjà inscrite dans /etc/ssh/sshd_config
• En cas de changement, modification de la dernière ligne du fichier /etc/ssh/sshd_config pour autoriser les connexions depuis la nouvelle adresse IP et depuis le réseau local et redémarrage de sshd pour rendre le changement de configuration effectif. (N'ayez crainte, les connexions déjà établies ne seront pas interrompues.)

sudo crontab -e

*/5 * * * * /usr/local/bin/SSH_IP_allow.sh

Le script SSH_IP_allow.sh (à placer dans /usr/local/bin/) : N'oubliez pas d'inscrire votre nom de domaine à la place de "*Votre nom de domaine ici*"

#!/bin/bash
 
# SSH_IP_allow.sh V0.12
# Par Mysteroïd 12/02/2009
 
# Script offert à la communauté Unbuntaise voir Linuxienne...
# Sans aucunes garanties, à utiliser en sachant ce que vous faites et à vos risques et périls.
# Et j'espère évidemment que ça vous rendra service à vous aussi... ;)
 
mkdir /tmp &>/dev/null
 
# Enregistre l'adresse IP (résultat de arp) dans getip.tmp
sudo arp ***Votre nom de domaine ici***> /tmp/getip.tmp
 
# Récupère la première ligne comme arguments $1,$2,...
set `head -1 /tmp/getip.tmp`
# Récupère l'IP
IP_DISTANTE="`echo $2 | tr -d ["()"]`"
# Dernière ligne du fichier sshd_config
L="`tail -1 /etc/ssh/sshd_config`"
# Nouvelle ligne (à inscrire si IP distance changée depuis fois précédente)
L2="AllowUsers *@$IP_DISTANTE *@192.168.*"
 
# Si pas de changement de ligne (par rapport à l'IP indiquée dans le ficher de configuration)
if [ "$L" = "$L2" ]; then
	echo "Pas de changements d'IP..."
else
	# Enlève la dernière ligne si elle débute par AllowUsers
	if [ "${L:0:10}" = "AllowUsers" ] ; then
		set `wc -l /etc/ssh/sshd_config`
		head -$(($1-1))	/etc/ssh/sshd_config > /tmp/sshd_config
		mv /etc/ssh/sshd_config /etc/ssh/sshd_config.old
		cat /tmp/sshd_config > /etc/ssh/sshd_config
	fi
	# Ajoute les utilisateurs autorisés...
	echo $L2 >> /etc/ssh/sshd_config
	echo "Utilisateurs / hôtes autorisés à se connecter en SSH :"
	echo -e "${L2:11}\n"
	echo "Redémarrage du serveur SSH"
	sudo /etc/init.d/ssh restart
fi
exit 0

ls -l /tmp/getip.tmp

tail -1 /etc/ssh/sshd_config

Modifications envisageables :

• Limitation des utilisateurs autorisés et pas seulement des domaines, en utilisant le format utilisateur@domaine dans sshd_config au lieu de *@domaine.
• Utilisation de plusieurs domaines distants autorisés avec écriture.
• Pour des serveurs très utilisés type entreprise avec de multiples personnes susceptible de s'en servir, possibilité de lancer le script par cron de façon très fréquente jusqu'à chaque seconde pour réduire au maximum les délais d'accès au serveur en cas de changement d'IP des clients.
• Récupérer l'IP sans passer par l'enregistrement du fichier getip.tmp, ça rend la vérification du travail du script un peu moins évidente mais ça évite les petits accès disque, surtout en cas de lancement du script à fréquence rapide type une seconde.
• Archivage des IP autorisées
• Certainement bien d'autres choses encore, à vous d'imaginer la suite…

Concernant la partie "Sécurisons … encore plus" UNIQUEMENT : Si besoin contactez moi via la page Mysteroïd, de même que ça me fera plaisir de savoir si le script vous rend service…

nano ~/.ssh/config

ServerAliveInterval 3
ServerAliveCountMax 20

Bon SSH à tous !

• Tuto. Chrooter un utilisateur en ssh facilement.
• Config. Configuration et sécurisation de ssh.