Teleport uses incorrect principal during proxy SSH authentication

Description

What happened:

Via RBAC, a Teleport user can be permitted to authenticate with more than one principal. The following role defines three principals (aka logins).

kind: role
version: v3
metadata:
  name: admin
spec:
  options:
    forward_agent: true
  allow:
    logins: [root, admin, devops]

After authenticating with tsh. The following is displayed:

> Profile URL:        https://proxy.example.com:3080
  Logged in as:       user1
  Cluster:            dev-test0
  Roles:              admin*
  Logins:             root, admin, devops
  Kubernetes:         enabled
  Kubernetes cluster: "mini-k8s"
  Kubernetes users:   admin
  Kubernetes groups:  system:masters
  Valid until:        2021-03-19 02:18:41 -0500 CDT [valid for 11h55m0s]
  Extensions:         permit-port-forwarding, permit-pty

This means, a user with the admin role can perform the following:

$ tsh ssh root@node
$ tsh ssh admin@node
$ tsh ssh devops@node

$ tsh ssh -l root node
$ tsh ssh -l admin node
$ tsh ssh -l devops node

Upon issuing any of the above commands, Teleport will ignore the requested remote host login, and instead only use the first principal in the logins list to authenticate with the Teleport proxy.

$ tsh ssh devops@node

DEBUG [PROXY]  conn(X.X.43.137:64288->10.128.0.2:3023, user=root) auth attempt fingerprint:ssh-rsa-cert-v01@openssh.com SHA256:4aB5t5LNXQ+jUrxxxxxxxQRU5P9SJnfQPiPdlXog local:10.128.0.2:3023 remote:X.X.43.137:64288 user:root srv/authhandlers.go:163

This is problematic because you may have two roles that, when merged together, have differing role options. For example, one role may have agent forwarding enabled, while the other is disabled.

If the first principal in the logins list has agent forwarding disabled, and you're operating with proxy recording mode, you will get the following error from the tsh client.

error: failed connecting to node master. agent forwarding not requested or not authorized

What you expected to happen:

Teleport to respect role options for the specified remote login principal.

Reproduction Steps

As minimally and precisely as possible, describe step-by-step how to reproduce the problem.

Enable proxy recording mode. Create two roles. One with forward_agent: true and the other with forward_agent: false.

kind: role
version: v3
metadata:
  name: admin
spec:
  options:
    forward_agent: true
  allow:
    logins: [root]

kind: role
version: v3
metadata:
  name: devops
spec:
  options:
    forward_agent: false
  allow:
    logins: [admin, devops]

Set your SSO mapping to map both roles onto the user.
Authenticate with your cluster.
Run tsh login. In the output, observe which user is listed first. Is it root, admin, devops or admin, devops, root?
If root appears first, go back to your SSO mapping and reorder your role mappings to change the order of logins. Logout and log back in and admin, devops should be listed first.
```
Logins:             admin, devops, root
```
Now, attempt tsh ssh root@<node>. You should run into the error. This should work, because root has permission to forward the agent. However, under the hood, Teleport is actually authenticating with admin.
```
error: failed connecting to node master. agent forwarding not requested or not authorized
```

Server Details

Teleport version (run teleport version): 6.0.2
Server OS (e.g. from /etc/os-release): 16.04.6 LTS (Xenial Xerus)
Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware): AWS

Client Details

Tsh version (tsh version): 6.0.2
Computer OS (e.g. Linux, macOS, Windows): macOS
Browser version (for UI-related issues): N/A
Installed via (e.g. apt, yum, brew, website download): website download

Debug Logs

Please include or attach debug logs, when appropriate. Obfuscate sensitive information!

Start Teleport with --debug flag (teleport --debug)
Run tsh with --debug flag (tsh --debug)

gravitational / teleport