Teleport: tsh login - rpc Fehler in Teleport v5.0.0

Die aktuelle Problemumgehung, die ich verwende, besteht darin, brew uninstall teleport und tsh v4.4.5 https://get.gravitational.com/tsh-4.4.5.pkg manuell zu installieren

Es scheint, dass das Problem auf die Verwendung von Auth Server v4 zurückzuführen ist. Wie in 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)

Wir haben keine Kontrolle über die in Homebrew verpackte Version. Der sicherste Weg, um sicherzustellen, dass aufgrund unerwarteter Upgrades nichts kaputt geht, ist die Installation der richtigen Version unserer offiziell signierten, notariell beglaubigten tsh PKG von https://goteleport.com/teleport/download

Schätzen Sie die Antwort von Ihnen und Ihrem Team @webvictim. Zum Abschluss der Auflösung wird das Teleport-Paket über den obigen Link installiert.

@rmoles / @webvictim Mein 2p wäre, dass wenn neuere tsh -Versionen nicht abwärtskompatibel sind, die Fehlermeldung verbessert werden sollte, um den Benutzer auf seinen Fehler hinzuweisen (Client-Version ist neuer als Remote). Ich habe gesehen, dass einige unserer Onboarding-Betreiber diesen Fehler festgestellt haben, weil der Remote-Endpunkt, zu dem sie eine Verbindung herstellen möchten, Teleport 4.4 ist, aber sie haben gerade das neueste tsh-Paket von der offiziellen Download- Seite

Ich weiß nicht, ob das Abrufen der authVersion eine authentifizierte oder nicht authentifizierte API-Anforderung ist, aber die ideale Lösung wäre, wenn tsh die Remote-Version mit ihrer eigenen vergleichen und den Benutzer warnen könnte, dass ihre Version neuer als ist die Fernbedienung.

Zu Ihrer Information: Die Installation des MacOS .pkg-Installationsprogramms auf MacOs wird mit dem folgenden Fehler blockiert: “teleport-4.4.5.pkg” cannot be opened because it is from an unidentified developer.
Schritte zur Installation finden Sie hier: https://support.apple.com/en-gb/guide/mac-help/mh40616/mac

@rmoles teleport-4.4.5.pkg und tsh-4.4.5.pkg sind eigentlich verschiedene Dinge.

Die teleport-*.pkg -Dateien sind nicht signiert, da die Art und Weise, wie die Teleport-Binärdatei erstellt wird, derzeit nicht mit den Signaturanforderungen von MacOS kompatibel ist. Wir haben ein offenes Problem, um dies hier zu beheben: # 3158

Die tsh-*.pkg -Dateien sind mit einem offiziellen Entwicklerzertifikat signiert und von Apple notariell beglaubigt, sodass sie problemlos installiert werden können.

@dnwe Ich stimme zu. Wir stellen die minimale Client-Version bereits über einen nicht authentifizierten API-Aufruf bereit:

$ 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"
}

Ich werde untersuchen, warum dies keine Logik auslöst, um tsh Benutzer zu warnen, dass ihre Version nicht funktioniert.

Ich öffne das Problem erneut, um dies als eine Verbesserung zu verfolgen, die für tsh erforderlich ist.

Die Problemumgehung für alle anderen, die auf dieses Problem stoßen, besteht in der Zwischenzeit darin, Ihre Version von tsh von 5.xx auf 4.4.x herunterzustufen.

@dnwe Ich stimme zu. Wir stellen die minimale Client-Version bereits über einen nicht authentifizierten API-Aufruf bereit:

...

Ich werde untersuchen, warum dies keine Logik auslöst, um tsh Benutzer zu warnen, dass ihre Version nicht funktioniert.

In diesem Fall ist es eine max_client_version, die wir benötigen würden, um Benutzer zu warnen, dass tsh 5.x nicht gegen den Teleport 4.x-Server verwendet werden kann