3 votes

Connecter le serveur Bastion SSH au serveur DB

Je veux me connecter à un serveur de base de données Linux sur un sous-réseau privé par le biais d'un serveur Bastion SSH Linux situé sur un sous-réseau public. Je veux également créer un tunnel vers le port 3306.

Lorsque j'essaie de créer la connexion SSH à partir du serveur Bastion, je reçois le message " Permission Denied (publickey) ".

ssh -L 10.0.0.10:22:10.0.1.10:22 user@10.0.1.10

Voici la sortie de débogage où il échoue :

> debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

La clé publique correcte se trouve déjà sur le serveur DB, je pense donc devoir entrer la clé privée RSA quelque part. Où dois-je entrer la clé privée ? De plus, y a-t-il des modifications à apporter à la configuration de sshd pour créer le tunnel sur 3306 ?

5voto

quanta Points 49664
client <-----> Bastion Server <-----> Database Server
                (10.0.1.10)             (10.0.0.10)

Alors, essayez ceci :

$ ssh -C -N -L 3306:10.0.0.10:3306 user@10.0.1.10

et ensuite vous pouvez vous connecter au serveur de la BD en exécutant :

$ mysql -u <user> -p -h localhost

Où dois-je entrer la clé privée ?

La valeur par défaut est ~/.ssh/ mais vous pouvez le mettre où vous voulez et le spécifier avec -i option.

Y a-t-il des changements de configuration sshd nécessaires pour créer le tunnel ? sur 3306 ?

Assurez-vous que la ligne AllowTcpForwarding est commenté ou fixé à yes .

1voto

jlp Points 401

La cause principale semble être liée aux clés ssh sur l'hôte du bastion. Si vous ne vous connectez pas à l'hôte du bastion en tant que root (et vous ne devriez pas le faire), peut-être que l'utilisateur sous lequel vous vous connectez n'a pas de répertoire personnel et essaie d'utiliser le répertoire personnel de root ? Si vous sont en vous connectant à l'hôte du bastion en tant que root, vous ne devriez probablement pas le faire.

Utilisez-vous un agent ssh sur votre hôte d'origine ? Jetez un coup d'oeil au fichier /etc/ssh/sshd_config sur l'hôte du bastion. Si AllowAgentForwarding est "no", essayez de le changer en "yes" et redémarrez sshd. Si vous n'utilisez pas d'agent ssh sur votre hôte d'origine, vous pouvez envisager de le faire car il conservera votre clé et permettra de la transférer vers des connexions ssh distantes (comme sur l'hôte du bastion).

Une autre option serait d'activer l'authentification par mot de passe sur la machine de la base de données afin qu'elle n'échoue pas lorsqu'elle ne peut pas effectuer l'authentification par clé publique. Vérifiez la présence de PasswordAuthentication dans le fichier /etc/ssh/sshd_config de la machine DB et assurez-vous qu'il n'est pas défini (la valeur par défaut est "yes") ou qu'il est défini à "yes".

Lorsque vous exécutez ssh, vous pouvez lui passer plusieurs arguments -v pour augmenter le niveau de débogage. Parfois, cela permet de montrer exactement où se situe le problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X