내 경험에 따르면 사용자는 공개 키와 개인 키로 인프라를 낭비합니다. openssh는 공개 키를 특정 디렉터리로 제한하는 것을 허용하지만(이를 통해 많은 수의 키가 생성되는 것을 방지) 개인 키에 대해 유사한 메커니즘을 제공하지 않습니다(기본값을 정의할 수는 있지만 강제로 적용할 수는 없습니다).
이상적으로는 비밀번호나 패스프레이즈(Ssh 에이전트의 초기 패스프레이즈 제외)를 입력하지 않고도 호스트에 액세스할 수 있기를 바랍니다.
내 $WORK 사용자가 MS-Windows에서 putty를 사용하여 ssh 여행을 시작했지만 나는 그들이 사용 가능한 개인 키를 ssh 서버 역할을 하는 시스템에 복사하는 것을 방지하는 데에만 관심이 있습니다.
이러한 대상 호스트는 다른 곳에서 SSH 연결을 설정할 수 있어야 하므로 나가는 SSH 연결을 단순히 차단할 수는 없습니다.
전체 권한 있는 액세스 솔루션을 구현하지 않고 사용자가 키 쌍을 사용하여 인증할 수 있지만 개인 키를 복사하는 것을 방지할 수 있는 방법이 있습니까(또는 자체 키를 생성하고 개인/공개 키 배포)?
답변1
당신은 할 수 없습니다. 시스템에서 파일을 읽을 수 있는 사람은 누구나 파일을 복사할 수 있으며, 이것이 파일 시스템이 작동하는 방식입니다. 파일을 읽는 파일 복사 프로그램은 파일을 읽는 다른 프로그램과 다르지 않습니다.
그러나 사용자에게 프록시를 전달하기만 하면 다른 서버에 로그인하려는 목표를 달성할 수 있다고 설명하고 연결이 설정될 때 이를 수행하는 방법에 대한 지침을 제공하면 이보다 쉽고 쉽다는 것을 깨닫게 될 것입니다. 키를 복사합니다. 이것이 우리 작업에서 수행되는 작업입니다. 사용자에게 쉘 호스트에 대한 액세스를 설정하도록 지침(OpenSSH용)을 제공하고 프록시를 전달하기 위한 지침을 설정하도록 지시합니다(다른 시스템에 액세스하는 데 필요하므로). 그러면 그들은 이것저것을 합니다. SSH 개인 키를 셸 호스트에 복사할 필요가 없으므로 그럴 필요도 없습니다.
설명에서 언급했듯이 사용자가 하드웨어 보안 키로 지원되는 SSH 키를 사용하는 경우 문제가 효과적으로 해결됩니다. 개인 키 복사를 막지는 못하지만, 원격 시스템에 하드웨어 보안 키를 연결하지 않으면 개인 키가 작동하지 않으므로 이 동작이 억제됩니다. 그러나 이 기능이 작동하려면 상대적으로 새로운 버전의 OpenSSH가 필요하며 Windows 버전의 OpenSSH가 이 기능을 지원하는지 확실하지 않습니다. 하지만 그 외에는 이런 일이 발생하는 것을 막을 수 있는 방법이 없습니다.
답변2
ssh-agent나는 "프록시 전달"이라는 기술이 사용자가 SSH(요새?) 호스트에 개인 키를 두는 것을 방지하는 방법이 될 수 있다고 생각합니다 . 나는 이것을 직접 사용하지 않았지만 작동 방식에 대한 이해는 다음과 같습니다.
- 사용자가 SSH 세션을 열면 SSH 에이전트가 사용자의 홈 컴퓨터에서 실행되고 에이전트는 사용자의 개인 키를 캐시합니다. 그들이 귀하의 서버에 SSH로 접속할 때, 그들의 SSH 클라이언트는 에이전트에게 주요 질문에 응답하도록 요청한 다음 귀하의 서버에 로그인합니다.
- 서버의 로컬 SSH 구성은 SSH 연결을 통해 홈 컴퓨터에서 SSH 클라이언트(그리고 에이전트)로 주요 챌린지를 다시 전송하도록 SSH 클라이언트에 지시합니다.
- SSH 호스트에서 다른 서버로 SSH를 통해 연결하면 주요 질문이 홈 컴퓨터로 반환되고 에이전트가 응답합니다. 서버에는 개인 키가 필요하지 않습니다.
다음 URL에서 가이드에 대한 참조를 보았습니다.https://docs.github.com/en/developers/overview/using-ssh-agent-forwarding, 하지만 나는 그것을 잠깐 살펴보았습니다. 자세한 내용은 Steve Friedl이 작성한 가이드에 대한 링크가 있습니다.
이것은 사람들이 전화하는 것을 막기에는 충분하지 않을 수 있지만 ssh -i symcbean_hates_this_key_fileSSH 서버에서 키를 사용하는 자동화된 방법이 있다면 아마도 대부분의 사람들이 전화를 끊을 것입니다.