ssh 공개 키 사용 위험

나는이 서버 A 와 서버 B (백업) 및 서버 A에 누군가 나누기, 이것은 내가 SSH 공개 키를 사용하여 암호없이 로그인을 구성한 경우 서버 B에 침입하는 잠재적으로 위험 할 수 있을지, 궁금 해서요?

rsnapshot을 설정하려고합니다.

감사

예, 이것은 암호가없는 SSH 키의 문제 중 하나입니다. 서버 B에 연결할 수있는 개인 키를 서버 A에 저장하면 서버 A에 대한 액세스 권한이 서버 B에 효과적으로 액세스하는 것입니다. (반대가 사실이 아니므로 서버 B에 대한 액세스 권한이 발생하지 않습니다. 해당 방향으로 비밀번호없는 로그인을 허용하도록 SSH 키를 설정하지 않았다고 가정 할 때 서버 A가 즉시 손상됩니다.

이를 완화하기 위해 수행 할 수있는 몇 가지 작업이 있습니다.

• 프로세스를 완전히 자동화 할 필요가없는 경우 SSH 키에 비밀번호를 추가하십시오. (이것은 아마도 백업을위한 것이므로 작동하지 않을 것입니다)
• 자신의 계정으로 여러 컴퓨터에 암호없이 로그인하려면 물리적으로 입력 한 각 컴퓨터에 암호 키를 생성하고 SSH 에이전트를 사용하여 키를 메모리에 저장하는 것이 좋습니다. 에이전트 전달을 사용하면 각 원격 호스트에서 키를 만들지 않고도 호스트에서 호스트로 "홉"할 수 있습니다.
• 암호가없는 자동화 된 SSH 키의 경우 키가 실행할 수있는 명령을 제한하는 것이 좋습니다. 당신의에서 authorized_keys파일, 당신의 각 키를 가진 접두사 :
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 년 전에 수백 명의 로컬 사용자와 공유 사용자 환경에서 작업했으며 키에 비밀번호 정책을 시행 할 방법이 없었기 때문에 SSH 키 기반 로그인이 비활성화되었습니다. 시나리오를 완전히 제어하는 ​​한 요즘 SSH 키는 암호를 사용하는 것보다 확실히 좋습니다.

예, 인터넷에있는 대부분의 가이드는 암호가없는 ssh가 안전하게 작동하지 않고 작동하도록 중지합니다. 이 가이드 는 위험을 줄이기 위해 수행 할 수있는 작업을 잘 보여줍니다. 기본적으로 (기사 인용) :

• 작업에 대한 단일 목적 역할 계정을 작성하십시오. 즉 dnssync각 시스템 의 사용자
• 가능하다면 루트에 의존하지 않고 해당 사용자가 파일을 쓸 수 있도록하십시오.
• 특권 액세스가 필요한 비트의 경우 스크립트를 작성하고 sudo를 사용하십시오.
• 암호문없는 키를 제한하기 위해 파일의 사용 command=및 from=옵션authorized_keys
• 파일 전송을 수행하려면 수신 시스템에서 rsync를 사용하여 스크립트를 작성하여 원격 액세스를 읽기 전용으로 할 수 있습니다.
• 이것이 원격 컴퓨터에서 시작 컴퓨터에 다시 액세스해야 함을 의미하는 경우 ssh-agent, 두 번째 암호없는 키를 만드는 대신 사용하십시오

ssh 키에는 몇 가지 문제가 있습니다.

키를 취소하는 중앙 집중식 방법이 없습니다.

키에 비밀번호 정책을 시행 할 수있는 방법이 없습니다 (개인 키가 암호화되어 있으며, 그렇다면 적절한 비밀번호로 암호화되어 있습니까?).

이것들은 kerberos가 해결하는 문제입니다. 그러나 구현하기가 더 복잡하고 실제 사용자 관리 인프라가 배포 및 관리되어야하는 다른 것들도 소개합니다.

어쨌든 ssh certified_keys 는 morris-worm 유형의 공격을 허용하지만 .r 서비스 및 텔넷보다 몇 킬로미터 정도 더 낫습니다 (광년)

내가 통제 한 환경에서 나는 항상 서비스 계정에 대한 가능한 최소 권한에 대한 진정한 애착 자였습니다.

이 경우 원격 서버의 사용자 계정이 작고 엄격하게 정의 된 실행 파일 집합 만 실행할 수 있도록하는 것이 좋습니다. 원격 측과 sudo에서 여러 계정을 사용하여이를 수행 할 수 있습니다.

이 경우에도 여전히 로컬 권한 에스컬레이션 버그가 발생하므로 세심한주의를 기울이고 보안 버그를 철저히 추적하십시오.