So I’m currently demoing teleport for our use and after reading issue #1497, other issues and official docs I ended up with the following setup:
demo-teleport: running teleport auth/proxy with the following
teleport: nodename: demo-teleport.host auth_servers: - demo-teleport.host:3025 auth_service: enabled: yes cluster_name: demo authentication: type: github listen_addr: demo-teleport.host:3025 public_addr: demo-teleport.host:3025 session_recording: proxy proxy_checks_host_keys: no client_idle_timeout: 1h ssh_service: enabled: yes listen_addr: 0.0.0.0:3022 public_addr: demo-teleport.host:3022 proxy_service: enabled: yes listen_addr: 0.0.0.0:3023 web_listen_addr: 0.0.0.0:3080 public_addr: demo-teleport.host:3080 ssh_public_addr: demo-teleport.host:3023
test-node-for-teleport: standard ubuntu instance running openssh with
TrustedUserCAKeys /etc/ssh/teleport-user-ca.pub added to
sshd_config (and that pubkey created).
I can use
tsh to login to that test node with
tsh ssh -p 22 email@example.com successfully. Recording and all appears to be kept track of.
However I’m unable to use the proxy directly with an SSH client:
~]$ ssh -o ForwardAgent=yes -J firstname.lastname@example.org:3023 email@example.com channel 0: open failed: unknown channel type: unknown channel type: direct-tcpip stdio forwarding failed kex_exchange_identification: Connection closed by remote host
I have the same use case as this guy in issue #2662, where I’d need to use teleport when provisioning infrastructure with terraform, and it looks like he’s also running into the same issue. However, the discussion and linked closed issues (#2543/#2873) in there seemed to indicate to me that this might have been resolved and that #2662 was just left open on accident. Wasn’t sure whether or not to post on Github so I’m posting here instead (since I’m also not 100% if I’m following the correct procedure to setup a teleport bastion for regular sshd servers).
Is there anything missing from/wrong with my setup and/or procedure?