SSH 키를 저장하는 방법?

56

저는 최근에 암호 대신 SSH 키를 사용하기 시작했습니다. (물론 GitHub 덕택입니다.) 그래서 나는이 개념 전체에서 아주 새롭다는 것을 명심하십시오. 현재 내 키는 단순히 ~ / .ssh 아래에 있지만, 이것이 좋은 연습인지 확실하지 않습니다. 예 : 여러 컴퓨터가있는 경우 개인 키를 복제해야하는데 이는 바람직하지 않다고 생각합니다. 또는 내 하드 디스크가 kaput이된다면, 그 키를 잃어 버릴 것입니다.이 키는 바람직하지 않습니다.

그렇다면 SSH 키를 안전하고 편리하며 안정적으로 저장하는 모범 사례는 무엇입니까?

스마트 카드를 사용하는 것 같은 옵션이 있습니다 ( gpg / ssh 키 저장 용 스마트 카드 (Linux) - 무엇이 필요합니까? ), 이것이 최고의 것입니까?

업데이트 : 질문의 이유는 GitHub, AWS EC2와 같은 많은 서비스가 서비스 사용을위한 SSH 키를 설정하는 방법에 대한 지침을 제공하지만 배경이 거의 없거나 거의 없습니다 (이미 키가 생성 된 경우 수행 할 작업 으로 ssh-keygen [1], 보안 조치 권장). 정보가 사실 중요하지 않거나 '기본적으로'정보를 알고 있을지 여부는 분명하지 않습니다.

이 시점까지 답변을 요약하면 다음과 같습니다. (그러나 그것들을 읽으십시오. 그리고 추가 할 것이 있다면 - 제발하십시오) :이 경우에는 ~ / .ssh에 개인 키를 남겨두면 다른 사람들로부터 그들을 지키는 것이 좋습니다. 그러나 일반적으로 새로운 키를 잃어 버리거나 업로드하는 경우에는 서비스에 액세스하여 새 키를 업로드하거나 생성하는 다른 방법이 있는지 확인하십시오.

[1] 제공하는 GitHub 여러 개의 키를 관리하는 방법에 대한 도움말 .

security  ssh-keys 
— Tony
소스
링크가 깨진 것 같습니다. help.github.com/multiple-ssh-keys
— KJ Price
@ KJ 가격, 인터넷 아카이브 덕분에 웨이 백 기계 , 페이지는 원래 링크가 아닌 온라인에서도 계속 사용할 수 있습니다. 2011 년 9 월 2 일에 보관 된 페이지의 사본은에서 찾을 수 있습니다. 여러 개의 SSH 키 .
— moonpoint

답변:

38

예 : 여러 컴퓨터가있는 경우 개인 키를 복제해야하는데 이는 바람직하지 않다고 생각합니다.

아니, 사실 당신은하지 않습니다. 여러 컴퓨터가있는 경우 각각의 컴퓨터에 별도의 개인 키를 만듭니다. 각각의 비공개 키에 대해서, 동일한 프로세스를 사용하여 GitHub에 상응하는 공개 키를 업로드하면됩니다.

또한, 내 HDD가 kaput되면, 나는 (내 생각 엔) 바람직하지 않은 개인 키를 잃어 버릴 것이다.

정말로. 비공개 키를 잃어 버리면 새로운 키를 생성하고 해당 공개 키를 업로드하면됩니다.

그것이 가치있는 일이라면 개인 키를 복제하는 것이 매우 바람직하지 않다는 것입니다. 이상적으로, 개인 키는 하나의 파일에서 생성되어야합니다 ( ~/.ssh/id_rsa 예를 들어) 못 그 파일을 남겨 두십시오. 즉, 복사, 이동 및 네트워크를 통해 전송되지 않아야합니다. (예 : 백업에서 제외합니다.) 비대칭 인증 프로토콜의 특성 때문에 개인 키를 다른 사람의 손에서 떼어 놓는 것에 대해 걱정할 필요가 있습니다. 너가 조금 배 밖으로 가고 너가 너 자신 그것을 추적하지 않으면, 일반적으로 큰 문제가 아니다. (이것은 비대칭과 혼동되어서는 안된다. 암호화 개인 키, 예 : GPG 키를 누르십시오.

— David Z
소스
11
이것은 개인 키가 액세스 권한을 제공하는 서버에 액세스하는 다른 방법이있는 경우에만 작동합니다. 백업 액세스 권한이있는 경우에만 새 공개 키를 업로드 할 수 있습니다.
— TREE
2
@ 트리 : 그렇습니다.하지만 제 경험상 SSH를 거치지 않고 다른 공개 키를 추가하는 서버를 찾는 것은 매우 드뭅니다.
— David Z
2
고마워요, 그것은 많은 것을 정리합니다. 실제로, 개인 SSH 키를 잃어 버리는 것은 문제가되지 않습니다. 왜냐하면 내가 사용하고있는 모든 서비스가 새로운 서비스를 업로드하기 위해 서비스에 액세스하는 또 다른 방법 인 것처럼 보이기 때문입니다.
— Tony
2
AWS는 개인 키 이외에 다른 액세스 방법을 제공하지 않습니다. 드라이브를 분리하고 비밀 키를 잃어 버렸을 때 액세스 권한을 얻으려면 드라이브를 어루 만져야합니다.
— Asad Saeeduddin
다른 보안 계층을 원한다면 개인 키에 암호를 입력 할 수 있습니다.
— sudo
8

동일한 사용자 계정을 사용하여 둘 다 실행하는 경우 ~ / .ssh /를 브라우저에서 읽을 수 있습니다.

시도 해봐! 브라우저에서 은밀한 홈 디렉토리의 키. 재미 있습니다.

따라서 다른 사용자 계정의 홈 디렉토리에 ssh-keys를 저장하는 것이 좋습니다.

암호 보호 암호에 대한 단어

  • 요즘은 무작위로 암호를 해독하는 것이 매우 빠릅니다. 체크 아웃 해시 캣
    • (무작위와 긴 12+ char 암호가 아직도 무차별 한 힘에 합리적으로 길지 만)
    • 따라서 AES 암호화 된 ssh 키는 좋은 긴 암호를 사용하는 한 가까운 미래에 uncrackable입니다. 만나다 github 추천
  • 따라서 일부 웹 사이트에서는 자바 스크립트를 사용하지 않고 키를 가져올 수 있습니다. 그런 다음 키를 오프라인으로 무차별 적으로 실행합니다.
  • 그리고 브라우저는 JS를 사용하여 클립 보드를 볼 수도 있습니다. 매우 긴 암호를 복사하여 붙이면 더 정교한 자바 스크립트 공격으로부터 위험에 처하게됩니다.

look_at_keys.html 

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>
— HeyWatchThis
소스
16
브라우저가 브라우저에서 실행중인 웹 사이트를 의미하는 것은 아니지만 개인 키를 읽을 수 있기 때문에 명확해야합니다.
— Ajedi32
5
그러나 브라우저 프로세스에서 프로세스를 삽입하는 경우. 그런 다음 브라우저를 제어 할 수도 있습니다. 그래서이 논증은 완벽하게 유효합니다.
— BigSack
그러나 그런 다음 브라우저의 처리 장치 프로세스 레지스터에 프로세스를 삽입하는 프로세스를 해킹해야합니다.
— Smalbil
7

KeePass2라는 매우 멋진 도구가 있습니다 ( http://keepass.info/ )와 확장자 ( http://lechnology.com/software/keeagent/ )

거기에 암호, SSH 키 등을 저장할 수 있습니다 (공식 KeePass 페이지에는 더 많은 유용한 확장이 있습니다)
SSH 키를 사용하여 자동 로그인을 원하면 PuTTY, Pageant 및 KeePass를 KeeAgent와 함께 설치하기 만하면됩니다. 제대로 구성하는 경우 PuTTY, Pageant 또는 FileZilla에서 키를 설정하지 않아도됩니다.

나는 그것을 직접 사용하고 그것에 대해 꽤 행복하다. 나는 30 개 이상의 VPS와 Root Server를 가지고 있고 다른 SSH 키들과 일정량의 키스 패스를 가지고있다. 그런 다음 콘솔에 암호를 입력하기 만하면된다.

— CentrixDE
소스
3

개인 키를 저장하는 것이 좋습니다.

  • 오프라인 (클라우드 안함)
  • 둘 이상의 장소에서
  • 관련이있는 것 외에는 (예 : 암호화 된 데이터의 키, 데이터와 별도의 위치에 저장

나는 최고의 장소가 될 것이라고 말하고 싶다.

  • 외장형 하드 드라이브
  • 플래시 키
  • 인터넷에 연결되지 않은 컴퓨터

더 좋은 점은 그냥 인쇄해서 내화 금고에 보관하십시오.

— blah
소스
3
보안 / 모범 사례는 실용성과 함께 작동합니다. 보안 전략이 시스템 사용 능력을 허물게 만들면 공격자가 아닌 사용자가 우회하게됩니다.
— zaTricky
1

나는 안전한 장소에 보관할 내 사용자 디렉토리 설정 (.bashrc, .ssh / 및 기타 설정 파일)이있는 tar 파일이 있습니다. 어디에서나 새 쉘 계정을 얻으면 tar 파일의 압축을 풉니 다.

신뢰할 수있는 서버에만 개인 키를 넣어야합니다. 그렇지 않으면 해당 서버에 대해 서버에 새 개인 키를 만들어 액세스 권한을 부여해야합니다.

개인적으로는 .ssh / stuff를 어디서나 복사하는 것이 편리합니다. (보통 ssh 키는 이미 authorized_keys 파일에 있기 때문에 즉시 ssh 액세스를 얻습니다.)

— EightBitTony
소스
암호화 된 ~ / .ssh를 USB 스틱에 매달아두면 하드웨어 오류 발생시 새 키를 생성하고 업로드해야 할 필요가 없어집니다. 그러나 SSH 키를 사용하여 액세스하는 서버가 거의 없기 때문에 새로운 키를 생성해도 많은 오버 헤드가 발생하지는 않습니다.
— Tony
2
그것은 코스의 말이며 왜 키를 사용 하느냐에 달려 있습니다. 이미 암호화 된 SSH 링크를 통해 ssh 개인 키를 복사하는 데 문제가 발생하지 않습니다. 그러나 대상 시스템을 신뢰하지 않고 루트 액세스 권한이있는 사용자를 모르는 경우 서버에 놓을 수없는 것을 넣지 마십시오.
— EightBitTony
개인 키를 다른 사람의 서버에 넣고 싶지는 않습니다. 해당 서버에서 루트 액세스 권한을 가진 사용자는 개인 키를 읽을 수 있으며 해당 개인 키를 사용하여 액세스하는 시스템에서 사용자를 가장 할 수 있습니다. 서버에 액세스하기 위해서는 공개 키만 넣어야합니다. 비밀 키를 해독하기 위해 원격 시스템에서 암호 구문을 사용하면 암호 구문이 그다지 도움이된다고 생각하지 마십시오.
— Codeguy007
ssh를 통해 ssh-agent를 전달할 수 있습니다. 그렇게하면 개인 키를 서버에 저장하거나 암호문을 그물을 통해 보낼 필요가 없습니다. stackoverflow.com/questions/12257968/...
— Codeguy007
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.