Teleport: tsh login - erreur RPC dans Teleport v5.0.0

La solution de contournement actuelle que j'utilise est de brew uninstall teleport et d'installer manuellement tsh v4.4.5 https://get.gravitational.com/tsh-4.4.5.pkg

Il semble que le problème soit lié à l'utilisation du serveur d'authentification v4. Comme expliqué dans slack Teleport v5 it's backwards compatible, but not forwards compatible ( old clients will work with new servers, but new clients may not work with old servers)

Nous n'avons aucun contrôle sur la version packagée dans Homebrew. Le moyen le plus sûr de s'assurer que rien ne casse en raison de mises à niveau inattendues est d'installer la version correcte de notre tsh PKG officiel signé et notarié https://goteleport.com/teleport/download

Appréciez la réponse de vous et de votre équipe @webvictim. Pour terminer, la résolution consiste à installer le package de téléportation à partir du lien ci-dessus.

@rmoles / @webvictim mon 2p serait que si les versions plus récentes de tsh ne sont pas rétrocompatibles, le message d'erreur devrait être amélioré pour indiquer à l'utilisateur son erreur (la version du client est plus récente que la version distante). J'ai vu un grand nombre de nos opérateurs d'intégration frapper cette erreur parce que le point de terminaison distant auquel ils essaient de se connecter est téléporter 4.4, mais ils viennent juste de récupérer le package tsh le plus récent sur la page de téléchargement officielle.

Je ne sais pas si la récupération de authVersion est une demande d'API authentifiée ou non authentifiée, mais la solution idéale serait que tsh puisse vérifier la version distante par rapport à la sienne et avertir l'utilisateur que sa version est plus récente que la télécommande.

Pour info, l'installation du programme d'installation MacOS .pkg sur MacOs est bloquée avec l'erreur suivante: “teleport-4.4.5.pkg” cannot be opened because it is from an unidentified developer.
Les étapes pour installer quand même peuvent être trouvées ici: https://support.apple.com/en-gb/guide/mac-help/mh40616/mac

@rmoles teleport-4.4.5.pkg et tsh-4.4.5.pkg sont en fait des choses différentes.

Les fichiers teleport-*.pkg ne sont pas signés, car la façon dont le binaire Teleport est construit n'est actuellement pas compatible avec les exigences de signature de MacOS. Nous avons un problème ouvert pour résoudre ce problème ici: # 3158

Les fichiers tsh-*.pkg sont signés avec un certificat de développeur officiel et notariés par Apple, ils s'installeront donc sans aucun problème.

@dnwe je suis d'accord. En fait, nous exposons déjà la version minimale du client via un appel d'API non authentifié:

$ curl -s https://teleport.example.com:3080/v1/webapi/ping | jq
{
  "auth": {
    "type": "github",
    "second_factor": "u2f",
    "github": {
      "name": "github",
      "display": "Github"
    }
  },
  "proxy": {
    "kube": {},
    "ssh": {
      "listen_addr": "0.0.0.0:3023",
      "tunnel_listen_addr": "0.0.0.0:3080",
      "public_addr": "teleport.example.com:3080",
      "ssh_public_addr": "teleport.example.com:3023",
      "ssh_tunnel_public_addr": "teleport.example.com:3080"
    }
  },
  "server_version": "5.0.0",
  "min_client_version": "3.0.0"
}

Je vais examiner pourquoi cela ne déclenche pas la logique pour avertir les utilisateurs de tsh que leur version ne fonctionnera pas.

Je rouvre le problème pour suivre cela comme une amélioration nécessaire pour tsh .

La solution de contournement entre-temps pour quiconque rencontre ce problème est de rétrograder votre version de tsh de 5.xx à 4.4.x.

@dnwe je suis d'accord. En fait, nous exposons déjà la version minimale du client via un appel d'API non authentifié:

...

Je vais examiner pourquoi cela ne déclenche pas la logique pour avertir les utilisateurs de tsh que leur version ne fonctionnera pas.

Dans ce cas, c'est une version max_client_version dont nous aurions besoin, pour avertir les utilisateurs que tsh 5.x ne peut pas être utilisé contre le serveur teleport 4.x