SSH 비밀번호 인증이 보안 위험 인 이유는 무엇입니까?

OpenSSH 구성에 대한 대부분의 안내서는 키 기반 인증을 위해 암호 인증을 비활성화하는 것이 좋습니다. 그러나 필자의 의견으로는 암호 인증은 중요한 이점이 있습니다. 키없이 절대 어디에서나 연결할 수 있다는 것입니다. 항상 강력한 암호를 사용하면 보안 위험이 없어야합니다. 아니면해야합니까?

암호 또는 키 기반 인증에 대한 장단점이 있습니다.

예를 들어, 키 기반 인증은 암호 인증보다 덜 안전합니다. 다른 경우에는 보안 기반이 덜 안전합니다. 어떤 경우에는 더 편리하고 다른 경우에는 덜 편리합니다.

키 기반 인증을 수행 할 때 암호로 키를 보호 해야합니다 . ssh-agent가 실행 중이 아니면 (ssh-agent가 매번 암호문을 입력하지 않아도 됨) 편의상 아무것도 얻지 못했습니다. 보안은 논란의 여지가 있습니다. 이제 공격 경로가 서버에서 귀하 또는 귀하의 계정 또는 개인 컴퓨터로 옮겨졌습니다. (...)-침입하기 쉬울 수도 있고 아닐 수도 있습니다.

이것을 결정할 때 상자 밖에서 생각하십시오. 보안 측면에서 얻었는지 느슨하게하는지 여부는 나머지 환경 및 기타 조치에 따라 다릅니다.

편집 : 아, 방금 당신이 홈 서버에 대해 이야기하는 것을 보았습니다. 나는 항상 "비밀번호"또는 "키가있는 USB 스틱"과 같은 상황에 있었습니까? 나는 전자로 갔지만 SSH 수신 포트를 22가 아닌 다른 포트로 변경했습니다. 그러면 모든 네트워크 범위를 강제하는 모든 불쾌한 스크립트 키디가 무차별 적으로 중지됩니다.

ssh 키를 사용하면 비밀번호 로그인에 비해 고유 한 기능이 하나 있습니다. 허용 된 명령을 지정할 수 있습니다. ~/.ssh/authorized_keys서버에서 파일을 수정하여 수행 할 수 있습니다 .

예를 들어

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

특정 키와 함께`/usr/local/bin/your_backup_script.sh '명령 만 허용합니다.

키에 허용되는 호스트를 지정할 수도 있습니다.

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

또는 두 가지를 결합하십시오.

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

키를 사용하면 특정 계정의 암호를 공개하지 않고도 서버에 일부 사용자 (예 : 컨설턴트)에게 임시 액세스 권한을 부여 할 수도 있습니다. 컨설턴트가 작업을 마치면 임시 키를 제거 할 수 있습니다.

네트워크 내에서만 비밀번호 인증을 허용하여 두 가지 이점을 모두 누릴 수 있습니다. 끝에 다음을 추가하십시오 sshd_config.

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

질문에 부분적으로 응답했습니다. 공격자가 연결할 수있는 곳이 많을수록 무차별 공격 (DDoS 고려)을 통해 서버에 침입 할 가능성이 높아집니다.

또한 비밀번호 길이와 키 크기 (보통 수천 비트)를 비교하십시오.

비밀번호로 로그인하면 비밀번호가 서버로 전송됩니다. 이는 서버 운영자가 SSHD를 수정하여 비밀번호에 액세스 할 수 있음을 의미합니다. 공개 키 인증을 사용하면 모든 공개 키만 서버로 이동하므로 개인 키를 얻을 수 없습니다.

ssh 키는 사용자의 암호에 대한 중간 공격을 방지합니다.

키로 로그인을 시도하면 서버는 공개 키를 기반으로 챌린지를 구성하여 클라이언트로 보냅니다. 암호를 해독하고 보낼 적절한 응답을 구성합니다.

개인 키는 서버로 전송되지 않으며 청취하는 사람은 단일 세션을 가로채는 것 외에는 아무것도 할 수 없습니다.

암호를 사용하면 자격 증명이 생깁니다.

내 솔루션은 USB 키의 암호화 된 파티션에 적합한 형식의 휴대용 ssh 키를 사용하는 것입니다.
키를 잃어 버렸을 때 키를 쉽게 넣을 수 있습니다 .
내가 액세스 할 수있는 서버를 제한
하고 여전히 가지고 다닐 수 있습니다

마운트 소프트웨어를 설치하는 데 어려움이 있지만 (truecrypt)

@MartinVejmelka가 말한 것처럼 그것은 절충입니다.

키 기반 인증을 사용하는 이유는 키가 현재 또는 미래의 무차별 강제력 보다 훨씬 높기 때문에 자신의 PC에서 가져 오거나 USB 스틱 또는 이와 유사한 키를 가져야하기 때문입니다.

비밀번호에는 다음과 같은 문제가 있습니다.

• 짧으면 무차별적일 수 있습니다
• 그것이 길면 쉽게 잊혀진다
• 어깨 서핑을 할 수 있습니다

키는 수십배 더 길며 어떤 시점에도 표시되지 않으므로이 세 가지 문제를 피할 수 있습니다.

여기에 이미 언급 된 좋은 점.

강력한 암호를 사용하여 기본 사항을 처리 한 경우 가장 큰 위험은 사용자가 모르게 키로거를 설치 한 컴퓨터가 많다는 것입니다. 트로이 목마가 포함 된 유용한 유틸리티의 전체 사이트를 작성하는 사람들도 있으므로 우리에게 최선을 다할 수 있습니다. 키로거는 예를 들어 로그인 정보를 해커에게 이메일로 보낸 다음 서버에 쉽게 액세스 할 수 있습니다.

나는 최근에 Norton에서 Minecraft jar에 비행을 추가하기 위해 Zombee Mod 설치 프로그램 (jar이 아닌 설치 프로그램이 아닌)을 다운로드하는 것에 대해 경고했습니다. 자세한 내용을보고 Norton은이 사이트에 트로이 목마가있는 것으로 표시된 많은 유틸리티를 나열했습니다. 이것이 올바른지 아닌지는 모르겠지만 파일 이름과 관련이 있습니다. 또한 트로이 목마가 배포되기 전에 (일부) warez에 들어가는 것은 알려진 사실입니다.

비밀번호에 비해 SSH의 잠재적 이점 중 하나는 SSH 비밀번호 문구를 지정하지 않으면 비밀번호를 다시 입력 할 필요가 없다는 것입니다. 컴퓨터는 키를 가지고 있기 때문에 서버에서 본질적으로 신뢰할 수 있습니다. 즉, 나는 항상 SSH 암호를 항상 사용하므로 이점을 배제합니다.

사용자 가이드가 SSH over 비밀번호 인증을 권장하는 이유에 대한 가장 좋은 대답은 SSHOpenSSHKeys의 Ubuntu 매뉴얼에서 나온 것입니다. 나는 인용한다.

중요하지 않다고 생각되면 다음 주에 발생할 수있는 모든 악의적 인 로그인 시도를 기록해보십시오. 완전히 평범한 데스크톱 PC 인 내 컴퓨터는 지난 주에만 4,000 번 이상 암호를 추측하고 거의 2,500 건의 침입 시도를했습니다. 공격자가 비밀번호를 우연히 발견하기까지 수천 건의 무작위 추측이 필요하다고 생각하십니까?

기본적으로 문장 부호, 대소 문자 및 숫자가 포함 된 견고하고 길이가 긴 비밀번호가있는 경우 비밀번호 인증을 사용하는 것이 좋습니다. 또한 로그를 모니터링 할 계획이고 네트워크를 통해 "슈퍼 보안"작업을 수행하지 않는 경우 (예 : 홈 서버에 사용). 그런 다음 비밀번호가 제대로 작동합니다.

Passwd 인증 방법은 실제로 안전하지 않습니다 (imho). 이 메커니즘을 사용하면 비밀번호가 sshd 서버로 전송됩니다 (@ramon이 이미 말했듯이). 이는 일부 개인이 sshd 서버를 수정하여 비밀번호를 검색 할 수 있음을 의미합니다. MITM (Man-In-The-Middle) 공격을 사용하면 로컬 네트워크에서 매우 쉽게 수행 할 수 있습니다.

이 패치 ( https://github.com/jtesta/ssh-mitm )를 설치하여 sshd 서버를 패치 할 수 있습니다 . 사용 arpspoof및 iptables클라이언트와 정통 SSHD 서버 사이에 패치 서버를 넣어.

비밀번호 인증을 비활성화하십시오 : 구성 파일을 열고 /etc/ssh/ssh_config행을 추가하십시오 PasswordAuthentication no.

-o StrictHostKeyChecking=no옵션으로 with를 무시할 수 있습니다 . 쉘 스크립트에서 ssh를 사용할 때 매우 유용합니다.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost