Infograb logo
tsh 명령줄 도구 사용

이 가이드는 Teleport 클라이언트 도구인 tsh를 사용하는 방법을 보여줍니다.

다음과 같은 내용을 배웁니다:

  • 원격 클러스터 노드에서 인터랙티브 쉘에 로그인합니다.
  • 클러스터 노드 간 파일을 복사합니다.
  • SSH 역 터널을 사용하여 방화벽 뒤에 있는 SSH 클러스터에 포트가 열려 있지 않더라도 연결합니다.
  • 클러스터를 탐색하고 클러스터의 특정 노드에서 명령을 실행합니다.
  • 동료와 인터랙티브 쉘 세션을 공유 하거나 다른 사용자의 세션에 참여합니다.
  • 기록된 인터랙티브 세션을 나열하고 재생합니다.

이 문서 외에도 CLI 참조를 위해 항상 단순히 터미널에 tsh를 입력할 수 있습니다.

소개

인내가 부족한 분들을 위해 사용자가 일반적으로 사용하는 방식의 예를 보여드립니다. tsh:

Teleport 클러스터에 로그인합니다. 이 명령은 사용자의 인증서를 검색하고

~/.tsh/teleport.example.com에 저장합니다.

tsh login --proxy=teleport.example.com

일반과 같이 노드에 SSH로 로그인합니다.

tsh ssh user@node

`tsh ssh`는 OpenSSH 클라이언트와 같은 인수를 받습니다:

tsh ssh -o ForwardAgent=yes user@node
tsh ssh -o AddKeysToAgent=yes user@node

편리한 심볼릭 링크를 만들 수 있습니다:

ln -s /path/to/tsh /path/to/ssh

... 이제 'ssh' 명령은 Teleport의 `tsh ssh`를 호출합니다.

ssh user@host

이 명령은 사용자의 머신에서 SSH 인증서를 제거합니다:

tsh logout

Teleport 클러스터에 로그인합니다. 이 명령은 사용자의 인증서를 검색하고

~/.tsh/mytenant.teleport.sh에 저장합니다.

tsh login --proxy=mytenant.teleport.sh

일반과 같이 노드에 SSH로 로그인합니다.

tsh ssh user@node

`tsh ssh`는 OpenSSH 클라이언트와 같은 인수를 받습니다:

tsh ssh -o ForwardAgent=yes user@node
tsh ssh -o AddKeysToAgent=yes user@node

편리한 심볼릭 링크를 만들 수 있습니다:

ln -s /path/to/tsh /path/to/ssh

... 이제 'ssh' 명령은 Teleport의 `tsh ssh`를 호출합니다.

ssh user@host

이 명령은 사용자의 머신에서 SSH 인증서를 제거합니다:

tsh logout

다시 말해, Teleport는 기존 SSH 기반 워크플로우와 완전히 호환되도록 설계되었으며 사용자에게 새로운 작업을 배울 필요가 없습니다. 단지 시작할 때 tsh login을 호출하면 됩니다.

tsh 설치

tsh 바이너리 설치를 위한 아래 지침을 따르십시오.

Teleport 클러스터에서 사용 중인 버전과 동일한 주요 버전의 tsh를 설치하는 것이 좋습니다.

버전 번호를 찾으려면 다음 방법 중 하나를 사용하십시오:

  • 웹 UI에서 오른쪽 상단에 있는 사용자 이름을 선택한 후 도움 및 지원을 클릭합니다. 그러면 클러스터 정보 아래에 Teleport 클러스터의 버전이 표시됩니다.

  • curljq를 사용하십시오. teleport.example.com를 Proxy 서비스 주소로 바꿔야 합니다(예: Teleport Enterprise Cloud의 경우 mytenant.teleport.sh):

    curl https://teleport.example.com/webapi/find | jq '.server_version'
    "16.2.0"

tsh의 서명된 macOS .pkg 설치 관리자를 다운로드합니다. Finder에서 pkg 파일을 두 번 클릭하여 설치합니다:

curl -O https://cdn.teleport.dev/tsh-16.2.0.pkg
Danger

Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의 Teleport 패키지는 Teleport에서 유지 관리되지 않으며 그 신뢰성이나 보안을 보장할 수 없습니다.

macOS에서 설치 시 자체 Teleport 패키지의 사용을 권장합니다.

curl.exe -O https://cdn.teleport.dev/teleport-v16.2.0-windows-amd64-bin.zip

아카이브를 압축 해제하고 `tsh.exe`를 %PATH%로 이동합니다.

주의: tsh.exe를 System32 디렉토리에 넣지 마세요, 이는 WinSCP 사용 시 문제를 일으킬 수 있습니다.

대신 %SystemRoot% (C:\Windows) 또는 %USERPROFILE% (C:\Users\<username>)를 사용하세요.

tsh는 Linux 설치에 포함된 모든 Teleport 바이너리와 함께 제공됩니다. 더 많은 옵션(RPM/DEB 패키지 및 i386/ARM/ARM64 다운로드 포함)은 설치 페이지를 참조하십시오.

curl -O https://cdn.teleport.dev/teleport-v16.2.0-linux-amd64-bin.tar.gz
tar -xzf teleport-v16.2.0-linux-amd64-bin.tar.gz
cd teleport
sudo ./install

Teleport 바이너리가 /usr/local/bin에 복사되었습니다.

사용자 아이덴티티

Teleport의 사용자 아이덴티티는 클러스터 범위 내에 존재합니다. 클러스터의 구성원 노드에는 여러 OS 사용자가 있을 수 있습니다. Teleport 관리자는 모든 Teleport 사용자 계정에 대해 허용된 로그인을 지정합니다.

원격 노드에 로그인할 때는 Teleport 로그인과 OS 로그인을 모두 지정해야 합니다. Teleport 아이덴티티는 --user 플래그를 통해 전달되어야 하고, OS 로그인은 전통적인 ssh 명령과 호환되는 구문인 login@host로 전달됩니다.

"work" 클러스터에 대해 joe로 인증한 후

노드에 root로 로그인합니다:

tsh ssh --proxy=work.example.com --user=joe root@node

"work" 클러스터에 대해 joe로 인증한 후

노드에 root로 로그인합니다:

tsh ssh --proxy=mytenant.teleport.sh --user=joe root@node

CLI 문서 - tsh ssh

로그인

사용자 인증서를 검색하려면 다음을 실행하십시오:

전체 형식:

tsh login --proxy=proxy_host:<https_proxy_port>

기본 포트를 사용합니다:

tsh login --proxy=work.example.com

사용자 지정 HTTPS 포트 사용:

tsh login --proxy=work.example.com:5000

전체 형식:

tsh login --proxy=proxy_host:<https_proxy_port>

tsh login --proxy=mytenant.teleport.sh

CLI 문서 - tsh login

포트설명
https_proxy_port프록시 호스트가 수신하는 HTTPS 포트 (기본값은 4433080).

로그인 명령은 사용자의 인증서를 검색하고 ~/.tsh 디렉터리와 ssh agent에 저장합니다.

이렇게 하면 하루의 시작에 한 번만 인증하시면 됩니다. 이후의 tsh ssh 명령은 임시 인증서가 만료될 때까지 자격 증명을 요구하지 않고 실행됩니다. 기본적으로 Teleport는 TTL(유효 기간) 12시간의 사용자 인증서를 발급합니다.

모든 다른 tsh 명령을 사용하기 전에 항상 tsh login을 사용하는 것이 좋습니다. 이렇게 하면 사용자가 이후의 tsh 명령에서 --proxy 플래그를 생략할 수 있습니다. 예를 들어 tsh ssh user@host가 작동합니다.

Teleport 클러스터는 여러 사용자 아이덴티티 소스를 위해 구성될 수 있습니다. 예를 들어, 클러스터에 admin이라는 로컬 사용자가 있을 수 있으며 일반 사용자는 GitHub를 통해 인증해야 합니다. 이 경우, 인증할 아이덴티티 저장소를 지정하기 위해 --auth 플래그를 tsh login에 전달해야 합니다:

로컬 Teleport 'admin' 사용자로 로그인합니다:

tsh --proxy=proxy.example.com --auth=local --user=admin login

GitHub를 SSO 제공자로 로그인합니다. GitHub 연결자가 'github'라고 가정합니다.

tsh --proxy=proxy.example.com --auth=github login

로컬 Teleport 'admin' 사용자로 로그인합니다:

tsh --proxy=mytenant.teleport.sh --auth=local --user=admin login

GitHub를 SSO 제공자로 로그인합니다. GitHub 연결자가 'github'라고 가정합니다.

tsh --proxy=mytenant.teleport.sh --auth=github login

외부 아이덴티티 제공자를 사용하여 로그인할 때, tsh는 인증 흐름을 완료하기 위해 웹 브라우저를 열어야 합니다. 기본적으로 tsh는 시스템의 기본 브라우저를 사용합니다. 이 동작을 억제하려면 --browser=none 플래그를 사용할 수 있습니다:

로그인할 때 시스템 기본 브라우저를 열지 않습니다.

tsh login --proxy=work.example.com --browser=none

로그인할 때 시스템 기본 브라우저를 열지 않습니다.

tsh login --proxy=mytenant.teleport.sh --browser=none

이 경우 화면에 링크가 인쇄됩니다. 이 링크를 복사하여 원하는 브라우저에 붙여넣어 로그인 흐름을 계속할 수 있습니다.

CLI 문서 - tsh login

SSH 인증서 검사

~/.tsh에 있는 SSH 인증서를 검사하려면 사용자가 다음 명령을 실행할 수 있습니다:

tsh status

> 프로필 URL: https://proxy.example.com:3080

로그인 사용자: johndoe

클러스터: proxy.example.com

역할: access, auditor, editor

로그인: root, admin, guest

Kubernetes: enabled

유효 기한: 2017-04-25 15:02:30 -0700 PDT [1시간]

확장 기능: permit-agent-forwarding, permit-port-forwarding, permit-pty

tsh status

> 프로필 URL: https://mytenant.teleport.sh:443

로그인 사용자: johndoe

클러스터: mytenant.teleport.sh

역할: access, editor, auditor

로그인: root, admin, guest

Kubernetes: enabled

유효 기한: 2017-04-25 15:02:30 -0700 PDT [1시간]

확장 기능: permit-agent-forwarding, permit-port-forwarding, permit-pty

CLI 문서 - tsh status

SSH 에이전트 지원

ssh agent가 실행되고 있다면, tsh login은 사용자 인증서를 에이전트에 저장합니다. 이는 다음을 통해 확인할 수 있습니다:

ssh-add -L

SSH 에이전트는 인증서를 다른 SSH 클라이언트, 예를 들어 OpenSSH (ssh)로 제공하는 데 사용될 수 있습니다.

SSH 에이전트 통합을 비활성화하려면 --no-use-local-ssh-agenttsh에 전달하세요. 이와 함께 TELEPORT_USE_LOCAL_SSH_AGENT 환경 변수를 false로 설정하여 이 설정을 영구적으로 유지할 수 있습니다.

아이덴티티 파일

tsh login은 사용자 인증서를 파일에 저장할 수도 있습니다:

proxy.example.com에 대해 사용자를 인증하고 사용자

인증서를 joe.pem으로 저장합니다.

tsh login --proxy=proxy.example.com --out=joe

joe.pem을 사용하여 서버 'db'에 로그인합니다.

tsh ssh --proxy=proxy.example.com -i joe joe@db

mytenant.teleport.sh에 대해 사용자를 인증하고 사용자

인증서를 joe.pem으로 저장합니다.

tsh login --proxy=mytenant.teleport.sh --out=joe

joe.pem을 사용하여 서버 'db'에 로그인합니다.

tsh ssh --proxy=mytenant.teleport.sh -i joe joe@db

기본적으로 --out 플래그는 tsh -i에 적합한 아이덴티티 파일을 생성합니다. OpenSSH와의 호환성이 필요한 경우 --format=openssh를 지정해야 합니다. 이 경우 아이덴티티는 두 개의 파일 joejoe-cert.pub에 저장됩니다:

tsh login --proxy=proxy.example.com --out=joe --format=openssh
ls -lh

total 8.0K

-rw------- 1 joe staff 1.7K Aug 10 16:16 joe

-rw------- 1 joe staff 1.5K Aug 10 16:16 joe-cert.pub

tsh login --proxy=mytenant.teleport.sh --out=joe --format=openssh
ls -lh

total 8.0K

-rw------- 1 joe staff 1.7K Aug 10 16:16 joe

-rw------- 1 joe staff 1.5K Aug 10 16:16 joe-cert.pub

자동화를 위한 SSH 인증서

모범 사용자는 SSH 인증서를 요청해야 하며, 일반적으로 매일 요청합니다. 이는 cron 작업이나 CI/CD 파이프라인과 같은 비대화형 스크립트에 대한 작업은 아닙니다.

자동화 목적으로 인증서를 생성하는 가장 안전한 방법은 Machine ID를 사용하는 것입니다. 이를 통해 자동화가 단기 자격 증명의 보안 속성을 활용할 수 있습니다.

Machine ID가 선호하는 CI/CD 플랫폼을 지원하지 않는 경우, 자동화에 사용할 로컬 사용자를 생성하고 해당 사용자에 대한 장기 인증서를 요청할 수 있습니다.

이 예시에서는 jenkins 사용자에 대해 TTL을 1시간으로 설정한 인증서를 생성하고 jenkins.pem 파일에 저장합니다. 이 파일은 나중에 -i (아이덴티티) 플래그와 함께 tsh에 사용될 수 있습니다.

tsh를 사용하여 클러스터에 로그인하여 로컬 머신에서 tctl을 사용할 수 있습니다.

"tsh login"을 먼저 실행하지 않고도 Auth Service 호스트에서 tctl을 실행할 수 있습니다.

tsh login --proxy=teleport.example.com --user=myuser
tctl auth sign --ttl=1h --user=jenkins --out=jenkins.pem

Teleport Cloud 클러스터에 로그인하여 로컬에서 tctl을 사용할 수 있습니다.

tsh login --proxy=myinstance.teleport.sh --user=email@example.com
tctl auth sign --ttl=1h --user=jenkins --out=jenkins.pem

CLI 문서 - tctl auth sign

이제 jenkins.pem은 Jenkins 서버에 복사되고 -i (아이덴티티 파일) 플래그의 tsh에 전달됩니다.

tctl auth signtsh login --out의 관리자 동등물이며 제한 없는 인증서 TTL 값을 허용합니다.

클러스터 탐색

Teleport 클러스터에서 모든 노드는 정기적으로 클러스터의 Auth 서비스에 ping하고 상태를 업데이트합니다. 이를 통해 Teleport 사용자는 tsh ls 명령으로 어떤 노드가 온라인인지 확인할 수 있습니다:

이 명령은 "tsh login"을 통해 로그인된 클러스터의 모든 노드를 나열합니다:

tsh ls

노드 이름 주소 레이블

--------- ------- ------

turing ⟵ 터널 os=linux

graviton 10.1.0.7:3022 os=osx

CLI 문서 - tsh ls

tsh ls는 노드 레이블을 기반으로 필터를 적용할 수 있습니다.

'os' 레이블이 'osx'로 설정된 노드만 표시합니다:

tsh ls os=osx

노드 이름 주소 레이블

--------- ------- ------

graviton 10.1.0.7:3022 os=osx

CLI 문서 -tsh ls

When Teleport의 인증 서비스가 Teleport 노드를 나열하라는 요청을 받으면 (예: 웹 UI에서 노드를 표시하거나 tsh ls를 통해), 현재 사용자가 볼 수 있는 권한이 있는 노드만 반환합니다.

사용자의 Teleport 클러스터에 있는 각 노드에 대해 인증 서비스는 다음 검사를 순서대로 적용하며, 하나의 검사가 실패하면 해당 노드를 사용자에게 숨깁니다:

  • 사용자의 역할 중 어느 것도 노드의 레이블과 일치하는 deny 규칙을 포함하지 않아야 합니다.
  • 사용자의 역할 중 적어도 하나는 노드의 레이블과 일치하는 allow 규칙을 포함해야 합니다.

예상할 때 노드를 볼 수 없다면, 사용자의 역할에 Teleport 접근 제어 참조에 문서화된 적절한 allowdeny 규칙이 포함되어 있는지 확인하세요.

인터랙티브 쉘

원격 노드에서 인터랙티브 쉘을 시작하거나 명령을 실행하려면 tsh ssh를 사용합니다.

tsh는 가능하면 ssh 경험을 모방하려고 하며, -p, -l 또는 -L과 같은 가장 인기 있는 ssh 플래그를 지원합니다. 예를 들어, ~/.bashrc에 다음과 같은 별칭이 정의되어 있다면: alias ssh="tsh ssh"를 사용해 친숙한 SSH 구문을 계속 사용할 수 있습니다:

이 별칭을 ~/.bashrc에 구성합니다

alias ssh="/usr/local/bin/tsh ssh"

클러스터에 로그인하고 SSH 인증서를 검색합니다:

tsh --proxy=proxy.example.com login

이러한 명령은 내부적으로 `tsh ssh`를 실행합니다:

ssh user@node
ssh -p 6122 user@node ls
ssh -o ForwardAgent=yes user@node
ssh -o AddKeysToAgent=yes user@node

이 별칭을 ~/.bashrc에 구성합니다

alias ssh="/usr/local/bin/tsh ssh"

클러스터에 로그인하고 SSH 인증서를 검색합니다:

tsh --proxy=mytenant.teleport.sh login

이러한 명령은 내부적으로 `tsh ssh`를 실행합니다:

ssh user@node
ssh -p 6122 user@node ls
ssh -o ForwardAgent=yes user@node
ssh -o AddKeysToAgent=yes user@node

프록시 포트

기본적으로 Teleport 프록시 서비스는 포트 3080에서 수신합니다.

Teleport 프록시 서비스 인스턴스가 기본 포트가 아닌 포트에서 수신되도록 구성된 경우, --proxy 플래그를 통해 이를 지정해야 합니다:

tsh --proxy=proxy.example.com:5000 <subcommand>

tsh 명령은 프록시 서비스의 포트 5000을 사용할 것입니다.

포트 포워딩

tsh ssh는 OpenSSH의 -L 플래그를 지원하여 로컬 호스트:포트에서 지정된 원격 호스트:포트로 들어오는 연결을 전달합니다. -L 플래그의 구문은 다음과 같으며, "bind_ip"는 기본적으로 127.0.0.1입니다:

-L [bind_ip]:listen_port:remote_host:remote_port

예시:

tsh ssh -L 5000:web.remote:80 node

이는 원격 서버 node에 프록시 서비스를 통해 연결한 다음, localhost:5000에서 수신 소켓을 열어 모든 들어오는 연결을 web.remote:80으로 전달하는 방식입니다.

포트 전달을 설정하고 연결을 사용하는 로컬 명령을 실행한 다음 연결을 끊는 것이 편리할 수 있습니다. --local 플래그를 사용하여 이를 수행할 수 있습니다.

예시:

tsh ssh -L 5000:google.com:80 --local node curl http://localhost:5000

이 명령은:

  • node에 연결합니다.
  • 로컬 포트 5000google.com의 포트 80에 바인딩합니다.
  • curl 명령을 로컬에서 실행하여 결과적으로 curlgoogle.com:80node를 통해 호출하게 됩니다.

SSH 점프 호스트

Teleport의 ProxyJump를 구현하면서 이 기능은 tsh에 확장되었습니다.

tsh ssh -J proxy.example.com telenode
tsh ssh -J mytenant.teleport.sh telenode

알려진 제한 사항:

  • 하나의 점프 호스트만 지원됩니다 (-J는 Teleport가 사용하지 않는 체인을 지원) 및 tsh는 두 개의 점프 호스트가 있을 경우 오류로 반환합니다. 즉, -J proxy-1.example.com,proxy-2.example.com은 작동하지 않습니다.
  • tsh ssh -J user@proxy가 사용되는 경우 SSH 프록시는 tsh 프로필에서 정의된 프로퍼티를 재정의하며 포트 전달은 기존 Teleport 프록시 하위 시스템 대신 사용됩니다.

노드 이름 해결

tsh는 원격 노드 이름을 해결하기 위한 여러 방법을 지원합니다.

  • 전통적인: IP 주소 또는 DNS를 통해.
  • 노드 이름 설정: teleport 데몬은 nodename 플래그를 지원하여 Teleport 관리자가 대체 노드 이름을 할당할 수 있습니다.
  • 레이블: name=value 쌍으로 노드에 접근할 수 있습니다.

노드의 수가 os:linux 레이블을 갖는 경우 하나가 os:osx 레이블을 갖는 경우, os=ubuntu의 시스템 패키지를 업데이트하는 명령을 사용하여 여러 노드에서 명령을 실행할 수 있습니다.

단기 세션

Teleport 사용자 인증서의 기본 TTL은 12시간입니다. 이 값은 로그인 시 --ttl 플래그로 수정할 수 있습니다. 이 명령은 매우 짧은 TTL(1분)의 임시 인증서로 클러스터에 로그인하게 합니다:

tsh --ttl=1 login

1분 후에 로그아웃하지만, 즉시 로그아웃하려면 항상 실행할 수 있습니다:

tsh logout

파일 복사

클러스터 노드 간에 파일을 안전하게 복사하려면 tsh scp 명령을 사용합니다. 이 명령은 OpenSSH의 scp 명령을 가능한 한 많이 모방하도록 설계되었습니다:

tsh scp example.txt root@node:/path/to/dest

또한 bash 별칭을 만들어 친숙한 구문을 사용할 수 있습니다: alias scp="tsh --proxy=work scp":

scp -P 61122 -r files root@node:/path/to/dest

Teleport 9부터는 서버 접근에서 SCP 및 SFTP 프로토콜이 모두 지원됩니다. 원할 경우 OpenSSH scp 또는 sftp 명령도 tsh scp 대신 사용할 수 있습니다.

세션 공유

원격 서버에서 문제를 해결하려고 할 때, 다른 팀원이 도움을 요청하는 것이 더 수월할 수 있습니다. 전통적으로 이를 위해서는 그들에게 당신이 있는 호스트를 알려주고 SSH로 로그인한 다음 screen과 같은 터미널 다중화기를 시작하고 거기에서 세션에 참여하게 했습니다.

Teleport는 이를 더 편리하게 만들어줍니다. 서버 luna에 로그인한 후 Teleport에게 현재 세션 상태를 요청해 봅시다:

tsh ssh luna

호스트 luna에서

teleport status

사용자 ID : joe, 10.0.10.1 43026 3022에서 logging in as joe

세션 ID : 7645d523-60cb-436d-b732-99c5df14b7c4

세션 URL: https://work:3080/web/sessions/7645d523-60cb-436d-b732-99c5df14b7c4

이제 다른 사용자에게 work 클러스터에 초대합니다. 웹 브라우저를 통해 접근하기 위한 URL을 공유하거나 세션 ID를 공유하면 다른 사용자가 터미널에서 다음을 입력하여 참여할 수 있습니다:

tsh join <session_ID>
권한 부족?

세션에 참여하려면 클러스터 관리자가 설정해야 하는 특별한 권한이 필요합니다. 그들에게 Moderated Sessions 가이드를 참조해주세요.

세션 참여는 녹화 프록시 모드(즉, session_recordingproxy로 설정된 경우)에서는 지원되지 않습니다.

방화벽 뒤에 있는 SSH 클러스터에 연결

Teleport는 열려 있는 TCP 포트 없이 방화벽 뒤에 있는 서버의 클러스터를 생성하는 것을 지원합니다. 이는 방화벽 뒤 환경에서 Teleport 프록시 서비스로의 역 SSH 터널을 만들어서 작동합니다.

방화벽 뒤에 있는 클러스터 간의 신뢰 관계 설정에 대해 자세히 알아보려면 신뢰 클러스터 구성을 참조하세요.

만약 Teleport 프록시 서버인 work가 몇 개의 신뢰클러스터로 구성되어 있다면, tsh clusters 명령을 사용하여 서버의 모든 신뢰클러스터 목록을 확인할 수 있습니다:

tsh --proxy=work clusters

클러스터 이름 상태

------------ ------

staging online

production offline

만약 Teleport Cloud 테넌트인 mytenant.teleport.sh가 몇 개의 신뢰클러스터로 구성되어 있다면, 사용자는 tsh clusters 명령을 사용하여 서버의 모든 신뢰 클러스터 목록을 확인할 수 있습니다:

tsh --proxy=mytenant.teleport.sh clusters

클러스터 이름 상태

------------ ------

staging online

production offline

CLI 문서 - tsh clusters

이제 모든 tsh 명령에 --cluster 플래그를 사용할 수 있습니다. 예를 들어, production 클러스터에 속한 SSH 노드를 나열하려면 다음을 실행합니다:

tsh --proxy=work ls --cluster=production

노드 이름 노드 ID 주소 레이블

--------- ------- ------- ------

db-1 xxxxxxxxx 10.0.20.31:3022 kernel:4.4

db-2 xxxxxxxxx 10.0.20.41:3022 kernel:4.2

tsh --proxy=mytenant.teleport.sh ls --cluster=production

노드 이름 노드 ID 주소 레이블

--------- ------- ------- ------

db-1 xxxxxxxxx 10.0.20.31:3022 kernel:4.4

db-2 xxxxxxxxx 10.0.20.41:3022 kernel:4.2

마찬가지로 db-1에 SSH로 접속하려면 production 클러스터 내에서:

tsh --proxy=work ssh --cluster=production db-1

이것은 방화벽 없이도 production 클러스터 내의 노드로 SSH를 연결하는 경우에도 가능합니다. 이는 production 클러스터가 프록시 서비스를 호출되는 방식으로 역 SSH 터널을 설정하고 이를 통해 인바운드 SSH 연결을 설정하는 방식으로 작동합니다.

tsh --proxy=mytenant.teleport.sh ssh --cluster=production db-1

방화벽 없이도 production 클러스터 내의 노드로 SSH를 연결하는 것이 가능합니다. 이는 production 클러스터가 Teleport Cloud 테넌트의 프록시 서비스로의 역 SSH 터널을 구성하고, 이 터널을 사용하여 인바운드 SSH 연결을 설정합니다.

X11 포워딩

IDE와 같은 그래픽 프로그램을 SSH 세션 내에서 실행하려면, -X 플래그로 세션에 대한 X11 포워딩을 요청해야 합니다.

tsh ssh -X node01

X11 포워딩은 서버가 로컬 X 서버에 안전하게 접근할 수 있도록 하여 로컬 화면 및 I/O 장치와 직접 통신할 수 있게 합니다.

-Y 플래그는 안전한 X11 포워딩을 시작하는 데 사용될 수 있습니다. 이는 클립보드나 스크린샷 유틸리티와 같은 더 "불안전한" 기능을 활성화하는 데 필요합니다. 그러나 이는 서버가 로컬 X 서버에 무제한 접근할 수 있도록 하여 로컬 머신을 X11 공격 위험에 노출시킬 수 있으므로 극도로 주의해야 합니다.

X11 포워딩을 사용하려면, Teleport 노드에서 이를 활성화해야 합니다. 또한 사용자가 permit_x11_forwarding 역할 옵션을 가지고 있는지 확인해야 합니다:

tsh status
> 프로필 URL: https://proxy.example.com:3080 로그인 사용자: dev ... 확장 기능: permit-X11-forwarding

커스텀 별칭 및 기본값

tsh를 구성하여 별칭, 사용자 지정 명령 및 커맨드별 플래그 기본값을 정의할 수 있습니다. 별칭을 사용하면 자주 사용하는 tsh 명령을 더 쉽게 실행할 수 있습니다.

별칭은 다음 구문을 사용하여 구성 파일에 정의됩니다:

aliases:
    "<alias>": "<command>"

<alias>는 최상위 서브 명령만이 될 수 있습니다. 즉, tsh mycommand 별칭을 정의할 수 있지만 tsh my command는 정의할 수 없습니다.

tsh는 두 가지 유형의 구성 파일을 로드합니다:

  • 글로벌: $TELEPORT_GLOBAL_TSH_CONFIG 환경 변수를 통해 설정되며, 제공되지 않으면 비윈도우 운영 체제에서 기본값으로 /etc/tsh.yaml이 됩니다.
  • 사용자별: $TELEPORT_HOME/config/config.yaml, 기본값으로 ~/.tsh/config/config.yaml에 해당합니다.

tsh는 사용자별 구성과 글로벌 구성을 병합합니다. 충돌이 발생하는 경우 (즉, 두 파일에서 동일한 별칭이 정의된 경우) 사용자별 구성이 더 높은 우선 순위를 가집니다.

다음과 같이 해당 파일 중 하나에서 별칭을 정의할 수 있습니다:

aliases:
    "l": "tsh login --auth=okta"

이제부터 tsh ltsh login --auth=okta로 해석됩니다.

tsh 명령의 기본값을 변경할 수도 있습니다:

aliases:
    "status": "tsh status --format=json"

외부 프로그램을 걷어내는 것도 가능합니다:

aliases:
    "connect": "bash -c 'tsh login $0 && tsh ssh $1'"

위의 예시는 변수 $0$1를 사용하는 것입니다. 이 변수는 별칭에 제공된 인수를 나타냅니다. 위의 정의로 tsh connect foo barbash -c 'tsh login foo && tsh ssh bar'로 해석됩니다.

별칭은 필요에 따라 몇 개의 인수를 사용할 수 있습니다. 너무 적은 인수로 별칭이 호출되면, tsh는 오류를 보고합니다. 반면에 추가 인수를 제공하는 것은 오류가 아닙니다. tsh는 추가 인수를 별칭 정의의 끝에 추가합니다.

다음과 같은 구성이 있는 경우:

aliases:
    "example": "bash -c 'echo first=$0 $0-$1 $3'"

tsh example 0 1 unused-2 3 unused-4bash -c 'echo first=0 0-1 3 unused-2 unused-4'로 확장됩니다.

별칭 정의에서 $TSH 변수를 추가할 수도 있습니다. 별칭을 호출할 때 tsh는 이를 현재 tsh 실행 파일의 절대 경로로 확장합니다. 이렇게 하면 여러 tsh 버전이 설치된 경우나 현재 사용 중인 버전이 PATH에 없는 경우 유용할 수 있습니다.

aliases:
    "status": "$TSH status --format=json"

별칭 치환은 명령줄 플래그가 완전히 구문 분석되기 전에 발생합니다. 따라서 --debug 플래그에 의해 영향을 받지 않습니다. 별칭을 문제 해결하기 위해서는 TELEPORT_DEBUG=1 환경 변수를 설정하면 됩니다. 그러면 tsh 로그가 콘솔에 출력됩니다:

$ TELEPORT_DEBUG=1 tsh status
DEBU [TSH]       Self re-exec command: tsh [status --format=json]. tsh/aliases.go:203
...

기록된 세션 검사

tsh를 사용하여 사용자가 Teleport가 보호하는 리소스에서 완료한 세션을 검사할 수 있습니다. 이 섹션에서는 tsh로 Teleport 세션 녹화를 나열하고 재생하는 방법을 설명합니다.

세션 녹화는 Teleport 웹 UI에서도 플레이할 수 있습니다. 그렇게 하려면 왼쪽 사이드바에서 Access Management 탭으로 이동하여 Session Recordings 탭을 확인합니다.

녹화 목록

다음 명령을 실행하여 기록된 세션을 검토합니다:

tsh recordings ls
ID 유형 참가자 호스트 이름 타임스탬프------------------------------------ ---- ------------ -------- -------------------b0a04442-70dc-4be8-9308-7b7901d2d600 ssh jeff dev Nov 26 16:36:16 UTCc0a02222-70dc-4be8-9308-7b7901d2d600 kube alice Nov 26 20:36:16 UTCd0a04442-70dc-4be8-9308-7b7901d2d600 ssh navin test Nov 26 16:36:16 UTC

녹화 재생

세션 녹화를 재생하려면 tsh play 명령과 함께 tsh recordings ls에서 반환된 세션의 ID를 사용합니다:

tsh play c0a02222-70dc-4be8-9308-7b7901d2d600

아래 명령을 사용하여 세션 녹음이 포함된 TAR 파일로 tsh play를 실행할 수도 있습니다:

tsh play ./my-recording.tar

세션 녹화를 포함한 TAR 파일을 검색하려면 세션 녹화 백엔드에 접근할 수 있어야 합니다. 이는 자가 호스팅 Teleport 클러스터 또는 외부 감사 저장소를 요구합니다.

tsh play 명령은 기록된 세션이 상호작용하는 리소스의 종류에 따라 세 가지 형식 중 하나로 재생할 수 있습니다. 형식을 선택하려면, tsh play--format 플래그를 사용하세요:

--format지원되는 리소스설명
pty (기본값)서버, Kubernetes 클러스터tsh는 세션에서 실행된 각 명령을 재생하기 위해 가상 터미널을 엽니다.
json서버, Kubernetes 클러스터, 애플리케이션, 데이터베이스tsh는 감사 이벤트의 JSON 직렬화된 목록을 출력하며, 각 이벤트는 줄로 구분됩니다.
yaml서버, Kubernetes 클러스터, 애플리케이션, 데이터베이스tsh는 감사 이벤트의 YAML 직렬화된 목록을 출력하며, 각 이벤트는 --- 문자로 구분됩니다.

tsh 구성 파일

tsh의 동작을 제어하기 위해 구성 파일을 사용할 수 있습니다. 구성 파일은 위치에 따라 범위가 다릅니다:

  • /etc/tsh.yaml은 글로벌 공유 구성 설정의 기본 위치입니다. 이 위치는 TELEPORT_GLOBAL_TSH_CONFIG 환경 변수를 사용하여 재정의할 수 있습니다.
  • $TELEPORT_HOME/config/config.yaml은 사용자별 구성 설정의 기본 위치입니다. TELEPORT_HOME의 기본 위치는 ~/.tsh입니다.

tsh는 두 구성 파일 위치의 설정을 병합하며, 사용자 구성 설정이 우선합니다.

추가 프록시 헤더

tsh 구성 파일은 요청을 Teleport 프록시 서버에 포함하는 HTTP 헤더를 지정할 수 있습니다. 이 요청은 proxy 필드와 일치하는 주소에 대해 진행됩니다.

add_headers:
  - proxy: "*.example.com" # 일치하는 프록시에는 헤더가 포함됩니다
    headers: # 헤더는 HTTP 요청에 포함할 쌍입니다
      foo: bar # HTTP 요청에 포함될 키/값

예를 들어, 중간 HTTP 프록시가 존재할 경우 헤더 추가가 유용할 수 있습니다. 이는 인증 토큰 설정을 요구할 수 있습니다:

add_headers:
  - proxy: "*.infra.corp.xyz"
    headers:
      "Authorization": "Bearer tokentokentoken"

별칭

별칭을 사용하여 사용자 지정 명령 또는 기존 명령의 기본 플래그 값을 변경할 수 있습니다. 다음 구문을 사용합니다:

aliases:
    "<alias>": "<command>"

<alias>는 최상위 서브 명령만이 될 수 있습니다. 예를 들어, tsh mycommand 별칭을 정의할 수 있지만, tsh my command는 정의할 수 없습니다.

새 명령 tsh l은 다음과 같이 정의할 수 있습니다:

aliases:
    "l": "tsh login --auth=okta"

tsh status를 기본적으로 JSON을 사용하도록 수정하려면 다음과 같이 작성합니다:

aliases:
    "status": "tsh status --format=json"

별칭은 임의의 수의 인수를 사용할 수 있습니다. 인수 변수 $N가 참조되면 tsh는 최소한 N+1 인수가 별칭 호출에 제공되었는지 확인합니다. 참조되지 않은 모든 인수는 마지막에 추가됩니다.

사용자 정의 명령을 정의하는 구문은 다음과 같습니다. $0$1 변수는 인수를 나타냅니다:

aliases:
    "connect": "bash -c 'tsh login $0 && tsh ssh $1'"

첫 번째 인수가 --auth 옵션을 지정하는 커스텀 로그인 명령을 정의할 수도 있습니다:

aliases:
    "ap": "tsh login --auth=$0 --proxy=teleport.example.com"

다음과 같은 구성이 있는 경우:

aliases:
    "example": "bash -c 'echo first=$0 $0-$1 $3'"

tsh example 0 1 unused-2 3 unused-4bash -c 'echo first=0 0-1 3 unused-2 unused-4'로 확장됩니다.

별칭 정의에서 $TSH 변수를 사용할 수 있습니다. 별칭을 호출할 때 tsh는 이를 현재 tsh 실행 파일의 절대 경로로 확장합니다. 이는 여러 tsh 버전이 설치된 경우 유용할 수 있습니다:

aliases:
    "status": "$TSH status --format=json"

별칭 치환은 명령 줄 플래그가 완전히 구문 분석되기 전에 발생합니다. 이는 --debug 플래그의 영향을 받지 않습니다. 별칭 문제를 해결하기 위해 TELEPORT_DEBUG=1 환경 변수를 설정하면 자세한 로그가 오류에 출력됩니다:

$ TELEPORT_DEBUG=1 tsh status
DEBU [TSH]       Self re-exec command: tsh [status --format=json]. tsh/aliases.go:203
...

tsh 제거

tsh와 관련된 사용자 데이터를 제거하려면 Teleport 제거하기를 참조하세요.

추가 읽기

모든 tsh 명령 및 옵션에 대해서는 tsh CLI 참조를 읽어보세요.

Teleport 원문 보기