Currently if you try to run tsh ssh on Windows, this happens:
C:\Users\Gus>tsh ssh gus@zeus
error: sessions not supported on Windows
This is a frustrating experience for users. The way to start a session is actually to install OpenSSH for Windows, then run a complicated SSH command:
c:\Windows\System32\OpenSSH\ssh.exe -i C:\Users\Gus\.tsh\keys\teleport.example.com\webvictim
-o "ProxyCommand C:\Windows\System32\OpenSSH\ssh.exe -i C:\Users\Gus\.tsh\keys\teleport.example.com\webvictim
-p 3023 [email protected] -s proxy:%h:%p" -o "HostKeyAlias zeus.teleport.example.com" gus@zeus -p 3022
This command also requires the correct host CA fingerprint to be present in the known_hosts file (which is automatically loaded by OpenSSH):
@cert-authority teleport.example.com,*.teleport.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDX2iIvsuLDdAqd1Kd0LAKa+JRkF/qRNTCqrIuBqjV4F8i0lTQ+8XTr7dqoT1BrzEo39mn8SfjYWyULEGYPwtKr1VXkGhS7Oo6r/jabDuuKNecYFLycxZdbBXItGCOLcbmWwo+xWcHNzmtPa/SERrvsUepS0xsMQR+sOgCy11RQUgpLuy0LDah0toGEeAcmmyZXe0th/11z248GqvfOfGmExbeaVts1pJsSOvUqzO++S2VZmVs0dYiZTYWhu7QUha+yBPowd9X3zzI/gLuxUHat3heqcIfa9WYVwnY9pLD8J+b/ULciOXTwL4KKhk27SjmVqlnwmfWc2FoZc1wlCz/x type=host
To get this, the user has to run tctl auth export --type=host on their Teleport auth server and add it to the known_hosts file manually. They also have to craft a matching hostname string in order for SSH to pick it up, or use HostKeyAlias to make it match.
I've written a guide on our Community Forum which details how to do some of this. It's our most viewed guide by quite a long way:

My proposal is that we could improve tsh ssh on Windows by making it write two temporary files after running tsh ssh, effectively building an ephemeral SSH config and known hosts file for the user, then automatically run the installed ssh.exe for them with the necessary parameters to load these two files and start the connection.
Here's the information needed to build the files:
teleport_username: Teleport username [webvictim]proxy_hostname: Teleport proxy server hostname [teleport.example.com]proxy_port: Teleport proxy server port [3023]login: Principal (login) to connect as [gus]hostname: Node hostname [zeus]port: Node port [3022]host_ca: Host CA [ssh-rsa string above]ssh_client_path: Path to SSH client [C:\Windows\System32\OpenSSH\ssh.exe]temp_dir: The value of the %TEMP% environment variable [C:\Users\Gus\AppData\Local\Temp]timestamp: A current timestampuser_profile_dir: The value of the %USERPROFILE% environment variable [C:\Users\Gus]Here is some pseudocode detailing how to create the files:
<temp_dir>\ssh_config_temp_<timestamp>:
Host <proxy_hostname>
Port <proxy_port>
IdentityFile <user_profile_dir>\\.tsh\\keys\\<proxy_hostname>\\<teleport_username>
UserKnownHostsFile <temp_dir>\known_hosts_temp_<timestamp>
Host <hostname>
ProxyCommand <ssh_client_path> <proxy_hostname> -s proxy:%h:%p
Port <port>
IdentityFile <user_profile>\\.tsh\\keys\\<proxy_hostname>\\<teleport_username>
HostKeyAlias <hostname>.<proxy_hostname>
UserKnownHostsFile <temp_dir>\known_hosts_temp_<timestamp>
<temp_dir>\known_hosts_temp_<timestamp>:
@cert-authority <proxy_hostname>,*.<proxy_hostname> <host_ca>
After these files are written, we then exec <ssh_client_path> -F <temp_dir>\ssh_config_temp_<timestamp> <login>@<port> to start the session automatically. When the session ends, the ephemeral config files we wrote can be deleted automatically. There is no key material in them, so it doesn't matter too much if they end up sticking around in the temp directory for a while.
The only requirement to make this work would be for the Windows machine to have ssh.exe installed on it and executable by the user. This is very simple to do in Windows 10 via the additional Windows features functionality.
Make it easier for Windows users to connect to Teleport hosts using SSH.
Windows users
This is a great idea.
We could reuse the same config generation logic in a new subcommand, to update openssh configs on any platform.
For example:
tsh configure openssh # updates stuff in ~/.ssh, with flags to override destination
I've realised that there are some quirks to writing SSH config files on Windows (like the need for the double-escaped backslash \\ in the example above, and the need to use the full path to ssh.exe in a ProxyCommand) so we'd have to have some separate per-platform logic, but overall the same logic is correct and we could reuse it.
One thing I've noticed is that people tend to find getting the right hostname principals to be really difficult - there isn't a lot of notification about whether the hostname matches the against the CA unless you run with ssh -vv or above, and the only warning it's failed is that you get a TOFU prompt (which people are conditioned into just typing yes for anyway, which then breaks if you have an HA proxy server which presents a different host cert on a second connection).
Removing that pain by just automatically making sure that the hostname in the known-hosts file matches both the hostname being connected and the proxy's hostname would make it considerably easier to configure an OpenSSH client.
We also tend to see a lot of requests related to running ssh in desktop linux clients vs the command line. You can do this in mobaxterm with the shell option. No ssh clients that I can find due to them using Putty. Having a method to integrate with an existing linux desktop client would help migrate existing windows users to Teleport.
@russjones any chance we can get this in 7.x?
I think it's not only useful for Windows users, but so many people use SSH every day
cc @knisbet
As I mentioned on the team leads call, missing this vs the gcloud compute config-ssh command is effectively why I stopped using teleport for my remote dev setup (vscode over ssh). I shutdown my VMs when not in use to save costs and justify larger VMs, so the IP changes every time they boot. But a quick gcloud compute config-ssh after booting the VMs and I get a fully configured openssh env.
Here's what the generated config looks like:
# Google Compute Engine Section
#
# The following has been auto-generated by "gcloud compute config-ssh"
# to make accessing your Google Compute Engine virtual machines easier.
#
# To remove this blob, run:
#
# gcloud compute config-ssh --remove
#
# You can also manually remove this blob by deleting everything from
# here until the comment that contains the string "End of Google Compute
# Engine Section".
#
# You should not hand-edit this section, unless you are deleting it.
#
Host host1.project
HostName 34.235.213.30
IdentityFile /Users/knisbet/.ssh/google_compute_engine
UserKnownHostsFile=/Users/knisbet/.ssh/google_compute_known_hosts
HostKeyAlias=compute.3311655241933103016
IdentitiesOnly=yes
CheckHostIP=no
<repeated for each host in the env>
code-insiders --remote ssh-remote+host2.northamerica-northeast1-b.project2 /home/knisbet/go/src/github.com/gravitational/gravity
Most helpful comment
We also tend to see a lot of requests related to running ssh in desktop linux clients vs the command line. You can do this in
mobaxtermwith the shell option. No ssh clients that I can find due to them using Putty. Having a method to integrate with an existing linux desktop client would help migrate existing windows users to Teleport.