동일한 SSH 서버 키를 가진 여러 장치를 갖는 것이 얼마나 나쁜가?

FreeBSD와 SSH를 실행하는 임베디드 장치에서 작업하고 있습니다.

아시다시피, sshd는 처음 부팅 할 때 서버 키 세트를 임의로 생성하는 것을 좋아합니다. 문제는 읽기 전용 sd-card 파일 시스템 (협상 불가능)으로 제품을 배송한다는 것입니다.

내가 보는 두 가지 옵션은 다음과 같습니다.

• 모든 장치에 동일한 sshd 서버 키를 제공하십시오
• 메모리 파일 시스템을 마운트하고 매번 부팅 할 때마다 서버 키를 생성하십시오 (느리게 ...).

모든 장치에 동일한 서버 키를 제공하는 것이 주요 보안 문제입니까? 이러한 항목은 인터넷에 직접 있지 않습니다. 같은 사람과 같은 네트워크에서 여러 장치를 소유하는 경우가 있습니다.

대부분의 경우 장치가 인터넷에 연결되지 않습니다.

SSH로 로그인하는 것은 정상적인 작동의 일부가 아닙니다. 주로 프로그래머와 기술자의 편의를위한 것입니다. 고객은 SSH를 사용하여 장치에 로그인하지 않습니다.

여러 하드웨어 장치에서 동일한 서버 키를 사용하면 어떤 결과가 있습니까?

추신 : 누군가가 사물 인터넷 태그를 만들 수 있습니까?

편집 : 나는 모든 서버 (장치)에 동일한 호스트 개인 키를 설치하는 것에 대해 이야기하고 있습니다. 사용자 공개 / 개인 키의 경우 현재 키 기반 로그인을 사용할 계획이 없습니다. 비밀번호 로그인입니다. 모든 서버 (장치)에서 동일한 암호를 다시 사용하십시오.

나는 이것이 아마도 나쁜 생각이라는 것을 안다. 나는 왜 그것이 왜 나쁜 생각인지 정확하게 알고 싶습니다. 그래서 나는 장단점을 이해할 수 있습니다.

SD 카드 또는 기타 읽기 전용 미디어에 ssh 호스트 키와 같은 호스트 별 데이터를 저장하는 대신 내장 시스템의 NVRAM에 저장할 수 있습니다. 부팅시 키를 저장하고 검색하려면 일부 사용자 지정 스크립팅을 수행해야하지만 스크립트는 모든 장치에서 정확히 동일합니다.

동일한 키 페어를 모든 장치와 함께 배송하면 그에 연결된 클라이언트의 보안과 직접 ​​관련이 있습니다. 이는 SSH 클라이언트에서 연결중인 장치를 고유하게 식별 할 수있는 방법이 없기 때문입니다. 키 페어가 유출되면 MITM 공격에 사용될 수 있습니다.

반면에, 부팅 할 때마다 키를 다시 생성하면 클라이언트에서 경고가 트리거됩니다.

참고로 man ssh(1):

ssh사용 된 모든 호스트에 대한 식별 정보가 포함 된 데이터베이스를 자동으로 유지 관리하고 검사합니다. 호스트 키는 ~/.ssh/known_hosts사용자의 홈 디렉토리에 저장됩니다 . 또한 파일 /etc/ssh/ssh_known_hosts은 알려진 호스트를 자동으로 확인합니다. 모든 새 호스트가 자동으로 사용자 파일에 추가됩니다. 호스트 식별이 변경되면 이에 ssh대해 경고하고 암호 인증을 비활성화하여 서버 스푸핑 또는 MITM (Man-in-the-Middle) 공격을 방지합니다. 그렇지 않으면 암호화를 우회하는 데 사용될 수 있습니다. 이 StrictHostKeyChecking옵션을 사용하여 호스트 키를 알 수 없거나 변경된 시스템에 대한 로그인을 제어 할 수 있습니다.

첫 번째 옵션에서 들리는 것처럼 SSH 키는 SD 카드에서 사용할 수 있습니다. 따라서 모든 사용자가 카드를 꺼내서 읽을 수 있습니다. 따라서 기본적으로 개인 키는 (대부분) 공개되었습니다.

이를 통해 다음과 같은 중간자 공격이 가능합니다.

1. 사용자는 장치에서 얻은 개인 키를 사용하여 SSH 서버를 설정하고 해당 IP 주소를 기술자에게 제공합니다.
2. 기술자는 SSH 연결을 통해 루트 비밀번호를 입력합니다.
3. 이제 사용자는 모든 장치에 유효한 루트 암호를 알고 있습니다.

그러나 먼저 루트 암호를 사용해서는 안됩니다. 대신 ssh 키를 사용하여 인증하십시오. LAN으로 만 로그온 하면 공유 서버 키의 영향이 매우 작습니다 .

SSH는 또한 전 방향 보안을 제공하므로 공격자는 키를 활용하기 위해 잘못된 서버를 설정할 수 있어야합니다. 수동으로 트래픽을 스니핑하면 트래픽을 해독 할 수 없습니다.

나는 이것을 공포로 읽었다! 동일한 ssh 호스트 키를 사용하여 동일한 클러스터에서 여러 시스템을 수행 한 사람은이 작업을 감히 수행하지 않습니다. 어떤 상황에서도 다른 관리자 세트를 가진 머신이 ssh 호스트 키를 공유하도록 허용하지 마십시오. 당신이 당신의 보안 부족으로 게시 될 때 그 방법은 광기와 비명 공포에 놓여 있습니다.

하나의 장치를 손상시키는 사람은 모든 장치를 손상시키는 진실을 말하겠습니다. 일단 획득하면, 나쁜 사람들이 원하는대로 서로 이동하고 보안은 얇은 종이처럼 롤백됩니다.

최종 사용자 / 고객이 SSH 액세스를 사용하지 않는다고 언급 했으므로 기본적으로 SSH 액세스를 끄고 장치를 "디버그"모드로 전환 한 경우에만 일시적으로 활성화 할 수 있습니다.

그런 다음 "디버그"모드를 보호하여 장치를 해킹하려는 누군가가 원격으로 트리거 할 수 없다고 가정하면 모든 장치를 동일한 키와 함께 제공 할 수 있습니다.

또는 장치가 "디버그"모드로 전환 될 때 새 키가 생성되므로 장치 전원을 켤 때마다 키를 생성하는 부팅 시간을 낭비하지 않아도됩니다.

보유한 제약 조건을 기반으로 한 샘플 공격 시나리오는 다음과 같습니다.

당신의 장치가 있다면, 예를 들어 라즈베리 파이라고 말하십시오. SD 카드를 걸어서 잡아 당기면 SD 카드를 내 컴퓨터에 꽂고 sshd 키를 찾아 원하는 곳에 복사 할 수 있습니다. 어쩌면 나는 내 자신의 라즈베리 파이와 USB 이더넷 카드를 잡을 수 있습니다. 이제 대상 장치와 장치가 어디를 가든지 ssh 연결을 모니터링 할 수 있습니다. 대상 장치가 ssh 연결을 시도하는 것을 볼 때 다음과 같이하십시오.

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

오, 그게 뭐야? 귀하의 비밀번호는 "나는 고양이를 좋아합니다"입니까? 이봐, 이건 네가 부인에게 보낸 흥미로운 이메일이야 그녀가 네 이웃집 아내에게 보낸이 이메일을 읽는다면 훨씬 더 흥미로울 것이다.

가능성은 끝 이 없습니다 . 그리고 sshd 키가 실제 서버에서 찾은 키와 동일하기 때문에 대상은 알 수 없습니다. 장치를 수신하는 시설의 물리적 보안에 따라 이는 매우 사소 할 수 있습니다 . 이러지 마

대신 이미 제안한 것을 수행하되 수정하십시오 . 이미지를 작성하기 전에 다음과 같이 실행하십시오.

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

이제 모든 서버에 새로운 키가 있습니다. 당신은 정말 때문에 정말 키의 복사본을 배포 할 싶지 않아요. 나는에있어 정직하게 말은 적어도 당신의 집 열쇠의 사진을 스냅과 집 주소와 인터넷에 업로드로 나쁜한다.