첫째, 배경지식입니다.
현재 소수의 Linux 서버만 있는 Windows Server AD 환경을 주로 사용하는 경우 SSH를 통해 서버에 인증할 수 있습니다.
- 인증서 인증을 사용하여 SSH를 통해 Linux 서버 관리(일반적인 Linux 방식)
- Linux 서버를 AD 도메인(영역+sssd)에 가입시키고 사용자 이름/비밀번호 인증을 사용하여 SSH를 통해 관리하세요.
문제는 옵션 1에서는 관리자가 나머지 환경과 별도의 자격 증명 세트를 관리하도록 하고 옵션 2에서는 시스템이 서로를 완전히 식별하기 전에 관리자가 네트워크를 통해 원격 서버에 직접 비밀번호를 제공한다는 것입니다.
Windows 세계에서는 네트워크 수준 인증을 통해 이 문제가 해결됩니다(적어도 RDP의 경우 피해야 한다고 알고 있음). 프로세스의 단순화된 버전은 다음과 같습니다.
- 사용자가 원격 컴퓨터에 연결을 시작합니다.
- 원격 컴퓨터는 AD 컴퓨터 계정 토큰으로 응답합니다.
- 로컬 컴퓨터가 토큰의 유효성을 검사하고, NLA 지원을 확인하고, 사용자에게 자격 증명 대화 상자를 표시합니다.
- 사용자가 자격 증명으로 대화 상자를 완료합니다.
- 로컬 컴퓨터는 원격 컴퓨터가 아닌 도메인 제어를 통해 자격 증명의 유효성을 검사합니다.
- DC는 로컬 컴퓨터에 인증 토큰을 제공합니다.
- 로컬 컴퓨터가 원격 컴퓨터에 토큰을 제공합니다.
- 원격 컴퓨터는 도메인에 대해 토큰의 유효성을 검사합니다.
- 성공하면 사용자는 원격 컴퓨터에 액세스할 수 있습니다.
실제로 프로세스는 훨씬 더 간단할 수 있습니다. 사용자가 로컬 컴퓨터에 처음 로그인할 때 생성된 기존 인증 토큰을 이미 사용할 수 있기 때문입니다.
이것은 복잡한 과정이므로 설명하는 데 확실히 오류가 있었습니다. 요점은 인증 토큰이 Linux 스토리의 인증서를 대신하므로 사용자가 잠재적으로 알려지지 않은 시스템에 실제 자격 증명을 제공하지 않는다는 것입니다. 게다가 신뢰할 수 있는 DC에 대한 모든 당사자의 의존은 Linux 이야기보다 상황을 훨씬 더 좋게 만듭니다. 왜냐하면 사용자는 자신의 소프트웨어(제공되는 소프트웨어가 아니라)를 통해서도 자신의 인증서를 관리할 필요가 없기 때문입니다.
이제 질문입니다. 서버가 사용자 자격 증명을 볼 수 없지만 사용자 경험은 여전히 Windows 기본 자격 증명 유효성 검사인 AD에 가입된 Linux 서버에 대한 SSH 세션을 인증하기 위해 비슷한 것을 얻을 수 있는 방법이 있습니까?
답변1
해결해야 할 부분이 많지만 본질적으로 필요한 것은 "kerberized" SSH 등입니다. NLA는 또한 인증이 검증될 때까지 콘솔 세션(생성하는 데 리소스 측면에서 비용이 많이 듭니다)을 제공하지 않는 추가 단계(여기에는 지정되지 않음)를 제공합니다.
더 중요한 것은, 엄청나게 복잡한 복잡성을 제외하면 이미 해결 방법이 있기 때문에 이에 대해 큰 관심이 없다고 봅니다. 요새 점프 호스트를 사용하여 Linux 호스트를 프런트엔드하고 다른 호스트의 액세스/포트 유형을 허용하지 않습니다. 해당 요새 호스트는 Windows일 수 있으며 누락된 모든 기능을 지원할 수 있습니다.
또한 보호된 리소스에 대한 RDP와 같은 액세스 유형을 허용하기 위해 AD 환경에서 배스천 점프 호스트가 점점 일반화되고 있습니다.
또한 RDP 예의 경우 자격 증명은 실제로 서버로부터 보호되지 않습니다. 이는 /RemoteGuard 스위치를 사용하여 해결됩니다.
https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc