L'utilisation d'une connexion VPN est le moyen le plus sûr d'accéder à un réseau si vous travaillez à distance, mais comme cette configuration peut nécessiter du matériel, du temps et des connaissances, vous devriez probablement connaître des alternatives pour le faire . L'utilisation de SSH est également un moyen sécurisé d'accéder à un réseau distant sans matériel supplémentaire, prend moins de temps et nécessite moins d'efforts que la configuration d'un serveur VPN. Dans ce blog, nous verrons comment configurer SSH Tunneling pour accéder à vos bases de données de manière sécurisée.
Qu'est-ce que SSH ?
SSH (Secure SHell) est un programme/protocole qui vous permet d'accéder à un hôte/réseau distant, d'exécuter des commandes ou de partager des informations. Vous pouvez configurer différentes méthodes d'authentification chiffrées et il utilise le port 22/TCP par défaut, mais il est recommandé de le changer pour des raisons de sécurité.
Comment utiliser SSH ?
Le moyen le plus sûr de l'utiliser consiste à créer une paire de clés SSH. Avec cela, vous n'avez pas seulement besoin d'avoir le mot de passe mais aussi la clé privée pour pouvoir accéder à l'hôte distant.
En outre, vous devez avoir un hôte avec uniquement le rôle de serveur SSH, et le garder aussi isolé que possible, afin qu'en cas d'attaque externe, cela n'affecte pas vos serveurs locaux. Quelque chose comme ça :
Voyons d'abord comment configurer le serveur SSH.
Configuration du serveur
La plupart de l'installation Linux a le serveur SSH installé par défaut, mais il y a des cas où il peut être manquant (ISO minimal), donc pour l'installer, il vous suffit d'installer les packages suivants :
Système d'exploitation basé sur RedHat
$ yum install openssh-clients openssh-serverSystème d'exploitation basé sur Debian
$ apt update; apt install openssh-client openssh-serverMaintenant que le serveur SSH est installé, vous pouvez le configurer pour n'accepter que les connexions utilisant une clé.
vi /etc/ssh/sshd_config
PasswordAuthentication noAssurez-vous de le changer après avoir mis en place la clé publique, sinon vous ne pourrez pas vous connecter.
Vous pouvez également modifier le port et refuser l'accès root pour le rendre plus sécurisé :
Port 20022
PermitRootLogin noVous devez vérifier si le port sélectionné est ouvert dans la configuration du pare-feu pour pouvoir y accéder.
Il s'agit d'une configuration de base. Il y a différents paramètres à modifier ici pour améliorer la sécurité SSH, vous pouvez donc suivre la documentation pour cette tâche.
Configuration client
Maintenant, générons la paire de clés pour l'utilisateur local "distant" pour accéder au serveur SSH. Il existe différents types de clés, dans ce cas, nous allons générer une clé RSA.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remote/.ssh/id_rsa):
Created directory '/home/remote/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/remote/.ssh/id_rsa.
Your public key has been saved in /home/remote/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hT/36miDBbRa3Povz2FktC/zNb8ehAsjNZOiX7eSO4w [email protected]
The key's randomart image is:
+---[RSA 3072]----+
| |
| .. . |
| o.+.=. |
| *o+.o.. |
| +S+o+=o . |
| . o +==o+ |
| =oo=ooo.|
| .E=*o* .+|
| ..BB ooo|
+----[SHA256]-----+Cela générera les fichiers suivants dans un répertoire appelé ".ssh" à l'intérieur du répertoire personnel de l'utilisateur :
$ whoami
remote
$ pwd
/home/remote/.ssh
$ ls -la
total 20
drwx------ 2 remote remote 4096 Apr 16 15:40 .
drwx------ 3 remote remote 4096 Apr 16 15:27 ..
-rw------- 1 remote remote 2655 Apr 16 15:26 id_rsa
-rw-r--r-- 1 remote remote 569 Apr 16 15:26 id_rsa.pubLe fichier "id_rsa" est la clé privée (gardez-la aussi sécurisée que possible), et le "id_rsa.pub" est le fichier public qui doit être copié sur l'hôte distant pour y accéder. Pour cela, exécutez la commande suivante en tant qu'utilisateur correspondant :
$ whoami
remote
$ ssh-copy-id -p 20022 [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/remote/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh -p '20022' '[email protected]"
and check to make sure that only the key(s) you wanted were added.Dans cet exemple, j'utilise le port 20022 pour SSH, et mon hôte distant est 35.166.37.12. J'ai également le même utilisateur (distant) créé dans les hôtes locaux et distants. Vous pouvez utiliser un autre utilisateur sur l'hôte distant. Dans ce cas, vous devez remplacer l'utilisateur par le bon dans la commande ssh-copy-id :
$ ssh-copy-id -p 20022 [email protected]Cette commande copiera la clé publique dans le fichier authorized_keys dans le répertoire .ssh distant. Donc, dans le serveur SSH, vous devriez avoir ceci maintenant :
$ pwd
/home/remote/.ssh
$ ls -la
total 20
drwx------ 2 remote remote 4096 Apr 16 15:40 .
drwx------ 3 remote remote 4096 Apr 16 15:27 ..
-rw------- 1 remote remote 422 Apr 16 15:40 authorized_keys
-rw------- 1 remote remote 2655 Apr 16 15:26 id_rsa
-rw-r--r-- 1 remote remote 569 Apr 16 15:26 id_rsa.pubMaintenant, vous devriez pouvoir accéder à l'hôte distant :
$ ssh -p 20022 [email protected]Mais cela ne suffit pas pour accéder à votre nœud de base de données, car vous êtes encore sur le serveur SSH.
Accès à la base de données SSH
Pour accéder à votre nœud de base de données, vous avez deux options. La méthode classique est que si vous êtes sur le serveur SSH, vous pouvez y accéder car vous êtes sur le même réseau, mais pour cela, vous devez ouvrir deux ou trois connexions.
Tout d'abord, la connexion SSH établie avec le serveur SSH :
$ ssh -p 20022 [email protected]Ensuite, la connexion SSH au nœud de base de données :
$ ssh [email protected]Et enfin, la connexion à la base de données, qui dans le cas de MySQL, est :
$ mysql -h localhost -P3306 -udbuser -pEt pour PostgreSQL :
$ psql -h localhost -p 5432 -Udbuser postgresSi le client de base de données est installé sur le serveur SSH, vous pouvez éviter la deuxième connexion SSH et simplement exécuter la connexion à la base de données directement depuis le serveur SSH :
$ mysql -h 192.168.100.120 -P3306 -udbuser -pou :
$ psql -h 192.168.100.120 -p 5432 -Udbuser postgresMais, cela pourrait être ennuyeux car vous utilisiez la connexion à la base de données directement depuis votre ordinateur connecté au bureau, alors voyons comment utiliser le tunnel SSH pour cela.
Tunnel SSH
Suivant le même exemple, nous avons :
- Adresse IP publique du serveur SSH :35.166.37.12
- Port du serveur SSH :20022
- Adresse IP privée du nœud de base de données : 192.168.100.120
- Port de la base de données :3306/5432
- Utilisateur SSH (local et distant) :distant
- Utilisateur de la base de données :dbuser
Ligne de commande
Donc, si vous exécutez la commande suivante sur votre ordinateur local :
$ ssh -L 8888:192.168.100.120:3306 [email protected] -p 20022 -NCela ouvrira le port 8888 sur votre machine locale, qui accédera au nœud de base de données distant, port 3306, via le serveur SSH, port 20022, en utilisant l'utilisateur "distant".
Donc, pour que ce soit plus clair, après avoir exécuté cette commande, vous pouvez accéder au nœud de base de données distant, en l'exécutant sur votre ordinateur local :
$ mysql -h localhost -P8888 -udbuser -pOutils graphiques
Si vous utilisez un outil graphique pour gérer les bases de données, il a très probablement la possibilité d'utiliser le tunnel SSH pour accéder au nœud de la base de données.
Voyons un exemple utilisant MySQL Workbench :
Et pareil pour PgAdmin :
Comme vous pouvez le voir, les informations demandées ici sont assez similaires à celles utilisées pour la connexion de tunnel SSH en ligne de commande.
Conclusion
La sécurité est importante pour toutes les entreprises, donc si vous travaillez à domicile, vous devez garder les données aussi sécurisées que vous l'êtes lorsque vous travaillez au bureau. Comme nous l'avons mentionné, pour cela, la meilleure solution est probablement d'avoir une connexion VPN pour accéder aux bases de données, mais si pour une raison quelconque ce n'est pas possible, vous devez avoir une alternative pour éviter de traiter les données sur Internet de manière non sécurisée. Comme vous avez pu le constater, configurer SSH Tunneling pour accéder à vos bases de données n'est pas sorcier et constitue probablement la meilleure alternative dans ce cas.
