Vagrant sur Buster

Support Debian
#1

Bonjour,

J’utilise une machine Debian Buster qui me permet de créer des VM virtualBox à l’aide de Vagrant. J’ai créé une boîte Vagrant Buster et je génère ainsi des VM Debian Buster alimentés automatiquement en applications. J’ai depuis peu généré des VM Debian Bullseye mais à la fin je reçois un message d’erreur:

=> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

cat /proc/modules

Stdout from the command:



Stderr from the command:

La machine est bien créée mais le dossier de partage /vagrant qui apparaît dans la config de l’hyperviseur n’est pas accessible.

Pour info j’obtiens les mêmes erreurs avec un vagrant up.

Quelqu’un a t’il déjà rencontré ce type de problème ? Faut-il que je passe mon poste hôte en Bullseye ?

Merci de vos réponses :wink:

#2

Oui, c’est sur @clochette. Je viens de passer de Debian 10 à Debian 11 et plus moyen de prendre à distance mon bureau (écran noir avec le curseur de la souris) avec la commande rdesktop.

Difficultés pour MAJ de Debian (Source List)
#3

Tu utilises XRDP sur la cible?

#4

Oui @Zargos. Je n’arrive toujours pas à prendre le bureau à distance de ma Debian Bullseye mais par contre j’arrive à prendre à distance les machines virtuelles VirtualBox en mode graphique.

#5

et coté parefeu?

#6

Je pense ne pas avoir de pare feu d’installé. Le problème viendrait du côté d’openssh. J’arrive parfois (très rarement) à me connecter en ssh d’un côté (Debian stretch) ou de l’autre (Debian Bullseye) mais pas en mode graphique et uniquement en passant par la saisie d’un mot de passe (clefs ssh non acceptés).

#7

Comme tu peux le voir cela pollue le fil original je viens de déplacer la discussion vers ce fil qui me semble bien plus approprié.

#8

Merci @clochette. Je ne pense pas que mes réponses pollue le fil original car pour informations mes problèmes de clefs ssh apparaissent suite à une évolution de Buster vers Bullseye sur le deuxième poste que je souhaite prendre à distance avec un poste en Stretch. De tout évidence, j’aurais du le préciser ou être plus vigilant sur les questions au style chat.

Probablement même que la suite de cette discussion conduira vers l’ouverture d’un autre sujet (problème de compatibilité de versions Linux ou problèmes entre versions d’OpenSSH ?) tout en permettant d’avancer sur ma problématique Vagrant mais les problèmes semblent liés.

Pour l’instant il est trop tôt pour faire clairement la part des choses même si ssh a manqué de politesse :grinning: en m’envoyant des messages comme quoi il y avait trop de tentatives de connexions depuis mes derniers essais d’hier soir. Je vais revenir à un dossier .ssh avec le minimum pour tenter de revenir sur une base d’investigation plus adaptée…

Pour avancer sur le sujet et tenter de résoudre mon problème initial, j’aimerai connaître dans un premier temps si la prise à distance d’un poste avec ssh sous Stretch ou Buster vers ou depuis Bullseye a déjà été effectuée avec succès à l’aide d’un jeu de clefs SSH par d’autres membres et si oui quels étaient les points délicats rencontrés en cours de route. Qu’en est-il de la compatibilité des clefs générés sur une version de Debian ou une autre ? Dans un parc de machines hétérogènes au niveau des versions Debian, quels problématiques les admins en poste rencontrent-ils avec les clefs ssh pour la prise à distance ?

#9

Mais concrètement il y a quoi dans les logs ? ce ne serait pas un souci de permissions pour le stockage des clés tout simplement ou la connexion par mots de passe ne fonctionne pas non plus ?

#10

Quand on fait une migration de stretch vers bullseye, il y a des clefs et des certificats autosignés qui peuvent être de nouveau générés. ou des configurations écrasées.