OpenSSH와 함께 Teleport 사용하기 (수동 설치)

이 가이드에서는 OpenSSH 서버 sshd를 구성하여 Teleport 클러스터에 가입하는 방법을 보여줍니다. 기존의 OpenSSH 서버 Fleets는 Teleport CA에 의해 동적으로 발급된 SSH 인증서를 수락하도록 구성할 수 있습니다.

Teleport와 OpenSSH를 사용하는 것은 신속하게 구현할 수 있는 장점이 있지만, 장기적으로는 sshd를 teleport로 교체하는 것을 권장합니다. teleport SSH 서버는 OpenSSH와 호환되지 않는 여러 기능을 지원합니다:

Teleport는 Proxy Service를 통해 SSH 연결을 프록시하여 OpenSSH를 지원합니다. Teleport 사용자가 OpenSSH 노드에 연결을 요청하면, Proxy Service는 사용자의 Teleport 역할을 확인합니다.

RBAC 확인이 성공하면, Proxy Service는 Teleport CA에서 서명된 동적으로 생성된 인증서를 사용하여 OpenSSH 노드에 인증합니다. 이렇게 하면 Proxy Service가 OpenSSH 노드에 대한 연결을 기록하고 감사할 수 있습니다.

Proxy Service는 Teleport 사용자가 감사 과정을 우회하는 것을 방지하기 위해, 인증서를 Teleport CA에서만 서명하도록 요구합니다.

이 설정에서 Teleport SSH Service는 RBAC 확인을 수행하고 호스트에서 세션을 감사 및 기록하므로, SSH 세션을 기록할 때 연결 종료가 필요하지 않습니다.

참고

이 가이드는 OpenSSH 노드를 등록하는 방법과 노드 리소스를 생성하고 OpenSSH가 Teleport CA를 신뢰하도록 구성하는 방법을 보여줍니다. 만약 OpenSSH 노드에 teleport 바이너리를 복사하고 실행할 수 있다면, 표준 등록 가이드를 따르세요. 이 가이드는 단계가 적습니다. Teleport는 이 가이드에서 보여주는 여러 단계를 자동으로 수행할 수 있습니다.

사전 준비 사항

로컬 머신에 OpenSSH 버전 6.9 이상이 설치되어 있어야 합니다. 다음 명령어로 OpenSSH 버전을 확인할 수 있습니다:
```
ssh -V
```

실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
tctl 관리 도구와 tsh 클라이언트 도구.

tctl과 tsh 다운로드에 대한 지침은 설치를 방문하세요.

Teleport가 설치되지 않은 Linux 호스트에 OpenSSH 서버 sshd 버전 7.4 이상이 설치되어 있어야 하며, 이 호스트의 SSH 포트는 Teleport Proxy Service 호스트로부터의 트래픽을 수신할 수 있도록 열려 있어야 합니다.
당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

레거시 OpenSSH 노드에서 v14로 업그레이드하기

이전에 OpenSSH 노드를 Teleport CA를 신뢰하도록 구성했으나 등록하지 않고 Teleport 클러스터를 Teleport 14로 업그레이드하면 기본적으로 더 이상 연결할 수 없습니다. 이는 클러스터에 등록되지 않은 OpenSSH 서버에 대한 개방 접근이 Teleport 14에서 더 이상 허용되지 않기 때문입니다. OpenSSH 노드에 대한 액세스를 유지하려면 이 가이드를 따라 이전에 구성한 모든 OpenSSH 노드를 Teleport에 등록해야 합니다. 이는 Teleport 클러스터를 Teleport 14로 업그레이드하기 전에 수행해야 합니다.

OpenSSH 노드 등록에 문제가 있거나 모든 OpenSSH 노드를 등록하기 전에 Teleport 클러스터를 Teleport 14로 업그레이드해야 하는 경우 TELEPORT_UNSTABLE_UNLISTED_AGENT_DIALING 환경 변수를 Proxy Service에 전달하고 yes로 설정할 수 있습니다. 그러면 등록되지 않은 OpenSSH 노드에 연결할 수 있지만, Teleport v15에서 제거될 예정입니다.

1단계/5단계. Teleport 클러스터에 노드 리소스 추가하기

OpenSSH 노드에 SSH 연결을 요청하면 Teleport는 노드의 IP 주소를 찾아서 연결을 설정할 수 있어야 합니다.

node 리소스를 선언하여 Teleport가 OpenSSH 서버에 접근하는 방법을 알 수 있도록 합니다. 로컬 머신에서 openssh-node-resource.yaml라는 파일을 다음 내용을 작성하여 생성합니다:

kind: node
version: v2
sub_kind: openssh
metadata:
  name: a100fdd0-52db-4eca-a7ab-c3afa7a1564a
  labels:
    env: prod
spec:
  addr: 1.2.3.4:22
  hostname: openssh-node

spec.addr 및 spec.hostname는 필수 항목입니다. spec.addr에 노드의 주소와 포트를 할당하고 spec.hostname에 Teleport에서 사용자가 보고 싶어하는 노드의 이름을 지정합니다.

metadata.labels 필드는 SSH Service 인스턴스를 레이블링하므로, 이에 RBAC 규칙을 적용할 수 있습니다.

metadata.name 필드는 필수 항목이 아니지만 여기에서 설정하면 나중에 작업이 줄어듭니다.

node 이름에 적합한 새로운 보편 고유 식별자(UUID)를 생성하려면, Linux 또는 macOS의 uuidgen을 사용하거나 Windows의 Powershell에서 New-Guid cmdlet을 사용하세요.

노드 리소스를 생성합니다:

tctl create openssh-node-resource.yaml

Note

이 단계는 코드 기반 인프라(IaC) 도구(tctl, Terraform 또는 Kubernetes Operator)로 수행할 수 있습니다. 이는 OpenSSH 서버의 IaC 가이드에서 설명되어 있습니다.

2단계/5단계. `sshd`가 Teleport CA 신뢰하도록 구성하기

이 가이드의 후반부에서는 Teleport Auth Service에서 서명한 인증서를 사용하여 SSH 서버에 인증하는 SSH 클라이언트 구성을 생성할 것입니다. 이를 위해 sshd는 Teleport Auth Service에서 생성된 인증서로 사용자가 로그인할 수 있도록 허용하라는 지시를 받아야 합니다.

먼저 Teleport CA 공개 키를 내보냅니다.

sshd를 실행하는 호스트에서 다음 명령을 실행하여 proxy를 Teleport Proxy Service의 주소로 할당합니다:

export KEY=$(curl 'https://proxy/webapi/auth/export?type=openssh' | sed "s/cert-authority\ //")

공개 키를 sshd에 접근할 수 있도록 만듭니다:

sudo bash -c "echo \"$KEY\" > /etc/ssh/teleport_openssh_ca.pub"
sudo bash -c "echo 'TrustedUserCAKeys /etc/ssh/teleport_openssh_ca.pub' >> /etc/ssh/sshd_config"

sshd를 재시작합니다. systemd가 활성화된 호스트에서 다음 명령을 실행하세요:

sudo systemctl restart sshd

이제 sshd는 Teleport에서 발급한 인증서를 제시하는 사용자를 신뢰합니다.

3단계/5단계. 호스트 인증 구성하기

다음으로 Teleport에 대해 sshd 호스트에 대한 유효한 호스트 인증서를 발급하라는 요청을 합니다. 이 가이드의 후반부에서는 SSH 클라이언트를 구성하여 인증서를 신뢰하고 sshd 호스트를 인증합니다. 위에서 생성한 사용자 인증서와 마찬가지로, 호스트 인증서도 Teleport Auth Service에 의해 서명될 것입니다.

사용자가 올바른 권한을 가지고 있는지 확인하십시오

사용자는 호스트 인증서를 읽고 쓸 수 있는 권한이 있어야 합니다.

로컬 머신에서 host-certifier.yaml라는 파일을 다음 내용을 사용하여 생성합니다:

kind: role
version: v5
metadata:
  name: host-certifier
spec:
  allow:
    rules:
      - resources:
          - host_cert
        verbs:
          - list
          - create
          - read
          - update
          - delete

역할 리소스를 생성합니다:

tctl create host-certifier.yaml
역할 'host-certifier'가 생성되었습니다.

host-certifier 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:
```
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
```

로컬 사용자를 편집하여 새로운 역할을 추가합니다:

tctl users update $(tsh status -f json | jq -r '.active.username') \  --set-roles "${ROLES?},host-certifier"

Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

github 인증 커넥터를 가져옵니다:
```
tctl get github/github --with-secrets > github.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.
github.yaml을 편집하고 teams_to_roles 섹션에 host-certifier을 추가합니다.

이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

여기에 예시가 있습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - host-certifier
```
변경 사항을 적용합니다:
```
tctl create -f github.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

saml 구성 리소스를 가져옵니다:
```
tctl get --with-secrets saml/mysaml > saml.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.
saml.yaml을 편집하고 attributes_to_roles 섹션에 host-certifier을 추가합니다.

이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

여기에 예시가 있습니다:
```
  attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - host-certifier
```
변경 사항을 적용합니다:
```
tctl create -f saml.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

oidc 구성 리소스를 가져옵니다:
```
tctl get oidc/myoidc --with-secrets > oidc.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.
oidc.yaml을 편집하고 claims_to_roles 섹션에 host-certifier을 추가합니다.

이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

여기에 예시가 있습니다:
```
  claims_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - host-certifier
```
변경 사항을 적용합니다:
```
tctl create -f oidc.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

이제 sshd 호스트에 대한 호스트 키를 내보낼 수 있는 권한이 있습니다.

호스트 인증서 발급하기

node 리소스를 생성할 때 metadata.name 필드를 설정하지 않았다면, Teleport Auth Service는 그 노드에 대한 보편 고유 식별자(UUID)를 생성합니다. Teleport Proxy Services는 UUID를 사용하여 같은 호스트 이름을 가진 노드를 구분하므로 호스트 인증서에 추가해야 합니다. 노드의 UUID를 찾으려면, 먼저 해당 호스트 이름이 고유한지 결정합니다:

tctl get node/openssh-node --format text

하나의 노드만 표시되는 경우, jq가 설치되어 있다면 다음 명령을 실행하여 노드의 UUID를 얻을 수 있습니다:

tctl get node/openssh-node --format=json | jq -r ".[0].metadata.name"

그렇지 않다면, 다음 명령의 YAML 출력에서 metadata.name 필드에서 노드의 UUID를 찾습니다:

tctl get node/openssh-node

호스트 인증서 생성하기

호스트 인증서를 생성할 때는 노드를 참조하는 모든 도메인 이름과 주소를 지정하는 것이 중요합니다. 노드의 호스트 인증서를 생성할 때 지정되지 않은 이름이나 주소로 연결을 시도할 경우, Teleport는 SSH 연결을 거부합니다.

로컬 머신에서 IP 주소, 노드의 완전한 도메인 이름, 노드의 UUID를 환경 변수에 할당합니다. 노드의 호스트 이름으로 연결하지 않을 예정이라면, 이를 생략할 수 있습니다.

ADDR=1.2.3.4,openssh-node,a100fdd0-52db-4eca-a7ab-c3afa7a1564a

다음 tctl 명령을 실행하여 호스트 인증서를 생성합니다:

tctl auth sign \      --host=${ADDR?} \      --format=openssh \      --out=myhost

자격 증명이 myhost, myhost-cert.pub에 기록되었습니다.

위 명령은 개인 키와 인증서를 생성합니다.

여러 호스트의 인증서를 생성할 경우, host 플래그에 콤마로 구분된 주소 목록을 지정합니다. OpenSSH는 와일드카드 도메인을 지원하지 않으므로, 각 도메인은 완전한 형태여야 합니다.

ssh-keygen을 사용하여 인증서의 내용을 확인합니다:

ssh-keygen -L -f myhost-cert.pub

Principals 섹션에는 앞서 ADDR에 할당한 주소가 포함되어야 합니다:

myhost-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com 호스트 인증서
        Public key: RSA-CERT SHA256:nHkp6SnrAW4AV00VUaqPgR6SgdyvV9MmjUrYnwZ779A
        Signing CA: RSA SHA256:euqx2Y8Pq+r0c94GKVNXAklBVTmAJtaQUn3/ehrfEJE (rsa-sha2-512 사용)
        Key ID: ""
        Serial: 0
        Valid: after 2022-04-22T11:14:16
        Principals:
                1.2.3.4
                openssh-node
                a100fdd0-52db-4eca-a7ab-c3afa7a1564a
        Critical Options: (없음)
        Extensions:
                x-teleport-authority UNKNOWN OPTION (len 33)
                x-teleport-role UNKNOWN OPTION (len 8)

호스트 키와 인증서를 sshd 호스트로 복사하고 /etc/ssh 디렉토리에 배치합니다.

이 파일들이 올바른 권한을 가지고 있는지 확인합니다:

sudo chmod 0600 /etc/ssh/myhost
sudo chmod 0600 /etc/ssh/myhost-cert.pub

그런 다음 sshd 호스트의 /etc/ssh/sshd_config에 다음 라인을 추가합니다:

HostKey /etc/ssh/myhost
HostCertificate /etc/ssh/myhost-cert.pub

sshd를 재시작합니다.

4단계/5단계. SSH 클라이언트 구성 생성하기

다음 단계는 OpenSSH 클라이언트를 Teleport에서 관리되는 자격 증명을 사용하여 sshd 호스트에 연결하도록 구성하는 것입니다. 이 구성은 사용자의 Teleport 발급 인증서를 사용하여 sshd 호스트에 인증합니다. 또한, 이전에 생성한 호스트 인증서를 사용하여 sshd 호스트를 인증합니다.

먼저, Teleport 클러스터에 로그인을 한 상태인지 확인합니다:

tsh status
> 프로필 URL:        https://teleport.example.com:443  로그인한 사용자:       myuser  클러스터:            teleport.example.com  역할:              access, auditor, editor, host-certifier  로그인:             ubuntu, root  Kubernetes:         enabled  유효기간:        2022-05-06 22:54:01 -0400 EDT [11시간 53분 0초 유효]  확장:         permit-agent-forwarding, permit-port-forwarding, permit-pty

tsh status
> 프로필 URL:        https://teleport.example.com:443  로그인한 사용자:       myuser  클러스터:            teleport.example.com  역할:              access, auditor, editor, reviewer, host-certifier  로그인:             ubuntu, root  Kubernetes:         enabled  유효기간:        2022-05-06 22:54:01 -0400 EDT [11시간 53분 0초 유효]  확장:         permit-agent-forwarding, permit-port-forwarding, permit-pty

tsh status
> 프로필 URL:        https://mytenant.teleport.sh:443  로그인한 사용자:       myuser  클러스터:            mytenant.teleport.sh  역할:              access, auditor, editor, reviewer, host-certifier  로그인:             ubuntu, root  Kubernetes:         enabled  유효기간:        2022-05-06 22:54:01 -0400 EDT [11시간 53분 0초 유효]  확장:         permit-agent-forwarding, permit-port-forwarding, permit-pty

로컬 머신에서 다음 tsh 명령을 실행합니다. 이 명령은 SSH 클라이언트가 클러스터의 호스트에 연결하는 데 Teleport에서 관리되는 자격 증명을 사용하도록 지시하는 구성 블록을 출력합니다.

tsh config > ssh_config_teleport

이 명령은 더 쉽게 정리할 수 있도록 비표준 위치에 SSH 구성 파일을 생성하지만, 원한다면 tsh config의 출력을 기본 SSH 구성 파일(~/.ssh/config)에 추가할 수 있습니다.

Teleport는 여러 서브시스템, 즉 서버가 연결을 처리할 때 실행되는 미리 정의된 명령을 포함하는 SSH 서버를 구현하고 있습니다. Proxy Service는 원격 호스트 및 신뢰할 수 있는 클러스터로 SSH 트래픽을 전달하는 proxy 서브시스템을 구현합니다.

tsh config가 생성하는 구성에 대한 간략한 설명은 다음과 같습니다:

# 모든 {{ .ClusterName }} 호스트에 대한 공통 플래그
Host *.{{ .ClusterName }} {{ .ProxyHost }}
    UserKnownHostsFile "{{ .KnownHostsPath }}"
    IdentityFile "{{ .IdentityFilePath }}"
    CertificateFile "{{ .CertificateFilePath }}"

접근하려는 호스트가 Teleport 클러스터에 속하는 경우(즉, 해당 주소가 클러스터 도메인의 하위 도메인인 경우), Teleport가 관리하는 알려진 호스트 파일, 개인 키 및 인증서를 사용하여 .tsh 디렉토리에 저장합니다.

# 프록시를 제외한 모든 {{ .ClusterName }} 호스트에 대한 플래그
Host *.{{ .ClusterName }} !{{ .ProxyHost }}
    Port 3022
    ProxyCommand "{{ .TSHPath }}" proxy ssh --cluster={{ .ClusterName }} --proxy={{ .ProxyHost }} %r@%h:%p

접근하려는 호스트가 Teleport 클러스터에 속하는 경우, OpenSSH 클라이언트는 먼저 ProxyCommand라는 명령을 실행하여 Proxy Service에 SSH 연결을 설정합니다. 이 명령인 tsh proxy ssh는 원격 호스트(신뢰할 수 있는 클러스터의 호스트 포함)로 SSH 트래픽을 전달하는 proxy 서브시스템을 요청합니다.

tsh proxy ssh 명령은 아래와 비슷한 명령을 통해 proxy 서브시스템을 요청합니다. 이는 사용자 root로 teleport.example.com이라는 클러스터에 있는 mynode라는 노드에 로그인한다고 가정합니다:

/usr/bin/ssh -l root -A -o UserKnownHostsFile=/root/.tsh/known_hosts -p 11105 teleport.example.com -s proxy:mynode:3022@teleport.example.com

명령에 사용되는 known_hosts 파일은 tsh에 의해 관리되기 때문에, 해당 SSH 호스트의 정보가 이 파일에 나열되어 있어 OpenSSH 클라이언트가 이전에 생성한 인증서를 통해 호스트를 인증할 수 있습니다.

Windows의 PowerShell을 사용 중이라면, 일반 셸 리디렉션으로 파일이 잘못된 인코딩으로 작성될 수 있습니다. 올바르게 작성되도록 하려면 다음을 시도하세요:

tsh.exe config | out-file .ssh\config -encoding utf8 -append

Teleport 클러스터에서 라우팅은 기본적으로 대소문자를 구분하지만, OpenSSH는 항상 호스트 이름을 소문자로 변환합니다. OpenSSH 클라이언트를 사용하고 호스트 이름에 대문자가 포함된 호스트가 있는 경우, Teleport 구성의 auth_service 블록이나 cluster_networking_config 리소스에서 case_insensitive_routing: true를 설정해야 할 수 있습니다.

다중 클러스터

여러 Teleport Proxy Server 간에 전환할 경우, 각 클러스터에 따라 tsh config를 다시 실행해야 하며, 신뢰할 수 있는 클러스터가 추가되거나 제거되는 경우 이전 구성을 교체하려면 tsh config를 다시 실행해야 합니다.

5단계/5단계. `sshd` 호스트에 연결하기

OpenSSH 클라이언트 구성 파일에 새 텍스트를 추가한 후, 위에서 생성한 구성을 사용하여 sshd 호스트에 로그인할 수 있습니다.

먼저 Teleport 클러스터의 주소, sshd 호스트에 로그인하는 데 사용할 사용자 이름, SSH 트래픽에 사용할 sshd 호스트의 포트를 위한 환경 변수를 정의합니다:

sshd 호스트에 접근하기 위해 사용할 수 있는 로그인 정보를 확인합니다.
tsh status | grep Logins
Logins:             ubuntu, rootUSER=ubuntu
CLUSTER=teleport.example.com
PORT=22

sshd 호스트에 접근하기 위해 사용할 수 있는 로그인 정보를 확인합니다.
tsh status | grep Logins
Logins:             ubuntu, rootUSER=ubuntu
CLUSTER=mytenant.teleport.sh
PORT=22

다음으로 원격 호스트에 SSH로 접속합니다:

ADDR_NODE=openssh-node
ssh -p ${PORT?} -F ssh_config_teleport "${USER?}@${ADDR_NODE?}.${CLUSTER?}"

이 이름은 DNS를 통해 해석할 필요가 없으며, 연결은 Teleport Proxy Service를 통해 라우팅됩니다.

기본적으로 tsh config에 의해 생성된 OpenSSH 클라이언트 구성은 Teleport Proxy Service가 클러스터 내의 노드의 3022 포트로 다이얼하도록 지시합니다. 이는 해당 노드의 SSH 서비스가 포트 3022에서 수신 대기하는 경우에 작동하며, OpenSSH 클라이언트로 Teleport SSH Service에 연결할 수 있도록 합니다.

Teleport 클러스터에 노드를 추가하면 노드가 클러스터의 Proxy Service로 리버스 터널을 만듭니다. 생성된 구성을 사용하여 Teleport 클러스터 내의 호스트에 접근하는 SSH 명령을 실행하면 Teleport Proxy Service는 이 리버스 터널을 통해 호스트에 연결하려고 시도하고 실패할 경우 직접 주소로 연결을 시도합니다.

우리 경우 sshd 호스트는 Teleport를 실행하고 있지 않으므로 리버스 터널이 존재하지 않으며, Proxy Service는 호스트의 SSH 포트에 대해 직접 연결을 설정합니다.

신뢰할 수 있는 리프 클러스터의 호스트에 로그인하려면, 클러스터의 이름을 노드의 이름과 루트 클러스터의 이름 사이에 삽입하세요:

ssh -F ssh_config_teleport ${USER?}@node2.leafcluster.${CLUSTER}

참고

Teleport는 키 대신 OpenSSH 인증서를 사용합니다. 원격 호스트에 연결할 때, OpenSSH는 호스트 주소가 OpenSSH 인증서의 Principals 섹션에 나열된 주소인지 확인합니다. 이는 일반적으로 IP 주소가 아닌 완전한 도메인 이름이어야 합니다.

Teleport 원문 보기