Partir de la réponse réelle

Ce guide concerne l’interface RDP de rdp-cli 0.1.0 sous Windows, macOS et Linux. Il repose sur des vérifications de connexion et d’Agent de septembre 2026, sans nouveau test de serveurs. Utilisez un serveur Windows RDP autorisé et la version actuelle pour votre client. Les exemples utilisent rdp-cli dans PATH ; sous Windows, employez .\rdp-cli.exe depuis son dossier et sous Linux la commande installée ou l’exécutable téléchargé.

rdp-cli --version
rdp-cli list
rdp-cli status --session SESSION

Remplacez SESSION par votre identifiant reçu. En cas d’échec, lisez error.code, error.message et error.retryable. Dans un état réussi, consultez data.connection_state, data.control_state, data.last_error s’il existe et data.capabilities. Une indication de nouvelle tentative n’autorise pas à rejouer une saisie.

Vérifier chaque étape de connexion

Erreur Vérification et action
CONNECT_TIMEOUT / RDP_CONNECT_FAILED Vérifiez l’hôte, le port configuré (généralement 3389), le trajet LAN/VPN et le service RDP. Faites contrôler l’écoute et la règle autorisée du pare-feu par l’administrateur. Un port accessible ne prouve pas une connexion RDP réussie. Réessayez une fois après correction.
RDP_TLS_HANDSHAKE_FAILED Examinez la configuration TLS du serveur. Le profil par défaut modern exige TLS 1.2. Réservez --tls-profile legacy à un ancien serveur identifié sur un réseau de confiance : il permet une cryptographie ancienne. Ne l’appliquez pas partout et ne désactivez pas la sécurité du serveur pour réussir un test.
CERTIFICATE_UNTRUSTED Avec --cert-policy strict, vérifiez le nom et la chaîne de certificats, ou comparez l’empreinte SHA-256 avec l’administrateur avant un enregistrement de confiance précis. Le défaut actuel ignore ne vérifie pas l’identité. Ne basculez pas uniquement pour masquer une erreur strict.
AUTH_FAILED Contrôlez utilisateur, compte local ou de domaine, --domain et droit d’ouverture de session distante. Utilisez la saisie de mot de passe ou la référence enregistrée du démarrage rapide. Évitez les essais répétés : un échec TLS ou un hôte inaccessible ne prouvent pas un mauvais mot de passe.

Connecté, mais sans image exploitable

Exécutez cette lecture et ouvrez le PNG indiqué par data.path. connected signifie que RDP est activé et qu’une image cohérente a été reçue. Elle peut montrer l’identification, l’accueil ou un écran noir ; le bureau n’est pas forcément prêt.

rdp-cli screenshot --session SESSION

Pour FRAME_UNAVAILABLE, consultez l’état et error.retryable, laissez la reconnexion ou le changement d’affichage se stabiliser, puis capturez à nouveau. Si l’image reste noire, vérifiez le serveur, la mise en veille du client et le VPN. Les cas historiques avaient des causes différentes ou non établies. Ne saisissez pas d’identifiants dans une cible invisible et n’assimilez pas toute image fixe à un protocole bloqué.

Résoudre les erreurs de saisie et de droits

  • OBSERVATION_REQUIRED : capturez et lisez une nouvelle image, puis utilisez son data.observation. Renouvelez-le après reconnexion, reprise en main ou changement d’affichage.
  • SESSION_PAUSED, CONTROL_HELD_BY_HUMAN ou CONTROL_NOT_OWNED : arrêtez la saisie et respectez le contrôleur actuel. Reprenez seulement après une restitution autorisée, puis capturez à nouveau ; ne contournez pas la pause avec un autre visualiseur.
  • PERMISSION_DENIED / CAPABILITY_UNAVAILABLE : vérifiez la capacité et l’autorisation. Un visualiseur n’active pas une fonction absente du serveur. UNICODE_INPUT_UNAVAILABLE exige une méthode prise en charge, pas des tentatives aveugles.

Vérifier une action au résultat incertain

Avant une saisie dont le résultat pourrait nécessiter une récupération, définissez et conservez un --request-id unique par action distincte ; remplacez les identifiants d’exemple par vos propres valeurs. Si un JSON d’erreur arrive, gardez son champ request_id de premier niveau ; si toute la réponse est perdue et qu’aucun identifiant initial n’a été conservé, n’en inventez pas un pour consulter l’ancienne action et ne la répétez pas à l’aveugle.

Après REQUEST_TIMEOUT ou SERVICE_UNAVAILABLE pendant une action, conservez l’identifiant initial. Vérifiez le service local avec list, puis interrogez l’opération avant de réessayer. La saisie peut avoir été envoyée malgré une réponse perdue.

rdp-cli operations status --session SESSION --request-id REQUEST_ID
rdp-cli status --session SESSION
rdp-cli screenshot --session SESSION

Remplacez REQUEST_ID par la valeur initiale, pas l’identifiant de la consultation. Vérifiez data.state, le data.result conservé et une capture récente. OPERATION_NOT_FOUND peut signifier une expiration ou un changement de service ; il ne prouve pas l’absence d’exécution. Après correction, un reconnect explicite sur une session non fermée la laisse en pause. SESSION_CLOSED nécessite une nouvelle connexion autorisée, pas des reconnexions répétées.

Poursuivre avec les bons éléments

Si le problème persiste, fournissez versions client/serveur, protocole, heure, code et état/capture sans données sensibles. Retirez mots de passe, jetons et contenu privé. Ce guide ne valide pas la compatibilité ou la stabilité prolongée de tous les serveurs.

Télécharger · Démarrage rapide · Référence des commandes