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

The current workaround that I am using is to brew uninstall teleport and manually install tsh v4.4.5 https://get.gravitational.com/tsh-4.4.5.pkg

It appears the issue is down to the use of auth server v4. As explained 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)

We don't have any control over the version packaged in Homebrew. The safest way to make sure nothing breaks due to unexpected upgrades is to install the correct version of our official signed, notarized tsh PKG from https://goteleport.com/teleport/download

Appreciate the response from you and your team @webvictim. Closing as the resolution is to install the teleport package from the above link.

@rmoles / @webvictim my 2p would be that if newer tsh versions aren't backwards compatible then the error message should be improved to point the user to their mistake (client version is newer than remote). I've seen a bunch of our onboarding operators hit this error because the remote endpoint they're trying to connect to is teleport 4.4 but they've just gone and fetched the most recent tsh package from the official download page.

I don't know if fetching the authVersion is an authenticated or non-authenticated API request, but the ideal solution would be if tsh could check the remote version against its own and warn the user that their version is newer than the remote.

FYI installing the MacOS .pkg installer on MacOs is blocked with the following error: “teleport-4.4.5.pkg” cannot be opened because it is from an unidentified developer.
Steps to install anyway can be found here: https://support.apple.com/en-gb/guide/mac-help/mh40616/mac

@rmoles teleport-4.4.5.pkg and tsh-4.4.5.pkg are actually different things.

The teleport-*.pkg files are not signed, because the way that the Teleport binary is built is not currently compatible with MacOS' signing requirements. We have an open issue to fix this here: #3158

The tsh-*.pkg files are signed with an official developer certificate and notarized by Apple, so they will install without any problems.

@dnwe I agree. We do actually already expose the minimum client version via an unauthenticated API call:

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

I will look into why this isn't triggering logic to warn tsh users that their version won't work.

I'm reopening the issue to track this as an improvement needed to tsh.

The workaround in the meantime for anyone else who encounters this problem is to downgrade your version of tsh from 5.x.x to 4.4.x.

@dnwe I agree. We do actually already expose the minimum client version via an unauthenticated API call:

...

I will look into why this isn't triggering logic to warn tsh users that their version won't work.

In this case it’s a max_client_version we’d need, to warn users that tsh 5.x can’t be used against teleport 4.x server