SSH에 공개 키 인증을 사용해야하는 이유는 무엇입니까?

SSH 서버를 실행 중이며 여전히 간단한 비밀번호 인증을 사용하고 있습니다. 보안에 관한 모든 곳에서 공개 키 인증을 사용하는 것이 좋습니다. 그러나 나는 이점을 얻지 못한다. 그것들을 사용하는 것은 내 눈에 안전하지 않거나 많은 편리한 작업입니다.

물론 누군가 누군가 내 SSH 서버에 로그인하는 것을 강제로 시도하면 공개 키는 암호보다 훨씬 강력합니다. 그러나 그 점을 제외하면 완전히 안전하지 않습니다.

조언자들은 대부분 비밀번호를 기억할 필요가 없다고 주장합니다. 얼마나 안전하지 않습니까? 누군가 누군가 내 컴퓨터를 해킹하면 내 컴퓨터뿐만 아니라 서버도 가져옵니다. 다양한 클라이언트에서 SSH를 사용하는 경우 공개 키를 하나씩 저장해야하므로 허위로 넘어 질 가능성이 배가됩니다. 나는 가지고 다니는 USB 스틱에 저장할 수는 있지만 잃어 버릴 수 있으며 파인더는 내 서버에 액세스 할 수 있습니다.

아마도 2 단계 인증을받는 것이 더 좋습니다.

내가 놓친 주장이 있습니까? 나에게 가장 좋은 방법은 무엇입니까?

누군가 내 컴퓨터를 해킹하면 내 컴퓨터뿐만 아니라 서버도 가져 옵니까?

어쨌든 키로거의 경우에도 마찬가지입니다. 손상된 시스템에서 서버에 로그인하자마자 암호를 얻습니다.

그러나 키에는 3 가지 장점이 있습니다.

1) 캐시 가능한 인증. 암호를 한 번 입력하고 여러 ssh 명령을 수행하십시오. 이것은 scp, rsync 또는 git와 같은 전송으로 ssh를 사용하는 것을 사용하는 경우 매우 유용합니다.

2) 확장 가능한 인증. 암호를 한 번 입력 하고 여러 컴퓨터에 로그인 하십시오 . 기계가 많을수록 더 유용합니다. 100 대의 기계가 있다면 어떻게해야합니까? 동일한 암호를 사용할 수 없으며 (복제 팜이 아닌 경우), 많은 암호를 기억할 수 없습니다. 따라서 암호 관리자를 사용해야하며 단일 절충 지점으로 돌아갑니다. 사실상 암호 는 암호 관리자입니다.

2b) 동일한 시스템을 사용하는 여러 관리자가있는 경우 다른 방식으로 확장됩니다. 비밀번호가 변경되었음을 B, C, D, E, F ...에게 알리지 않고 사용자 A의 키를 취소 할 수 있기 때문입니다.

(이것은 개별 계정과 sudo로도 수행 할 수 있지만 어떻게 든 해당 계정을 프로비저닝해야합니다)

3) 자동화 및 부분 위임. 키가 연결될 때 특정 명령 을 실행하도록 SSH를 설정할 수 있습니다 . 이를 통해 시스템 A의 자동화 된 프로세스는 두 시스템간에 암호없이 완전히 신뢰하지 않고도 시스템 B에서 무언가를 수행 할 수 있습니다.

(이것은 유감스럽게도 안전하지 않은 rlogin / rsh를 대체합니다)

편집 : 암호가 아닌 공개 키의 또 다른 이점은 서버가 취약점으로 인해 손상되는 일반적인 시나리오입니다. 이 경우 비밀번호로 로그인하면 비밀번호가 즉시 손상됩니다. 키로 로그인하지 않습니다! 관리자의 원래 데스크톱이 손상되는 것보다 더 일반적이라고 말할 수 있습니다.

좋은 암호를 사용하면 충분히 안전 할 수 있습니다. 나는 일반적으로 공개적으로 액세스 가능한 서버의 수를 최소로 제한하고 가능할 때마다 특정 IP의 SSH를 허용합니다.

또한 암호 (암호)로 키를 보호 할 수 있습니다. 따라서이 비밀번호 문구는 서버에 로그인해야 할 때마다 입력해야합니다. 올바른 암호가 제공되지 않으면 아무도 키를 사용할 수 없습니다.

비슷한 게시물이 있습니다 :

1. serverfault 에서 게시합니다 .
2. 에서 게시 보안 stackexchange .
3. 에서 게시 수퍼 유저 .

공개 키 인증이보다 안전한 방법 중 하나는 공격자가 클라이언트 컴퓨터와 서버 사이에서 MITM (Man-in-the-Middle) 상태를 유지하고 호스트 키가 변경되지 않는 경우입니다. 예를 들어이 특정 클라이언트 컴퓨터를 처음 사용하기 때문에 이전 키가 없습니다.

(공격자가 서버를 제어 할 수 있고 동일한 자격 증명이 작동하는 다른 서버가있는 경우에도 마찬가지입니다.)

표준 비밀번호 기반 인증을 사용하면 비밀번호 (암호화 된 연결 내)를 일반 텍스트로 제출하면, 정품 서버는 일반적으로 비밀번호를 해시하고 결과를 비밀번호 데이터베이스에 저장된 해시와 비교합니다. MitM 공격자는 대신이 암호를 가져 와서 실제 서버에 대한 연결을 열고 거기에 로그인하여 ... 내용을 사용자에게 전달하거나 (아무 눈치 채지 못함) 서버에서 자체 악의적 인 일을 할 수 있습니다 .

공개 키 인증을 사용하면 클라이언트는 기본적으로 개인 키를 소유하고 있음을 증명하기 위해 서버와 클라이언트 모두에게 알려진 일부 데이터에 서명하고 서명을 서버에 보냅니다. 이 서명 된 데이터에는 세션 식별자가 포함되는데, 세션 식별자는 클라이언트와 서버 모두에서 선택한 난수에 따라 달라 지므로 각 세션마다 다릅니다. MitM이 실제 서버에 대한 자체 SSH 연결을 여는 경우 해당 세션은 다른 세션 ID를 가지므로 클라이언트가 제공 한 서명이 작동하지 않습니다.

물론 다른 답변에서 이미 말했듯이 암호를 사용하여 암호화하거나 PIN을 입력 한 후에 만 ​​서명을 만드는 별도의 장치에서 개인 키를 안전하게 유지해야합니다.

OpenSSH는 자체 CA를 유지하여 SSH 호스트 및 클라이언트 키를 관리하고 해지 목록을 사용할 수 있습니다. 이것은 키 기반 인증에 의해 제공되는 보안에 추가 될 수 있습니다.

"비밀번호가 필요하지 않습니다"라는 주장에 대한 권리가 있습니다. 그것은 클라이언트 측에서는 실제로 안전하지 않습니다.

무엇 수 있습니다 만 훨씬 더 보안에 로깅을위한 공개 키 것은 서버에 대한 무력 액세스 할 수있는 방법이 없다는 사실이다. 공격자가 달성 할 수있는 모든 것은 서버에 약간의 부하를 가하는 것입니다. fail2ban 을 사용 하여이를 점검 할 수 있습니다 .

클라이언트 측의 보안을 위해서는 적절한 암호 문구로 개인 키를 보호해야합니다. 물론 지금은 서버에 연결하는 것이 암호보다 더 번거 롭습니다. 이를 극복하기 위해 ssh 에이전트 를 사용 하여 서버에 여러 번 연속으로 연결하려는 경우 개인 키를 메모리에 저장할 수 있습니다. 키를 메모리에 보관하는 시간을 제한하는 것이 좋습니다.

아마도 2 단계 인증을받는 것이 더 좋습니다.

SSH를위한 2FA의 가능성 (그리고 비교적 적은 설정 / 복잡성이 요구되는 것)은 실제로 공개 키와 암호를 사용하는 것입니다.

나는 그 선을 따라 무언가를 AuthenticationMethods publickey,keyboard-interactive추가하여 /etc/ssh/sshd_config그 일 을 할 수 있다고 생각합니다.

더 일반적으로, 문제는 암호 (독립)가 종종 모호한 품질이기 때문에 인증을위한 훌륭한 방법이 아니라는 것입니다. 키와 암호에 대한 매우 간단한 '인수'는 일반적으로 키가 적어도 2048 비트이며, 더 많은 경우가 있습니다 (EC 키의 경우 실제 크기가 아닌 효과적인 강도가 됨). 이러한 비트는 암호 적으로 안전한 (또는 적절한) 메커니즘에 의해 생성됩니다.

암호는 대개 2048 비트보다 작으며 종종 암호로 안전한 소스에서 파생되지 않습니다.

또한 암호를 사용하여 키를 보호하여 암호를 잃어 버리는 것과 관련된 문제를 방지 할 수 있습니다 (누군가 해당 암호를 시도하고 무력화 할 수는 있음).

따라서 기본적으로 키와 암호의 차이를 상당히 투명하게 만들 수 있으며 키를 사용하면 사람이 다룰 수있는 것보다 더 나은 암호를 사게됩니다. 이것은 만병 통치약이라고 말하지는 않지만 평균적으로 암호보다 더 많은 보안을 제공합니다.