빈 암호로 SSH 키를 사용해도 되나요?


34

ssh 키를 만드는 방법을 처음 배웠을 때 읽은 자습서는 모두 좋은 암호를 선택해야한다고 언급했습니다. 그러나 최근에 다른 컴퓨터에 ssh 해야하는 데몬 프로세스를 설정할 때 매번 부팅 할 때마다 인증 할 필요가없는 키를 갖는 유일한 방법은 비어있는 키를 만드는 것입니다. 암호. 그래서 내 질문은 암호가없는 키를 사용하는 것에 대한 우려는 무엇입니까?

답변:


38

암호가없는 키는 다른 사람이 해당 키에 액세스 할 수없는 사람 (어쨌든 액세스 할 수있는 리소스를 얻을 수없는 사람)에 의존합니다. 따라서 키가 옆에있는 머신에 대한 액세스 권한을 부여하고 두 머신 모두 동일한 수준의 전자 보안과 물리적 보안을 갖는 경우 실제로 큰 문제는 아닙니다.

반면에, 키가 보안이 취약한 컴퓨터에있는 경우 (신뢰할 수없는 사용자가 많거나 물리적으로 쉽게 액세스 할 수 있거나 패치 적용 체제를 최신 상태로 유지하지 못하는 경우) 암호문이없는 키를 유지하고 싶습니다.

궁극적으로, 설정에 대한 신뢰와 설정의 위험 / 비용을 측정해야합니다. 공격자가 키에 액세스 할 수있는 리소스보다 키에 액세스하는 것이 현실적으로 쉽지 않다는 확신이들 경우 그러면 괜찮습니다. 자신감이 없다면 아마도 이유를 수정해야합니다 :)


신뢰할 수있는 사람들 만 키를 사용하여 컴퓨터에 액세스 할 수 있으므로 내 질문에 대한 답이 될 것 같습니다. 감사.
mozillalives

11

다른 솔루션으로 보안을 강화하면서 쉽게 사용할 수 있으므로 항상 암호를 입력 할 필요가 없습니다.

개인 키를 암호화하려는 경우 ssh-agent워크 스테이션에서 암호화되지 않은 키를 '캐시' 할 수 있습니다 . 해독 된 키를 저장하려면 ssh-add ~/.ssh/id_rsa개인 키의 이름을 지정하십시오. 암호를 입력하라는 메시지가 표시되고 로그 아웃, ssh-agent종료 또는 종료 할 때까지 ssh 연결에 암호 해독 된 키를 사용할 수 있습니다 .

예를 kill들어 저장된 키 ssh-agent -k를 사용하여 키를 메모리에 저장할 수있는 수명을 지정할 수 있습니다 ssh-agent -t [seconds]. 키를 영구적으로 해독하지 않고 호스트 주변에서 많은 ssh-ing을 수행하려면 시간 제한을 5-10 분으로 설정할 수 있습니다. 따라서 키 암호를 계속 입력 할 필요가 없습니다.

다시 말하지만,이 모든 것은 당신이 / workstation /의 보안에 얼마나 자신감이 있는지와 관련이 있습니다. 암호문이없는 개인 키는 합리적으로 안전합니다.

당신이 나와 같고 개인 키를 썸 드라이브에 보관하면 개인 키 (워크 스테이션에서 사용하는 별도의 키) 일지라도 확실하게 암호화하려고합니다. 내 키를 잃어 버렸습니다. 내 서버 ~/.ssh/authorized_keys목록 에서 엄지 드라이브의 공개 키를 쉽게 제거 할 수 있습니다. 공개 키 에 유용한 주석을 추가하는 / excellent / 이유가 나타납니다)

이전 답변에 대한 귀하의 응답에서, 귀하는 신뢰하는 사람들 만이 키를 사용하여 시스템에 액세스 할 수 있다고 말했습니다. 나는 당신이하고있는 일이라면 개인 키가 연결중인 서버에있을 필요가 없다는 것을 분명히하고 싶습니다. 공개 키만 서버에 있어야하며 이는 문제가 아니기 때문에 '공개'키입니다.

아, 나는 언급하는 것을 잊었다. 내가 시작 ssh-agent내가, 내가 함께 저장 그렇지 않으면 드 암호화 되 키 X를 시작할 때 ssh-add다른 통해 유지되지 않습니다 xterm세션을, 그리고 난에이 패스워드 재 입력 때마다 내가 닫기 xterm전 출시 ssh-add내에서. ~/.xinitrc파일, 내가 가진 :

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)
fi

ssh-agent가 실행될 때 설정해야 하고 환경 변수가 X 세션 전체에서 일정 할 때 설정 해야하는 일부 환경 변수를 반환하기 때문에 ssh-agent래핑 된 호출이 eval있습니다 ~/.xinitrc.


예-공개 키만 업로드하면됩니다. 하나의 서버를 다른 서버에 연결하는 것입니다. 그러나이 명확하고 신중한 답변을 작성해 주셔서 감사합니다.
mozillalives

글쎄, 당신이 그것을 사용 ssh-agent하고 사용 ssh -A -i privkey user@host한다면 ssh 에이전트 전달을 허용 할 것이고, 이것은 당신이 첫 번째 서버에 개인 키를 두지 않고도 초기 서버에서 서버에 액세스 할 수있게합니다. ssh 키 전달을 사용하지 않는 경우에도 ssh 체인은 권장되지 않으며 ssh -A자체 보안 문제가 있습니다. 서버의 키를 암호화 할 수없는 이유는 없지만 워크 스테이션의 키는 암호가 필요 없습니다.
cpbills

3

웹 서버의 SSL 개인 키에 대해 비슷한 질문을 살펴볼 수 있습니다 . 기본적으로 세 가지 옵션이 있습니다.

  1. 파일 시스템 권한으로 키를 보호하십시오.
  2. 암호로 보호 된 키를 사용하고 다시 시작할 때마다 키를 수동으로 입력하십시오.
  3. 비밀번호로 보호 된 키를 사용하고 파일 시스템에 키를 저장하여 재시작을 자동화하십시오.

그들 각각은 결함이 있으므로, 당신이 가장 두려워하는 것에 달려 있습니다.


1

암호가없는 키가 필요한 자동 액세스의 경우 항상 authorized_keys의 추가 옵션 (sshd (8) 참조)을 사용하여 실행할 수있는 명령을 제한합니다.

일반적으로 원격 끝에서 신중하게 작성된 스크립트를 제공합니다.이 스크립트는 허용하려는 작업 (또는 작업-매개 변수를 볼 수 있음)을 정확하게 수행합니다.

그런 다음 해당 키로 연결할 수있는 IP 주소에 고정합니다 (100 % 완전하지는 않지만 명령 제한으로도 양호).


탁월한 점-보호되지 않은 키를 사용해야하는 경우 잠금 해제하는 것이 가장 좋습니다!
MikeyB

1

키 외에 다른 사람이 키에 액세스 할 수 없으면 암호가 필요하지 않습니다. 실제로 자동화 된 소프트웨어가 사용하는 키에는 암호를 사용할 수 없습니다.


0

ssh를 사용하여 모든 종류의 자동 절차를 수행하려는 경우-특히 Nagios 검사를 생각하고 있습니다. 암호를 사용하고 싶지 않을 것입니다.

이 상황에서는 아마도 LAN 외부에서 이것을 사용하지 않을 것이므로 절차를 수행하는 서버에 키가 안전하게 저장되어있을 것입니다.

SSH에 관한 대부분의 자습서는 외부 네트워크, 아마도 안전하지 않은 컴퓨터에서 로그인하는 사람을 예상 할 것입니다.

기본적으로 정당하지 않은 이유가 없으면 암호를 만드십시오. 매번 암호를 입력하기에 너무 게으 르면 충분한 이유가 있습니다 :-)


외부 네트워크에서 로그인하더라도 어떻게 다른 점이 있습니까? 클라이언트 컴퓨터의 보안 만 중요합니다. 암호문은 클라이언트 쪽에서 처리됩니다.
njsg 2016 년

누군가가 SSH 키를 취소 할 기회를 갖기 전에 클라이언트 랩톱을 도난 당하여 경계를 위반할 때까지. 키의 암호는 키를 취소하는 데 더 많은 시간을 제공합니다.
dunxd 2016 년

제가 말했듯이 "클라이언트 컴퓨터의 보안 만 중요합니다".
njsg 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.