여행 중에 호텔에서 SSH로 서버에 연결하는 것이 실제로 안전합니까?

여행 중에 호텔의 SSH를 사용하여 서버에 연결하는 것이 실제로 안전합니까?

서버 :
-CentOS 7
-RSA 키로 만 인증-비밀번호 인증 거부
-비표준 포트

워크 스테이션 :
-Ubuntu 14-
사용자 비밀번호
-RSA 키를 사용하기위한 비밀번호 (표준 방법)

개인 RSA 키의 절반 을 USB 스틱에 유지하고 연결하기 전에 자동으로 (스크립트로)이 절반을 ~ / .ssh / private_key에 추가 하는 것이 좋습니다 .

인터넷은 호텔의 WIFI 또는 임대 아파트의 케이블을 통해 이루어집니다.

UPD
처음에 불분명해서 죄송합니다. 여기서 두 가지 측면에서 보안을 의미합니다.

신뢰할 수없는 네트워크를 통한 SSH 연결의 보안
SSH 연결에 필요한 키로 컴퓨터 보안-도난당한 경우 서버를 보호하는 방법 ...

security physical-security

— 세르게이 세 로프
소스

반쯤 RSA 키? ssh 호스트 키의 공개 부분? 사용자 SSH 키의 개인 부분의 절반?

— andol

내 개인 RSA 키의 절반은 물론 :) 그리고 스크립트에 의해 자동 으로이 반을 서버에 연결하기 전에 ~ / .ssh / private_key에 추가합니다.

— Sergey Serov 2016 년

Linux를 실행하고 있기 때문에 대부분의 사람들보다 이미 안전합니다. 최신 버전을 실행 중이므로 더 강력한 암호화를 지원하는 새 버전의 OpenSSH가 있어야합니다. tecmint.com/5-best-practices-to-secure-and-protect-ssh-server 를 팔로우 한 후 stribika.github.io/2015/01/04/secure-secure- shell.html

— 병아리

@chicks는 "리눅스를 사용하고 있기 때문에 대부분의 사람들보다 더 안전하다"고 말하는 것은 어리석은 일입니다. SSH는 Linux, Unix (Mac) 또는 Windows에서 실행되는지에 관계없이 SSH입니다. 그리고 우리는 최근의 역사에서 Linux의 매우 심각한 보안 결함을 지적 할 수 있습니다 (Heartbleed, anyone?). 간단히 말해서, 실제 질문과 문제에서 벗어나기 때문에 바보 같은 OS 화염 전쟁이 그들이 속한 부업에 남길 수 있습니다. 감사! ;-)

— Craig

@ 병아리 나는 그것이 전달하려고했던 것 같아요. 모든 OS에 많은 보안 문제가 있으며 Microsoft는 몇 년 전 "신뢰할 수있는 컴퓨팅 * 이니셔티브를 시작한 이래로 엄청난 발전을 이루었습니다."리눅스가 있기 때문에 대화가 실제 문제와 다를 것 "이라고 생각합니다. ;-)

— Craig

답변:

따라서 명시 적으로 신뢰할 수없는 연결을 통해 ssh 연결을 만드는 것과 관련이 있습니다.

이전 연결의 ~ / .ssh / known_hosts 항목이 이미 있다고 가정하면 네트워크의 안전 여부에 대해 걱정하지 않고 연결할 수 있어야합니다. ssh 호스트 키를 확인하는 다른 방법이있는 경우에도 마찬가지입니다.

이전에 서버에 연결 한 적이 없거나 ssh 호스트 키를 확인하는 다른 방법이없는 경우 연결에 사용하는 네트워크에 대해 더주의를 기울여야 할 수 있습니다.

— 안돌
소스

감사합니다!! 따라서 공개 Wi-Fi를 통해서도 SSH로 서버에 연결하는 것이 안전합니까?

— Sergey Serov 2016 년

사실,이 답변이 적용 어떤 원격 서버에 ssh를하려는 상황이 어떤 경로의 일부 SSH - 보내고 새로 설치된 로컬 호스트 또는 크로스 링크 케이블을 통해 차별화 그래서 실질적으로 (전체 통제하에 아무것도하지 않습니다 )

— Hagen von Eitzen 2016 년

클라이언트가 호스트 키를 모르는 경우 암호 인증을 사용하면 전체 MITM 공격이 가능하다는 점에 유의하십시오. 그러나 키 기반 인증을 사용하는 경우 공격자는 서버를 가장 할 수만 있습니다. 침입자는 실제 서버에 대해서도 인증 할 수 없습니다. 이 경우 공격자가 확실한 서버 위장을 제공하기가 어려우므로 너무 늦기 전에 무언가가 잘못되었음을 알 수 있습니다. 간단히 말해 : 공개 키 인증은 암호 인증보다 훨씬 안전합니다 .

— kasperd 2016 년

@kasperd : 연결 클라이언트에 에이전트 전달이 활성화되어 있으면 공개 키 인증도 전체 MITM 환경을 제공 할 수 있습니다. 그러나 예, 공개 키 인증은 항상 일반 암호보다 선호됩니다.

— andol

@kasperd : 글쎄, 누군가가 에이전트 전달을 발견하고 있지만 완전히 이해하지 못하고 ~ / .ssh / config에 "Host * \ n \ tForwardAgent yes"와 같은 것을 넣은 것을 쉽게 상상할 수 있습니다. 사람들은 모든 종류의 미친 일을 :-)

— andol

질문의 두 번째 부분에서는 노트북이 도난 당하고 암호가없는 SSH를 사용하여 서버에 로그인하는 데 필요한 개인 키가 걱정되는 것 같습니다.

제발이는 쉽게 "암호"와 "암호화"개인 키를 저장하여 (개인 키 문제를) 해결할 수 있습니다 : 그들은 처음 암호화 할 수 있습니다, 반면에 발생 SSH-Keygen은 유틸리티의 말에 암호를 제공하여 생성 프로세스 또는 이미 암호화되지 않은 경우 ssh-keygen 유틸리티를 -p옵션 과 함께 사용하십시오 . 키가 암호화되면 로그인 할 때마다 관련 암호를 입력하라는 메시지가 표시되고 올바른 경우 모든 것이 정상적으로 진행됩니다.

또한 ssh 클라이언트를 시작할 때마다 암호를 입력하지 않으려는 경우 ssh-agent를 사용할 수 있습니다. 메모리에서 암호화되지 않은 개인 키를 추적 할 수 있습니다. 암호화 된 키를 보유한 파일을 가리키는 ssh-add 를 실행 하고 암호를 요청한 후 키가 ssh-agent가 관리하는 세트에 추가됩니다. 그 후 SSH 클라이언트가 암호문으로 보호 된 키를 요구할 때마다 ssh 에이전트는 암호화되지 않은 관련 개인 키를 ssh 클라이언트에 투명하게 제공합니다. 따라서 대화식으로 입력 할 필요가 없습니다.

ssh-agent는 많은 키를 관리 할 수 있으며 ssh-add, 로그인 / 시작시 노트북 / 데스크톱을 "조정"하여 유틸리티 (ssh-agent 키 세트를 채울 때)를 실행할 수 있습니다.

또한 누군가가 랩톱을 훔치는 경우 개인 키는 아마도 유일하게 "민감한"내용이 아닐 수도 있습니다. 오늘날의 Linux 데스크톱 배포에서는 "암호화 된"에 의존하는 노트북을 매우 쉽게 설정할 수 있습니다 "파일 시스템 ( /home초보자이지만 /필요한 경우 전체 ). 그래서 이것도 고려하십시오.

자신의 노트북 에 의존 하지 않으면 위의 모든 사항이 적용 되지 않습니다 .

추신 : 암호화되지 않은 개인 키의 두 반쪽을 다른 매체에 저장할 수있는 가능성에 관해서 : 민감한 내용의 두 조각을 암호화되지 않은 형태로 유지하는 것이 두 가지를 유지하는 것보다 훨씬 나쁘기 때문에 이것을 하지 말 것을 강력히 권합니다 암호화 된 전체 내용의 전체 사본!

— 다미아노 베르 줄리
소스

질문의 첫 부분은 이미 이전 답변으로 답변되었습니다. 두 번째 부분에 따라 pam_google_authenticator를 사용하여 ssh 로그인에 두 번째 요소를 추가하는 것이 좋습니다. 모든 배포판에서 설정 및 구성이 매우 쉽습니다. 휴대하는 개인 키를 도난당한 경우 Google 인증 자에서 TOTP 일회용 비밀번호를 사용하여 서버에 로그인 할 수 없습니다.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— 아룰 셀반
소스