SSH 인증서를 사용하지 않았다면 틀렸습니다 | 2회: 인증서의 가용성, 조작성, 안전성 향상

SSH에서 키 대신 인증서를 사용하는 이점에 대해 설명했습니다.이번 방송에서 우리는 인증서로 전환하여 개발자, 운영자, 안전팀의 생활을 어떻게 개선하는지를 강조하고자 한다.

인증서 인증을 통한 가용성 향상

SSH를 사용하여 원격 호스트에 처음 연결하면 다음과 같은 보안 경고가 표시되는 공개 키 인증을 사용합니다.

$ ssh [email protected]
The authenticity of host 'ec2-54-161-77-102.compute-1.amazonaws.com (54.161.77.102)' can't be established.
ECDSA key fingerprint is SHA256:2ae53QcOB0W6HO+XtPmMXk7To/MvMuhFxTj8ZD7eSsE.
Are you sure you want to continue connecting (yes/no)?

너는 아마 이전에 본 적이 있을 것이다.만약 대부분의 사람들과 같다면, '예' 를 입력하기만 하면 그것을 무시할 수 있도록 훈련될 것이다.이것은 합법적인 안전 위협이기 때문에 문제다.이것도 매우 무서운 사용자 체험이다.절대 다수의 SSH 사용자들이 사실상 이 경고를 이해하지 못할 것이라고 나는 감히 내기를 걸겠다.
SSH를 사용하여 호스트에 연결하면 호스트에서 사용자를 인증합니다.또한 SSH 클라이언트가 호스트에 대한 인증을 시도합니다.이를 위해서는 클라이언트가 호스트의 공개 키를 알아야 한다.호스트 키는 ~/.ssh/known_hosts의 간단한 데이터베이스에 저장됩니다.클라이언트가 이 데이터베이스에서 호스트의 공개 키를 찾지 못하면 이 경고를 받을 것입니다.그것은 호스트가 인증될 수 없다는 것을 알려 준다.

관리자에게 물어보거나 데이터베이스에 문의하거나 다른 방식으로 키 지문을 외부에서 검증해야 한다.아무도 안 그랬어."예"를 입력하면 연결이 인증되지 않은 상태에서 이루어지고 공개 키는 영구적으로 추가됩니다 ~/.ssh/known_hosts.신뢰(두부) 역모드를 사용한 것은 이번이 처음이다.
인증서 인증은 인증서를 사용하여 공개 키 연결을 전달하기 때문에 클라이언트는 호스트에 처음 연결되어도 인증을 할 수 있습니다.두부 경고가 사라졌다.
인증서 인증은 인증서를 발급할 때 사용자 정의 인증을 통해 SSH를 검사할 수 있는 편리한 부분도 제공한다.이를 통해 SSH의 가용성을 더욱 높일 수 있습니다.특히 SSO(Single Sign On) 를 SSH로 확장할 수 있습니다.SSO for SSH는 인증서 인증의 가장 큰 참여자 기술입니다.우리는 잠시 후에 이 생각으로 돌아가서 어떻게 사용성과 안전성을 더욱 강화하는지 볼 것이다.이제 우리는 조작성에 대해 계속 토론합시다.

인증서 인증을 통한 운영 편의성 향상

중요한 승인 및 배포를 취소하면 운영 효율성이 향상됩니다.평범한 키 관리 작업에 ops주기를 낭비하지 않을 뿐만 아니라, 전체 차량에 정적 키 파일을 추가, 삭제, 동기화, 심사하는 데 사용되는 국산 기계와 관련된 지속적인 비용을 제거할 수 있습니다.
다양한 인증 메커니즘을 통해 SSH 사용자 인증서를 발급하는 능력도 조작 자동화를 추진했다.cron 작업이나 스크립트가 SSH 접근을 필요로 한다면, 장기적인 정적 키를 미리 설정하지 않고 필요할 때 짧은 SSH 인증서를 자동으로 얻을 수 있습니다.
SSH 공개 키 인증은 호스트 이름 주변에 이상한 조작 제한을 도입했고 인증서 인증은 이러한 제한을 없앴다.보시다시피 SSH 클라이언트가 호스트에 처음 연결되면 사용자에게 두부 경고를 표시합니다.사용자가 예를 입력하면 호스트의 공개 키가 로컬에 추가됩니다~/.ssh/known_hosts.호스트 이름과 특정 키 사이의 이러한 연결은 영구적이다.호스트가 나중에 다른 공개 키를 제공하면 다음과 같이 호스트 키 유효성 검사 실패 오류 메시지가 더 무섭게 표시됩니다.

$ ssh [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:2ae53QcOB0W6HO+XtPmMXk7To/MvMuhFxTj8ZD7eSsE.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:11
ECDSA host key for ec2-54-161-77-102.compute-1.amazonaws.com has changed and you have requested strict checking.
Host key verification failed.

이것은 호스트 이름을 다시 사용하는 데 도전적이다.prod01.example.com 하드웨어 장애가 발생하고 같은 이름의 새 호스트로 교체되면 호스트 키 확인이 실패합니다.이것은 보통 한 무리의 엔지니어들이 해커에게 공격당했다고 알리기 위해 secops에 연락하게 만든다.
호스트 키 검증을 무시하는 것은 키가 완전히 같은 공격 테이블 면적을 가지고 있는지 모르는 것과 같습니다.이상하게도 OpenSSH는 키가 알 수 없을 때 쉽게 돌아갈 수 있는 알림을 통해 소프트 실패를 선택하지만, 일치하지 않을 때 하드 실패는 더욱 무섭고 돌리기 어려운 오류를 가져온다.
연결을 만들 때 공개 키가 연결된 현재 이름을 전달하기 때문에 인증서는 모든 문제를 복구합니다.호스트가 새 인증서를 받기만 하면 호스트의 공개 키를 변경하면 됩니다.호스트 이름을 안전하게 다시 사용할 수 있으며, 같은 이름으로 여러 호스트를 실행할 수도 있습니다.호스트 키 검증이 실패한 것을 다시는 보지 못할 것이다.이름 재사용을 제외하고 호스트 키 검증 실패를 없애는 것은 인증서 인증이 양호한 안전 위생을 촉진하는 많은 방법 중 하나라는 것을 곧 알게 될 것이다.

인증서 인증을 통한 보안 강화

SSH 프로토콜 자체는 안전하지만 공개 키 인증은 일련의 나쁜 안전 방법을 장려하여 양호한 안전 위생을 실현하기 어렵다.
공개 키 인증을 통해 키는 영구적으로 신뢰됩니다.유출된 개인 키나 불법 키 귀속은 오랫동안 무시되거나 보고되지 않을 수 있습니다.키 관리 부주의 (예를 들어 호스트에서 전 직원의 키를 삭제하는 것을 잊어버린 것) 로 인해 SSH를 열 수 없습니다. 권한이 부여되지 않은 접근은 끝이 없습니다.
다른 한편, 증서는 기한이 지나게 된다.오류, 절도, 오용, 또는 그 어떠한 형식의 키 유출 등 사건이 발생할 때 손상된 SSH 증빙서류는 자동으로 만료되며, 설령 사건이 주의되지 않았거나 보고되지 않았더라도 관여할 필요가 없다.SSH 인증서는 장애가 발생해도 안전합니다.만약 조치를 취하지 않고 방문 시간을 연장한다면 방문은 자연히 기한이 지나게 된다.SSH 사용자 및 호스트가 자격 증명을 업데이트하기 위해 정기적으로 CA에 보고하면 전체 감사 기록이 부산물로 생성됩니다.
우리는 공공 키 인증이 사용자들이 심각한 안전 경고 (두부) 를 무시하고 허위의 안전 오류를 일으키도록 훈련하는 방법을 보았다.이것은 조작상의 번거로움만은 아니다.호스트 키 검증 실패로 인한 혼란은 호스트가 키를 다시 설정하는 것을 권장하지 않습니다. 즉, 호스트의 키 쌍을 바꾸는 것입니다.호스트 개인 키가 잘 보호되지 않기 때문에 정기적으로 키를 다시 설정하는 것은 좋은 방법이다.사용자가 규정을 어기거나 떠난 후에 키를 다시 입력해야 할 수도 있습니다.그러나 이후의 호스트 키 검증 실패로 인한 중단을 피하기 위해, 보통 이렇게 하지 않습니다.인증서 인증은 호스트 키 업데이트를 보잘것없게 합니다.
공개 키 인증도 사용자로 하여금 키를 다시 입력하기 어렵게 한다.키 승인과 배달은 사용자가 가능한 도구가 되어 있어도 키를 다시 만들기를 원하지 않을 정도로 번거롭다.더 심각한 것은, 낙담한 사용자는 개인 키를 복제하고, 장치 사이에서 반복해서 사용하며, 보통 여러 해 동안 지속된다.키 재사용은 심각한 안전 위험이다.개인 키는 영원히 네트워크를 통해 전송해서는 안 된다.그러나 SSH 공개 키 인증은 사용자가 민감한 개인 키와 직접 접촉하게 하고 사용할 수 있는 키 관리 도구를 제공하지 못하게 한다.이것은 오용과 남용의 비결이다.
SSH CA와 간단한 사용자 명령행 클라이언트를 결합하면 키 생성을 단순화하고 사용자를 불필요한 세부 사항과 분리할 수 있습니다.인증서 인증은 모든 보안 위험을 완전히 제거할 수는 없지만 보다 직관적이고 사용하기 쉽고 남용하기 어려운 SSH 워크플로우를 촉진시킵니다.
SSH 인증서에 대한 자세한 내용은 를 참조하십시오.당신은 심지어 우리의 무료 위탁 관리 서비스를 시도하여 5분도 안 되는 시간 안에 SSH 인증서의 가치를 체험할 수 있습니다!