Infograb logo
Teleport 녹화 프록시 모드

Teleport 녹화 프록시 모드는 Teleport 사용자가 sshd 를 실행하는 서버에 대한 세션 녹화를 활성화할 수 있도록 추가되었습니다. 이는 대규모 서버 환경을 Teleport로 점진적으로 전환하는 데 유용합니다.

Teleport OpenSSH 녹화 프록시

Teleport Cloud는 노드 수준에서만 세션 녹화를 지원합니다. 세션 녹화를 설정하려는 경우, OpenSSH 서버를 Teleport 노드로 교체할 수 있도록 서버 액세스 시작하기 가이드 를 참조하십시오.

우리는 녹화 프록시 모드가 다음 두 가지 이유로 노드 수준에서의 녹화보다 덜 안전하다고 생각합니다:

  • Teleport 프록시 서비스에 추가 권한이 부여됩니다. 기본 노드 녹화 모드에서는 프록시 서비스가 비밀 정보를 저장하지 않으며, 해독된 데이터를 "볼" 수 없습니다. 이로 인해 프록시 서버는 전체 클러스터 보안에 덜 중요해집니다. 그러나 공격자가 프록시 녹화 모드에서 실행 중인 프록시 서버에 물리적으로 접근하게 되면, 해독된 트래픽과 프록시 서버의 프로세스 메모리에 저장된 클라이언트 키를 볼 수 있게 됩니다.
  • 녹화 프록시 모드는 SSH 에이전트 포워딩을 요구합니다. 에이전트 포워딩이 없으면, 프록시 서버는 목적지 노드에 대한 두 번째 연결을 설정할 수 없습니다.

Teleport 프록시 서비스는 클라이언트에 제공되어야 하며 TLS로 설정되어야 합니다.

필수 조건

  • 실행 중인 자체 호스팅 Teleport 클러스터. 자체 호스팅 Teleport Enterprise를 시작하려면 영업팀에 문의하십시오. 또한 Teleport Community Edition으로 데모 환경을 설정할 수 있습니다.

  • tctl 관리 도구와 tsh 클라이언트 도구 버전 >= 17.0.0-dev.

    tctltsh 다운로드에 대한 지침은 설치 를 방문하십시오.

  • OpenSSH 서버를 실행할 호스트.
  • 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status

    클러스터 teleport.example.com

    버전 17.0.0-dev

    CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
    자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/3단계. Teleport 구성

Teleport를 운영 환경에서 실행할 때 보안 사고를 피하기 위해 다음의 모범 사례를 준수해야 합니다:

  • 필요하지 않는 한 운영 환경에서 sudo 사용을 피하십시오.
  • 새로운 비루트 사용자를 생성하고 Teleport 실험을 위해 테스트 인스턴스를 사용하십시오.
  • 필요하지 않은 한 비루트 사용자로 Teleport의 서비스를 실행하십시오. SSH 서비스만 루트 액세스를 요구합니다. Teleport가 < 1024 (예: 443 )로 번호 매겨진 포트에서 수신 대기하도록 하려면 루트 권한(또는 CAP_NET_BIND_SERVICE 권한)이 필요합니다.
  • 최소 권한 원칙을 따르십시오. 더 제한적인 역할로도 충분할 때 사용자에게 허용적인 역할을 부여하지 마십시오. 예를 들어, 클러스터 리소스에 액세스하고 편집할 수 있는 권한을 부여하는 내장된 access,editor 역할을 사용자에게 할당하지 마십시오. 대신 각 사용자에 대해 최소한의 필수 권한을 가진 역할을 정의하고 액세스 요청을 구성하여 일시적으로 상승된 권한을 부여하십시오.
  • 새로운 데이터베이스나 애플리케이션과 같은 Teleport 리소스를 등록할 때 초대 토큰을 파일에 저장해야 합니다. 명령줄에 직접 토큰을 입력하면 악성 사용자가 손상된 시스템에서 history 명령을 실행하여 이를 볼 수 있습니다.

이러한 관행이 문서에서 사용된 예제에 반드시 반영되는 것은 아닙니다. 문서의 예제는 주로 데모 및 개발 환경을 위한 것입니다.

경고

운영 인스턴스, 환경 및/또는 설정을 영구 수정하기 전에 백업하는 것은 모범 사례로 권장됩니다. 이를 통해 필요할 경우 기존 상태로 롤백할 수 있습니다.

프록시 녹화 모드 활성화

sshd 노드에 대한 세션 녹화를 활성화하려면 클러스터를 녹화 프록시 모드로 전환해야 합니다. 이 모드에서는 녹화가 프록시 수준에서 이루어집니다.

Auth 서비스 구성 파일을 아래와 같이 편집하십시오:

# /etc/teleport.yaml의 스니펫
auth_service:
  # OpenSSH와 함께 작동하려면 세션 녹화가 프록시로 설정되어야 합니다.
  session_recording: "proxy" # "off" 및 "node" (기본값) 도 있습니다.

선택적 불안전 단계: 엄격한 호스트 검사 비활성화

녹화 모드에서는 Teleport가 사용자가 연결하는 모든 노드의 호스트 인증서가 Teleport CA에 의해 서명되었는지 확인합니다. 기본적으로 이는 엄격한 검사입니다. 노드가 단순히 키 또는 다른 CA에 의해 서명된 인증서를 제시하면, Teleport는 다음과 같은 오류 메시지와 함께 이 연결을 거부합니다:

ssh: handshake failed: remote host presented a public key, expected a host
certificate

아래와 같이 엄격한 호스트 검사를 비활성화할 수 있습니다. 그러나 이는 중간자 공격의 가능성을 열어주며 권장되지 않습니다.

# /etc/teleport.yaml의 스니펫
auth_service:
  proxy_checks_host_keys: no

2/3단계. sshd 구성

sshd 는 사용자가 Teleport 사용자 CA에 의해 생성된 인증서로 로그인할 수 있도록 허용해야 합니다. 먼저 Teleport CA 공개 키를 내보내십시오.

Teleport 노드에서, Teleport 인증기관 인증서를 파일로 내보내고 SSH 구성에서 Teleport의 CA를 신뢰하도록 업데이트하십시오. proxy를 Teleport 프록시 서비스의 주소에 할당하십시오:

curl 'https://proxy/webapi/auth/export?type=user' | sed s/cert-authority\ // > teleport_user_ca.pub
sudo mv ./teleport_user_ca.pub /etc/ssh/teleport_user_ca.pub
echo "TrustedUserCAKeys /etc/ssh/teleport_user_ca.pub" | sudo tee -a /etc/ssh/sshd_config

sshd 를 재시작하십시오.

이제 sshd 는 Teleport가 발급한 인증서를 제시하는 사용자를 신뢰하게 됩니다. 다음 단계는 호스트 인증을 구성하는 것입니다.

추천 솔루션은 Teleport가 모든 OpenSSH 노드에 대해 유효한 호스트 인증서를 발급하도록 요청하는 것입니다. 호스트 인증서를 생성하려면, Teleport Auth 서버에서 다음을 실행하십시오:

접속할 모든 호스트의 배열과 함께 호스트 인증서 생성.

와일드카드 인증서는 OpenSSH에서 지원되지 않습니다. 도메인은 완전하게

명시되어야 합니다.

호스트 인증서 관리는 복잡해질 수 있습니다. 이는 노드에서 Teleport SSH 사용을 추천하는 또 다른 이유입니다.

sudo tctl auth sign \ --host=api.example.com,ssh.example.com,64.225.88.175,64.225.88.178 \ --format=openssh \ --out=api.example.com

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

ssh-keygen을 사용하여 내용을 확인할 수 있습니다.

ssh-keygen -L -f api.example.com-cert.pub

api.example.com-cert.pub:

Type: ssh-rsa-cert-v01@openssh.com 호스트 인증서

Public key: RSA-CERT SHA256:ireEc5HWFjhYPUhmztaFud7EgsopO8l+GpxNMd3wMSk

Signing CA: RSA SHA256:/6HSHsoU5u+r85M26Ut+M9gl+HventwSwrbTvP/cmvo

Key ID: ""

Serial: 0

Valid: after 2020-07-29T20:26:24

Principals:

api.example.com

ssh.example.com

64.225.88.175

64.225.88.178

Critical Options: (none)

Extensions:

x-teleport-authority UNKNOWN OPTION (len 47)

x-teleport-role UNKNOWN OPTION (len 8)

그런 다음 모든 OpenSSH 노드의 /etc/ssh/sshd_config 에 다음 줄을 추가하고 sshd 를 재시작하십시오.

HostKey /etc/ssh/api.example.com
HostCertificate /etc/ssh/api.example.com-cert.pub

3/3단계. 프록시 녹화 모드 사용하기

이제 tsh ssh 명령어를 사용하여 클러스터의 모든 sshd 노드에 로그인할 수 있으며, 세션이 녹화됩니다.

기본 ssh 포트 22를 사용하여 tsh ssh

tsh ssh --port=22 user@host.example.com

Amazon EC2 호스트 예시

tsh ssh --port=22 ec2-user@ec2-54-EXAMPLE.us-west-2.compute.amazonaws.com

프록시 뒤에 있는 sshd 서버에 "녹화 모드"로 로그인하기 위해 OpenSSH ssh 클라이언트를 사용하려면, ssh 클라이언트에게 점프 호스트를 사용하고 SSH 에이전트 포워딩을 활성화하라고 알려야 합니다. 그렇지 않으면 녹화 프록시가 SSH 연결을 종료하여 이를 기록할 수 없습니다:

에이전트 포워딩이 두 번 활성화된다는 점에 유의하십시오: 클라이언트에서 프록시로

(녹화 프록시 사용 시 필수) 그리고 선택적으로 프록시에서 최종 서버로

에이전트가 최종 서버에서 실행되기를 원하는 경우

ssh -o "ForwardAgent yes" \ -o "ProxyCommand ssh -o 'ForwardAgent yes' -p 3023 %r@p.example.com -s proxy:%h:%p" \ user@host.example.com

모든 것을 입력하는 것을 피하고 일반적으로 ssh user@host.example.com 을 사용하려면, 사용자는 ~/.ssh/config 파일을 업데이트할 수 있습니다.

로그인한 후 Teleport 인증서가 에이전트에 로드되었는지 확인하십시오:

Joe로 로그인

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

인증서가 존재하는지 확인 (인증서 끝에 "teleport:joe"를 찾으십시오)

ssh-add -L
GNOME Keyring SSH 에이전트 및 GPG 에이전트

Ubuntu와 같은 많은 인기 있는 리눅스 데스크탑에서 사용되는 Gnome Keyring SSH 에이전트와 GnuPG의 gpg-agent 는 SSH 인증서를 지원하지 않는 것으로 잘 알려져 있습니다. OpenSSH의 ssh-agent 사용을 권장합니다. 대안으로, --no-use-local-ssh-agent 플래그나 TELEPORT_USE_LOCAL_SSH_AGENT=false 환경 변수를 사용하여 SSH 에이전트 통합을 완전히 비활성화할 수 있습니다.

OpenSSH 속도 제한

"녹화 모드"에서 Teleport 프록시를 사용할 때 OpenSSH의 내장 속도 제한에 유의하십시오. Proxy Service 연결의 수가 많은 경우 다음과 같은 오류가 발생할 수 있습니다:

channel 0: open failed: connect failed: ssh: handshake failed: EOF

man sshd_configMaxStartups 설정을 참조하십시오. 이 설정은 기본적으로 OpenSSH가 한 번에 10개의 인증되지 않은 연결만 허용하며, 연결 수가 10을 초과할 때 30%의 확률로 연결을 끊기 시작합니다. 100개의 인증 연결에 도달하면 모든 새로운 연결이 끊어집니다.

동시성 수준을 높이려면 값을 MaxStartups 50:30:100 과 같이 늘리십시오. 이렇게 하면 50개의 동시 연결과 최대 100개의 연결이 허용됩니다.

Teleport 원문 보기