Connecting to node connects me to proxy on site, unable to connect to node with client

[nikolai]

Hi guys,

I’m trying to get the community edition running and am having some problems connecting to an added node. I have two servers:

server_a, nodename: foo-teleport-gateway
server_b, nodename: foo-staging

server_a acts as auth/proxy/node and server_b acts as a node. I am able to add server_b as a node and see it in “tctl node ls”. When I go onto the site and attempt to connect to server_b, it connects me to server_a. If I attempt to connect to server_a it connects me to server_a.

If I login via the tsh client, I see both servers when I run “tsh ls”. “tsh ubuntu@server_a” works correctly. “tsh ubuntu@server_b” results in:

error: access denied to ubuntu connecting to server_b on cluster test_cluster

Nothing shows up in server_a’s teleport logs when I try to connect to server_b. If I run the command with debug, I see this:

INFO [CLIENT] Client= connecting to node=server_b on cluster test_cluster client/client.go:451
DEBU [KEYAGENT] Host validation failed: ssh: principal “server_b” not in the set of valid principals for given certificate: [“4e65fe22-f072-4ba9-a29c-3feb990b53ec.foo” “foo-teleport-gateway.foo” “foo-teleport-gateway” “teleport.foo.com”]. client/keyagent.go:277

ERROR REPORT:
Original Error: *trace.AccessDeniedError access denied to ubuntu connecting to server_b on cluster test_cluster

Note that server_b does not appear in the valid principals array.

The only thing in the node log is:

Nov 27 15:14:49 ip-172-30-0-24 /usr/local/bin/teleport[18718]: INFO [PROC:1] The new service has started successfully. Starting syncing rotation status with period 10m0s. service/connect.go:433
Nov 27 15:17:32 ip-172-30-0-24 /usr/local/bin/teleport[18718]: WARN [NODE:1:CA] Re-init the cache on error: EOF.
Nov 27 15:17:32 ip-172-30-0-24 /usr/local/bin/teleport[18718]: WARN [PROC:1] Sync rotation state cycle failed: watcher has disconnected, going to retry after 10s.

server_a config:

teleport:
        nodename: foo-teleport-gateway
        data_dir: /var/lib/teleport
        advertise_ip: teleport.foo.com
        log:
                output: stderr
                severity: INFO
        storage:
                type: dir
                path: /var/lib/teleport/backend
auth_service:
        enabled: yes
        cluster_name: "test_cluster"
        authentication:
                type: local
                second_factor: off
        listen_addr: 0.0.0.0:3025
        public_addr: teleport.foo.com:3025
        session_recording: "node"
        client_idle_timeout: never
        disconnect_expired_cert: no
ssh_service:
        enabled: yes
        listen_addr: 0.0.0.0:3022
proxy_service:
        enabled: yes
        listen_addr: 0.0.0.0:3023
        tunnel_listen_addr: 0.0.0.0:3024
        web_listen_addr: 0.0.0.0:3080
        public_addr: teleport.foo.com:3080
        ssh_public_addr: teleport.foo.com:3023
        https_cert_file: /etc/letsencrypt/live/teleport.foo.com/fullchain.pem
        https_key_file: /etc/letsencrypt/live/teleport.foo.com/privkey.pem

node config:

teleport:
  nodename: foo-staging
  data_dir: /var/lib/teleport
  advertise_ip: 52.70.202.3
  log:
    output: syslog
    severity: INFO
  storage:
    type: dir
    path: /var/lib/teleport/backend
  auth_token: "<token>"
  ca_pin: "<pin>"
  auth_servers:
    - teleport.foo.com:3025
auth_service:
  enabled: no
proxy_service:
  enabled: no
ssh_service:
  enabled: yes
  listen_addr: 0.0.0.0:3022

I apologize in advance for the poor log formatting. I couldn’t figure out how to make it look better. Spaces deliberately placed in urls to get around the url limit.

[gus]

I fixed up your formatting for you - Discourse uses Markdown for formatting, so see something like https://www.markdownguide.org/extended-syntax/#fenced-code-blocks for more detailed information on how Markdown code blocks work.

With regard to your actual issue, it may be because your advertise IP is set to 52.70.202.3 but you’re trying to SSH to server_b. Is server_b actually a valid DNS name? Teleport does its own internal hostname rewriting when needed but you may be having issues because of that.

You should probably be trying to ssh to foo_staging rather than server_b as that’s what the nodename is configured as.

If you want to make a node accessible at a given hostname (which doesn’t match what the node shows up as in tsh ls) you can set public_addr under node_service and restart Teleport - this will cause its host certificate to be regenerated. It’s a little unclear to me which hostnames/IPs you’re actually using because you’ve edited parts of the config.

[nikolai]

I’ve figured out the issue. IP’s got crossed. Thank you for the help.

[gus]

Glad to hear that you got it fixed.