SSH 키 관리를위한 최고의 시스템? [닫은]

42

클라이언트 컴퓨터 (예 : 랩톱, 데스크톱 등)가 여러 대 있는데 관리하는 여러 서버 컴퓨터에 연결하고 SSH를 통해 모두 로그인합니다. 의미있는 ssh 키 관리에 대한 여러 가지 계획을 상상할 수 있으며 다른 사람들이하는 일에 대해 궁금합니다.

옵션 1 : 하나의 글로벌 공개 / 개인 키 쌍.

하나의 공개 / 개인 키 쌍을 생성하고 모든 클라이언트 시스템에 개인 키를, 모든 서버 시스템에 공개 키를 배치합니다.

옵션 2 : 서버 시스템 당 하나의 키 쌍.

각 서버 시스템에서 하나의 키 쌍을 생성하고 각 개인 키를 클라이언트 시스템에 배치했습니다.

옵션 3 : 클라이언트 시스템 당 하나의 키 쌍.

각 클라이언트 컴퓨터에는 고유 한 개인 키가 있으며 각 서버 컴퓨터에는 연결하려는 모든 클라이언트 컴퓨터에 대한 공개 키가 있습니다.

옵션 4 : 클라이언트 / 서버 쌍당 하나의 키 쌍

완전히 배 밖으로?

이 중 가장 좋은 것은 무엇입니까? 다른 옵션이 있습니까? 올바른 구성을 평가하기 위해 어떤 기준을 사용합니까?

ssh authentication

— 슬래시
소스

33

내가 사용 옵션 3 : 클라이언트 컴퓨터 당 하나의 키 쌍을 그리고 그것은 나에게 가장 의미가 있습니다. 몇 가지 이유는 다음과 같습니다.

클라이언트가 손상된 경우 해당 키 (및 해당 키만)를 서버에서 제거해야합니다.
모든 클라이언트의 모든 서버에 대한 담요 액세스 권한을 부여하지 않고 어디서 어디서 액세스 할 수 있는지 결정할 수있을만큼 유연합니다.
매우 편리합니다. ssh-add에는 하나의 키만 있으며 혼란은 없습니다.
옵션 4를 통해 쉽게 설정 및 관리

옵션 4 는 훌륭하지만 너무 많은 작업입니다. 옵션 3 은 훨씬 적은 번거 로움없이 98 %를 제공합니다.

— dwc
소스

4

옵션 4의 요점을 보지 못했습니다. 그것은 목적이 아닙니다.

— niXar 2016 년

26

홈 네트워크 서버, 사무실 서버, 컨설팅 클라이언트 네트워크 서버 및 기타 계정이있는 기타 시스템에 사용되는 SSH ID 키를 분리하여 유지하려는 경우 좀 더 복잡하지만 매우 다양한 솔루션을 사용합니다.

이제는 거의 독점적으로 Linux 워크 스테이션에서 작업하므로 LUKS 암호화를 사용하여 설정 된 USB 키가 있으며 HAL 데몬과 함께 X11 창 관리자가 LUKS 암호화 드라이브를 감지하고 암호 해독 암호를 삽입하고 시도 할 때 프롬프트를 표시합니다 장착하십시오. 암호화 된 드라이브에 이것을 저장하면 SSH 키를 어떤 워크 스테이션에도 저장하지 않습니다.

그런 다음 ~/.ssh/config파일에 다음 구성이 있습니다.

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

% d를 OpenSSH를하여 사용자의 홈 디렉토리로 번역하고,에 ~ / 스푸핑 디렉토리 내가 만든 keys.d를 제대로 장착 될 때 암호화 된 USB 드라이브의 디렉토리 경로에 대한 심볼릭 링크로.

%의 L의 발현은 로컬 클라이언트 컴퓨터의 호스트 이름과로 번역 유 % 로컬 클라이언트의 사용자 이름으로 변환됩니다.

이 구성은 SSH가 3 가지 다른 표현식을 사용하여 키를 찾을 수 있도록합니다. 예를 들어, 내 로컬 클라이언트의 사용자 이름이 jdoe내 로컬 클라이언트 컴퓨터 이름 인 examplehost경우 원격 서버에서 존재하고 수락 한 키를 찾을 때까지 다음 순서로 표시됩니다.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

% r 식을 사용하여 % u 및 % l 이 사용 된 것처럼 원격 서버 사용자 이름에 대한 키 또는 원격 서버 호스트 이름에 대한 % h 를 찾을 수도 있습니다.

업데이트 : 이제 실제로 ssh-agent와 호환되는 GnuPG gpg-agent를 사용하여 OpenPGP v2 스마트 카드에서 인증 키를 읽고 사용합니다.

— 제레미 부스
소스

와우, 훌륭한 솔루션, 감사합니다! ~ / .ssh / config의 범용 구성을 좋아합니다.

— 슬랙

업무, 개인 및 컨설팅 클라이언트 네트워크 서버를 위해 별도의 작업을 수행하는 것이 매우 편리하다는 것이 입증되었습니다. 나는 서버간에 인증을 혼합하고 싶지 않지만 쉽게 사용할 수 있기를 원합니다.

— Jeremy Bouse

놀랄 만한! 나는 이것을 정말로 좋아합니다.

— balu

클라이언트 컴퓨터마다 다른 USB 키를 사용한다고 가정합니다. 그렇지 않으면 모든 키가 동일한 장소에 저장된 경우 별도의 키의 요점은 무엇입니까? 위반이 발생하면 모두 철회해야합니다. (아마도) 뭔가 빠진 경우가 아니라면 문제가 복잡해 보입니다.

— Halil Özgür

@ HalilÖzgür, 예 상담하고 항상 같은 키를 사용하고 싶지는 않습니다. USB 키는 암호화되어 있고 연결이 필요하지 않은 한 컴퓨터에 연결되어 있지 않기 때문에 서버가 손상 될 염려가 없으며 드라이브 파일 시스템의 암호를 해독하는 암호는 키를 간단하게 취소하기에 충분히 길다.

— Jeremy Bouse 2016 년

6

개인 키는 민감한 데이터이기 때문에 옵션 1 (옵션 2;-것으로 생각되는 것으로 생각되는 옵션 1)을 모두 제거하고 가능한 한 적은 장소에 보관하는 것이 좋습니다. 나는 개인적으로 백업을하는 것을 제외하고는 한 컴퓨터에서 다른 컴퓨터로 (또는 같은 컴퓨터에서 다른 파일로 또는 다른 컴퓨터로) 개인 키를 절대로 복사하지 않을 것입니다. 대부분의 암호화 키와는 달리 SSH 키를 잃어버린 경우 세계의 끝이 아닙니다 (새 키를 만들면 데이터가 손실되지 않습니다).

— 데이비드 Z
소스

예, 올바른 "옵션 2"로 이름이 바뀌 었습니다. "개인 키를 절대로 복사하지 마십시오"라는 규칙이 마음에 듭니다. 좋은 규칙입니다.

— slacy

1

옵션 3 및 Puppet과 같은 것을 사용하여 키 관리를 처리하십시오.

— diq
소스

이 reductivelabs.com/trac/puppet/wiki/PuppetIntroduction 이 Puppet에 대한 링크입니까?

— Andy

그래 그거야. 사이트의 일부 예를 확인하십시오. 바퀴를 재발 명할 필요없이 다른 사람들이 이미 한 일을 확인할 수 있습니다.

— diq

1

옵션 3.

또한 클라이언트가 액세스 할 수있는 서버를 제어 할 수 있습니다. 예를 들어, 클라이언트 X가 서버 A와 B에 액세스해야하지만 C 또는 D에 액세스해야하는 경우 해당 호스트에만 공개 키를 복사합니다.

— pgs
소스