PowerShell Remoting (PSRemoting)은 PowerShell의 가장 많이 사용되는 기능 중 하나입니다. 왜냐하면 너무 유용하기 때문입니다! 하나의 명령을 사용하여 원격 컴퓨터 하나 또는 수천 대에 신속하게 연결하고 명령을 실행할 수 있습니다.
이 최종 가이드에서는 PSRemoting에 대해 자세히 알아보겠습니다. PSRemoting이 무엇인지, 작동 방식은 어떤지, 그리고 PSRemoting이 작동하는 다양한 기술에 대해 알게 될 것입니다. 이 가이드에서는 PSRemoting의 사용 방법을 다루지 않습니다. 대신 많은 사용 설명서에 대한 참조가 있을 것입니다.
PSRemoting 작동 방식
간단히 말해서, PSRemoting은 마치 컴퓨터 앞에 앉아 있는 것처럼 원격 컴퓨터에서 명령을 실행할 수 있게 해줍니다. PSRemoting은 사용자의 연결 및 인증, 원격 명령 실행 및 해당 명령의 모든 출력을 로컬 컴퓨터로 반환하는 기능 세트를 제공합니다.
PSRemoting을 telnet이나 SSH 또는 psexec과 같은 것으로 생각해보세요. PowerShell 내에서 컴퓨터에서 명령을 실행하는 방법입니다.
PSRemoting은 세션이라는 개념에 크게 의존합니다. 세션은 내부에서 명령을 실행하는 원격 셸을 설명하는 용어입니다. 이러한 세션을 생성하는 과정은 백그라운드에서 많은 단계를 거칩니다.
PSRemoting 세션을 시작하면, 다음과 같은 대략적인 단계가 진행됩니다:
- 클라이언트는 목적지 서버에 WinRM 리스너에 연결을 시도합니다 (WinRM 리스너에 대한 자세한 내용은 아래에서 설명합니다). WinRM 리스너는 목적지 서버에서 실행되는 작은 웹 서비스입니다. WinRM은 Microsoft의 WSMan이라는 표준의 구현입니다. WSMan은 Dell, Intel, Sun Microsystems와 같은 많은 다른 대형 기술 회사들과 함께 개발된 개방형 표준입니다.
- 클라이언트가 HTTP 또는 HTTPS 프로토콜을 통해 리스너에 연결하면 인증 프로세스가 시작됩니다. 인증의 각 방법에 대한 세부 정보는 나중에 다룰 것이지만, 일단은 클라이언트가 어떤 방식으로든 서버에 자격 증명을 전달해야 한다는 것을 알아두세요.
- 클라이언트가 서버에 연결하고 인증되면 PSRemoting은 세션을 생성합니다.
- PSRemoting이 세션을 생성한 후에는 비즈니스 운영을 시작할 수 있습니다. 이 시점에서 클라이언트는 서버에 정보를 보내고, 서버는 필요한 출력을 반환하는 직렬화라고 하는 통신을 시작할 수 있습니다. 이 통신은 일반적으로 암호화됩니다.
WinRM 리스너: 연결 가능
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
winrm 명령을 사용하여 Windows 컴퓨터에서 실행 중인 모든 WinRm 리스너를 확인할 수 있습니다.
WinRm 리스너에는 몇 가지 중요한 구성 요소가 있습니다. 이들은 다음과 같습니다:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- 전송 유형 – 각 WinRM 수신자는 클라이언트와 통신하기 위한 방법이 필요하며, 이를 HTTP 또는 HTTPS를 사용하여 전송합니다.
- 선택적으로 인증서 썸프린트 – WinRM 수신자가 전송에 HTTPS를 사용하는 경우, 클라이언트와 인증하기 위한 개인 키를 알아야 합니다. 이 키는 인증서 썸프린트를 사용하여 찾을 수 있습니다.
가능한 경우 HTTPS 수신자를 사용하세요. HTTPS 전송을 설정하면 서버의 유효성을 보장하고 인증 및 전송 트래픽을 암호화하여 보안을 높일 수 있습니다. 인증서를 발급할 때는 자체 서명된 인증서가 아닌 신뢰할 수 있는 인증 기관에서 발급하는 것이 좋습니다.
신뢰할 수 있는 호스트: 서버 검증
WinRM을 통한 PSRemoting 인증 작동 방식
위에서 언급했듯이, PSRemoting이 수행하는 첫 번째 단계 중 하나는 인증입니다. 인증은 가장 복잡하지만 가장 필수적인 PSRemoting의 부분 중 하나입니다.
PSRemoting이 처음 도입될 때는 Windows 원격 관리 (WinRM)라는 인증 메커니즘 하나만 사용할 수 있었지만, 요즘에는 SSH를 사용하여 인증할 수도 있습니다. 이후에 자세히 설명하겠습니다.
WinRM은 두 가지 다른 유형의 인증을 지원합니다. 사용자 이름과 암호 또는 인증서를 사용한 다양한 유형의 사용자 이름/암호 조합에 대한 인증입니다.
기본 인증
가장 쉽지만 가장 안전하지 않은 인증 유형은 기본 인증입니다. 이 유형의 인증은 HTTP 프로토콜에 내장된 표준입니다. 기본 인증은 클라이언트에서 수신기로 HTTP 헤더에 사용자 이름과 비밀번호를 base64로 인코딩하여 전송합니다.
기본 인증은 사용자 이름과 비밀번호를 인코딩만 하고 암호화하지 않기 때문에 네트워크에서 자격 증명을 가로채는 것이 간단합니다.
절대로 꼭 필요하지 않은 한 기본 인증을 사용하지 마십시오. WinRM에서는 더 안전한 인증 방법이 많이 있습니다!
커버로스 인증
클라이언트와 서버가 모두 Active Directory 환경에 있는가요? 그렇다면 이미 여러 네트워크 서비스에서 커버로스 인증을 사용하고 있습니다.
WinRM 클라이언트가 커버로스를 통해 WinRM 수신기에 연결을 시도할 때:
- 서버는 먼저 도메인 컨트롤러에서 클라이언트의 세션 키 또는 티켓 발급 티켓을 검색하려고 시도합니다.
- 도메인 컨트롤러는 클라이언트와 서버를 조회하고 둘 다 유효하고 신뢰할 수 있다면 토큰을 발급합니다.
- 서버는 그 신뢰할 수 있는 토큰을 사용하여 사용자 이름과 비밀번호 대신 클라이언트의 연결을 검증합니다.
Kerberos 인증 중에 도메인 컨트롤러는 티켓 검색 단계에서 클라이언트와 서버 양쪽을 확인하여 악의적인 사람이 서버를 가장하는 것을 막습니다.
Kerberos는 안정적이고 안전한 인증 방법으로, 클라이언트와 서버가 모두 Active Directory 도메인의 구성원인 경우 기본 인증 유형입니다. 그러나 클라이언트와 서버가 동일한 Active Directory 포레스트에 가입되어 있거나 포레스트 간에 신뢰 설정이 되어 있어야 합니다.
Negotiate 인증
WinRm은 Kerberos를 사용하려고 시도하고 사용할 수 없을 경우 NT Lan Manager (NTLM)이라는 인증 프로토콜을 사용하려고 시도합니다.
NTLM을 사용할 때:
- 서버는 클라이언트에게 문자열을 보냅니다.
- 그런 다음 클라이언트는 이 문자열을 사용자의 암호의 해시로 암호화합니다.
- 암호화된 문자열은 다시 서버로 보내지며, 서버는 사용자 이름, 원래 문자열 및 암호화된 문자열을 도메인 컨트롤러로 전송합니다.
- 도메인 컨트롤러는 해당 사용자의 비밀번호 해시를 찾아 문자열에 대해 동일한 암호화 과정을 반복하여 일치 여부를 확인합니다.
NTLM은 클라이언트를 인증하는 데에 좋지만, Kerberos와 달리 서버를 인증하지는 않습니다. 이로 인해 서버가 공격자에 의해 위장될 수 있는 여러 공격 경로가 열립니다.
서버 인증서를 사용하여 서버도 인증하고 HTTPS WinRM 리스너에 할당함으로써 NTLM 보안을 개선할 수 있습니다. 이 설정에서 클라이언트는 도메인 컨트롤러에 대해 NTLM으로 인증되고, 서버는 신뢰할 수 있는 인증서로 인증됩니다. 이 설정은 클라이언트와 서버 인증을 모두 제공하지만, NLTM 프로토콜은 오래된 암호화 알고리즘과 키 크기를 사용합니다.
이러한 이유로 인해 NLTM은 서버를 신뢰하는 호스트 목록에 추가하거나 HTTPS 리스너를 사용하는 경우에만 사용할 수 있습니다.
다이제스트 인증
WinRM에서 사용하는 가장 흔하지 않은 인증 방법 중 하나는 다이제스트 인증입니다. NTLM과 다이제스트는 유사한 인증 방식입니다. NTLM과 마찬가지로, 다이제스트는 사용자의 암호 해시로 암호화된 고유한 문자열을 생성합니다. 그런 다음 암호는 서버로 전송할 필요가 없습니다.
다이제스트는 MD5 해시 알고리즘을 사용하여 암호를 암호화합니다. 이 알고리즘 선택 때문에 다이제스트는 일반적으로 구식으로 간주되고 사용되지 않아야 합니다. MD5에는 암호학적 사용에 적합하지 않은 여러 알려진 취약점이 있습니다.
CredSSP(자격 증명 보안 지원 공급자)
대충 CredSSP에 대해 자세히 설명할 수는 있지만 필요하지 않습니다. 왜냐하면 PSRemoting과 WinRM에서 CredSSP를 구현하는 일반적인 이유는 “두 번째 점프 문제”입니다. 이에 대해 아래에서 배워보겠습니다.
CredSSP 인증이 구성되면, WinRM 클라이언트와 서버는 모두 Negotiate 인증을 사용하여 사용자와 클라이언트를 인증합니다. 그러나 한 번 완료된 후에는 사용자의 암호가 서버로 전송됩니다.
암호는 인증 프로세스가 완료된 후에 전송되므로 이제 암호화되어 있습니다. CredSSP는 또한 암호를 TLS 세션 키로 암호화하여 암호화된 문자열이 세션 간에 고유하게 됩니다.
CredSSP는 인증 후에 서버가 사용자 대신 다른 것에 연결할 수 있도록 도움이 됩니다. 그러나 이런 경우에는 연결한 서버에 대해 사용자 암호를 완전히 신뢰해야 합니다.
인증서 기반 인증
PSRemoting과 함께 사용하기 가장 안전한 인증 방법은 인증서 기반 인증입니다. 이 인증 방법에서는 클라이언트와 서버 간에 일반적인 키 교환이 발생하며 인증서를 확인합니다.
WinRM는 WinRm 내에서 서버의 사용자를 매핑하여 사용자를 인증합니다. 인증 프로세스 중 전달되는 것은 공개 키뿐이므로 매우 안전한 인증 방법입니다.
가장 안전하지만 인증서 기반 인증은 그리 흔하지 않습니다. 왜냐하면 설정하는 데 필요한 작업이 번거롭기 때문입니다. 다음과 같은 작업을 수행해야 합니다:
- 인증서 기관을 구축합니다.
- 사용자 인증서를 생성합니다.
- 공개 키를 공유합니다.
- 적절한 권한을 가진 로컬 사용자 계정(아마도 관리자 그룹)을 사용합니다.
- HTTPS 수신기를 설정합니다.
- … 그리고 다른 단계들을 수행해야 합니다.
도메인 사용자를 인증서로 인증할 수 없습니다. 클라이언트와 서버가 모두 Active Directory의 일부인 경우에도 마찬가지입니다.
Windows OS 인증 기본값
이제 여러 가지 인증 옵션이 있다는 것을 알았으니, 기본 제공되는 옵션은 어떤 것인지 알고 싶으시겠죠? 아래 표에서는 WinRM 클라이언트가 기본적으로 활성화되고 해당 인증 유형이 기본적으로 활성화되는지 여부를 나타내는 두 개의 열이 있습니다.
앞서 언급한 모든 인증 유형은 구성 가능하지만, 아래 표를 사용하면 직접 구성해야 할 내용을 잘 파악할 수 있습니다.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
두 번째 홉 또는 더블 홉 문제
PSRemoting의 가장 큰 문제 중 하나는 “두 번째 홉 문제” 또는 “더블 홉”으로 알려져 있습니다. 이 상황은 PSRemoting을 통해 원격 시스템에 연결한 다음 다른 원격 컴퓨터에 연결해야 할 때 발생합니다.
이 상황은 문제가 되는데, WinRm 클라이언트가 첫 번째 원격 컴퓨터에 인증을 할 때, 서버는 비밀번호를 서버로 보내지 않고 원래 클라이언트의 신원을 확인합니다. 첫 번째 연결의 서버에서 두 번째 컴퓨터에 연결을 시도할 때, 최종 서버는 사용자의 신원을 확인할 방법이 없습니다.
더블 홉 문제는 CredSSP 또는 Kerberos 위임을 사용하여 몇 가지 다른 방법으로 해결할 수 있습니다.
CredSSP 사용
더블 홉 문제를 해결하는 가장 일반적인 방법은 CredSSP를 사용하는 것입니다. CredSSP 인증은 첫 번째 원격 서버에 사용자 자격 증명을 저장하여 서버로 전달할 수 있도록 합니다.
그러나 CredSSP를 사용하는 데 주의할 점이 있습니다. 첫 번째 원격 서버에 저장된 사용자 자격 증명은 일반 텍스트로 저장될 수 있으므로 보안에 취약성이 존재할 수 있습니다. 최신 운영 체제에서는 비밀번호와 Kerberos Ticket Granting Ticket (TGT)의 해시를 사용합니다. 이들은 일반 텍스트 비밀번호처럼 네트워크 어디에서든 사용자로 인증하는 데 사용될 수 있지만, 약간의 리스크를 감소시킵니다.
협상을 통해 클라이언트와 서버는 서로 자신들이 주장하는 대로 신원을 확인하기 위해 정보를 주고받지만 사용자의 비밀번호는 절대로 액세스할 수 없습니다. 이 보안 기능으로 인해, 1번 서버가 2번 서버에 연결될 때 당신을 인증할 수 있는 방법은 없습니다.
케르버로스 위임 사용
이전에 언급한 대로, 케르버로스는 PSRemoting을 설정하는 일반적인 방법입니다. 보편적으로 사용되는 Active Directory의 일부이며 이미 기본적으로 설정되어 있습니다. 케르버로스 자체로는 WinRM을 인증하는 좋은 방법이지만, 이중 홉 문제를 해결할 수는 없습니다.
이중 홉 시나리오를 피하기 위해, 케르버로스 위임이라고 하는 두 번째 유형의 인증을 사용할 수 있습니다. 케르버로스 위임에는 여러 가지 종류가 있지만, CredSSP 대체로 충분히 안전하고 가능한 유일한 종류는 케르버로스 제약 위임이라고 불리는 특정 목록의 케르버로스(Active Directory) 개체에 제한된 도메인 리소스를 기반으로 케르버로스 인증 토큰을 위임하는 형태입니다.
리소스 기반 케르버로스 제약 위임은 이 경우와 같이 컴퓨터와 같은 도메인 리소스를 기반으로 케르버로스 인증 토큰을 위임하는 형태입니다.
이 Kerberos 위임을 구성하려면 체인의 세 번째 컴퓨터의 ADComputer 개체를 편집해야 합니다. 예를 들어, ClientA에서 ServerB로 이동한 다음 ServerC로 이동한다면, ServerC의 ADComputer 개체를 편집해야 하지만 ServerB도 알고 있어야 합니다. 이 예제에서는 PowerShell에서 다음 명령을 실행하세요:
리소스 기반 Kerberos 위임은 원격 연결에 대해 작동하지만 PSRemoting에서는 작동하지 않습니다. PSRemoting을 사용하여 WinRM을 통해 컴퓨터에 연결된 경우 세 번째 컴퓨터에 연결할 수 없습니다.
리소스 기반 Kerberos 제한된 위임을 설정하기 위해 Set-ADComputer cmdlet을 사용하는 PowerShell 명령어가 있습니다. 예를 들어, PSRemoting을 통해 ServerB에 ClientA에서 연결되어 있고 …를 사용하여 ServerC에 연결하려면 아래 PowerShell 명령어를 실행할 수 있습니다.
WinRM은 실패한 연결을 15분 동안 캐시에 저장합니다. 이 기능으로 인해 리소스 기반 Kerberos 제한된 위임을 설정한 후에도 세 번째 컴퓨터에 연결할 수 없을 수 있습니다. 이를 해결하기 위해 대기하거나 세 번째 컴퓨터에서 명령어
klist purge -LI 0x3e7을 실행하여 실패한 Kerberos 토큰을 삭제할 수 있습니다.
SSH를 통한 PSRemoting 인증 작동 방식
WinRm 인증은 PSRemoting을 위한 가장 일반적인 인증 방법이지만, PowerShell v6부터는 다른 방법을 사용할 수 있습니다. SSH를 인증 방법으로 사용하면 Linux에서 PSRemoting을 사용할 수 있습니다.
WinRm과 달리 SSH는 Windows 클라이언트에 SSH 클라이언트를 설정하는 등 클라이언트와 서버 모두에서 추가 구성이 필요합니다.
인증에 SSH를 사용하는 것은 SSH가 지원하는 인증 유형에 제한을 받는다는 뜻입니다. 이는 주로 암호 기반 및 공개 키 기반으로 두 가지 주요 유형으로 제한됩니다.
SSH에서는 다른 인증 유형도 지원되지만, 암호 및 공개 키 기반 옵션보다 안전성이 낮다고 여겨지므로 이 두 가지에만 초점을 맞출 것입니다.
암호 인증
PSRemoting과 함께 SSH 인증을 설정하는 가장 간단한 방법은 암호 기반 인증을 사용하는 것입니다. 암호 기반 인증을 사용하면 자신을 인증하기 위해 암호를 제공할 수 있습니다.
SSH 인증 과정에서 비밀번호는 SSH 연결이 이루어진 후에 교환되며 전송 중에 비밀번호가 암호화됩니다. Kerberos와 같은 WinRM에서 사용되는 일부 인증 방법과는 달리 이 인증 방법은 비밀번호 전체를 서버로 전송합니다.
SSH 비밀번호 인증은 HTTPS 수신기를 사용하여 WinRM 인증 방법 Basic과 비교할 수 있습니다. 비밀번호 자체는 의미 있는 방식으로 보호되지 않지만, 비밀번호를 포함한 전체 연결은 암호화되며 서버는 인증서를 기반으로 검증됩니다.
인증서 기반 인증(Authentication)
비밀번호 기반 인증은 설정하기 쉽고 사용하기 간단하지만 두 가지 문제가 있습니다.
- 첫째로 안전한 비밀번호 없이 인증하는 방법이 없습니다.
- 비밀번호 인증은 여전히 네트워크를 통해 비밀번호를 전송합니다. 비밀번호는 SSH 연결 내에서 암호화되지만, 서버는 전체 비밀번호를 받습니다. 서버가 어떤 방식으로든 침해당하면 보안 문제가 발생할 수 있습니다.
반면 인증서 기반 인증은 비밀번호와 같은 민감한 데이터를 네트워크를 통해 전송하지 않습니다. 대신, 서버에는 공개 키의 사본이 있고 클라이언트에는 개인 키의 사본이 있으며 협상이 서버에서 진행됩니다.
A rough workflow goes as follows:
- 클라이언트가 인증을 시도하면 공개 키의 ID 또는 지문을 서버로 전송합니다.
- 서버가 허가된 공개 키 목록에 해당 공개 키가 있는 경우, 공개 키로 암호화된 문자열로 응답합니다.
- 그런 다음 클라이언트는 개인 키로 문자열을 복호화합니다.
- 개인 키는 세션 ID와 해시됩니다.
- 세션 ID는 서버로 다시 보내져서 원래 문자열과 세션 ID를 사용하여 생성된 해시와 비교됩니다.
- 클라이언트의 세션 ID 해시와 서버의 세션 ID가 일치하면 클라이언트는 인증되고 연결할 수 있습니다.
공개 키로 암호화된 것은 연관된 개인 키로만 복호화할 수 있습니다. 개인 키로 암호화된 것은 공개 키로만 복호화할 수 있습니다. 세션 ID는 완벽한 전방 비밀 유지(PFS)를 제공하기 위해 사용됩니다.
PFS는 개인 키가 노출되더라도 과거의 모든 메시지를 해독할 수 없도록 보안을 제공합니다. 고유한 세션 ID는 통신을 암호화하는 데 사용되는 공유 비밀이 각 세션마다 다르다는 것을 의미합니다.
WinRm과 마찬가지로 SSH를 사용한 인증에는 개인/공개 키를 생성하고 원격 서버에서 공개 키를 인가하는 추가적인 작업이 필요합니다.
연결에 필요한 사용자 권한
기본적으로 두 개의 로컬 사용자 그룹인 관리자와 원격 관리 사용자가 PSRemoting을 사용하여 원격으로 서버에 연결할 수 있습니다.
원격 서버에 로컬 관리자 그룹에 사용자 계정을 추가할 수는 있지만 항상 최소한의 액세스 권한을 제공해야 합니다. 사용자가 단순히 원격 컴퓨터에 PSRemoting으로 연결해야 하는 경우 사용자 계정을 원격 관리 사용자 그룹에 추가할 수 있습니다. 관리자 그룹에는 추가하지 마십시오.
PSRemoting 액세스를 더욱 제어하려면 Just Enough Administration (JEA)라는 기능을 사용할 수도 있습니다. JEA를 사용하면 비관리자 사용자가 PowerShell의 제한된 언어 모드에서 특정 명령만 관리자로 실행할 수 있습니다.
암시적 vs. “명시적” 원격
이전에 PSRemoting을 사용한 적이 있다면 Invoke-Command, New-PSSession, Enter-PSSession 등과 같은 명령어에 익숙할 것입니다. 이러한 명령을 실행할 때 어떻게 원격 컴퓨터에 연결하는지 명확하게 알 수 있습니다. PSRemoting을 명시적으로 사용하고 있습니다.
PSRemoting 특정 명령을 실행할 때는 해당 명령을 명시적으로 실행하지만 다른 방법도 있다는 것을 알고 계셨나요? 직접 Invoke-Command 및 기타 cmdlet을 호출하는 대신, 암시적으로 PSRemoting을 활용할 수 있습니다.
암시적 PSRemoting은 PowerShell 세션 내에서 명령을 로컬로 실행하는 것처럼 보이지만, 실제로는 원격 컴퓨터에서 실행됩니다. 이것의 좋은 예는 시스템에 설치되지 않은 모듈을 사용하는 경우입니다. 로컬로 설치하는 대신 PSSession에서 명령을 내보내어 로컬로 설치된 것처럼 실행할 수 있습니다.
아래 스크린샷에서는 Test-PendingReboot 명령이 없음을 확인할 수 있습니다. 그런 다음 원격 컴퓨터에 연결하여 해당 명령을 내보냈습니다.
그런 다음 해당 모듈이 가져와지면 Test-PendingReboot 명령을 실행할 수 있습니다. 아래에 표시된 것처럼 출력에 표시되는 컴퓨터 이름은 PowerShell이 실행되는 기기의 이름이 아니라 명령이 가져온 기기의 이름임을 알 수 있습니다.
