Linux PC에서 OpenSSH에 대해 알아보십시오.

우리는 SSH의 장점을 보안 및 원격 액세스를 위해 여러 번 강조했습니다. 서버 자체, 중요한 "유지 관리"측면 및 그 밖의 부드러운 라이딩에 난기류를 추가 할 수있는 몇 가지 단점에 대해 살펴 보겠습니다..

이 가이드를 Linux에서 염두에두고 작성했지만, Cygwin을 통해 Mac OS X 및 Windows 7의 OpenSSH에도 적용될 수 있습니다.

안전한 이유

우리는 SSH가 데이터를 한 지점에서 다른 지점으로 안전하게 연결하고 터널링하는 좋은 방법이라고 여러 번 언급했습니다. 일들이 어떻게 작동하는지 아주 간략하게 살펴보고 가끔 이상한 일이 일어날 수있는 이유에 대해 더 잘 이해해 봅시다..

우리가 다른 컴퓨터에 연결을 시작하기로 결정할 때 우리는 쉽게 작업 할 수있는 프로토콜을 사용합니다. 텔넷과 FTP 모두 마음에 온다. 원격 서버에 정보를 보내면 연결에 대한 확인을 다시받습니다. 일종의 안전성을 확보하기 위해이 프로토콜은 종종 사용자 이름과 암호 조합을 사용합니다. 그것은 그들이 완전히 안전하다는 것을 의미합니다, 그렇죠? 잘못된!

연결 프로세스를 메일로 생각하면 FTP와 텔넷 등을 사용하는 것은 표준 우편 봉투를 사용하는 것과 같지 않습니다. 그것은 엽서를 사용하는 것과 같습니다. 누군가 중간에 계단을 걷는다면, 그들은 통신원 주소와 보내는 사용자 이름과 암호를 포함한 모든 정보를 볼 수 있습니다. 그런 다음 메시지를 변경하고 정보를 동일하게 유지하며 한 명이나 다른 메시지를 가장 할 수 있습니다. 이를 "중간자 (man-in-the-middle)"공격이라고하며, 계정을 손상시킬뿐만 아니라 전송 된 모든 메시지와 파일을 질문합니다. 발신자와 통화하고 있는지, 발신자와 통화 중인지 확실하지 않을 수 있으며, 상대방이 무엇이든간에 아무도보고 있지 않은지 확신 할 수는 없습니다..

이제 HTTP를 더욱 안전하게 만드는 SSL 암호화를 살펴 보겠습니다. 여기에는 서신을 처리하는 우체국이 있으며, 수령인이 자신이 주장하는 사람인지 확인하고, 귀하의 우편물을 보지 못하게하는 법률을 가지고 있습니다. 전반적으로 보안이 강화되었고, 중앙 기관인 Verisign은 HTTPS 예제에서 메일을 보내는 사람이 체크 아웃하는지 확인합니다. 그들은 엽서 (암호화되지 않은 자격 증명)를 허용하지 않음으로써 이것을합니다; 대신 그들은 진짜 봉투를 요구한다..

마지막으로, SSH를 살펴 보겠습니다. 여기서는 설정이 약간 다릅니다. 여기에는 중앙 인증자가 없지만 상황은 여전히 안전합니다. 그것은 당신이 이미 알고있는 주소의 누군가에게 편지를 보내고 있기 때문입니다. 전화로 그들과 이야기를 나눠 보면서 말입니다. 그리고 당신은 봉투에 서명하기 위해 정말 멋진 수학을 사용하고 있습니다. 당신은 그것을 당신의 형제, 여자 친구, 아빠, 또는 딸에게 넘겨 주소로 가져 가야합니다. 그리고 수령인의 화려한 수학 일치가 그 주소가 있어야한다고 가정한다면 말입니다. 그런 다음 편지를 받고,이 놀라운 수학으로 눈을 뗄 수없는 상태에서 보호받을 수 있습니다. 마지막으로 알고리즘에 매료 된 또 다른 숨겨진 봉투에 사용자의 자격 증명을 보낼 수 있습니다. 수학이 일치하지 않으면 원래 수신자가 이동했다고 가정 할 수 있으며 주소를 다시 확인해야합니다..

설명이있는 한 그곳에서자를 것입니다. 좀 더 통찰력이 있다면, 물론 코멘트에 채팅 할 수 있습니다. 지금은 SSH, 호스트 인증과 가장 관련성이 높은 기능을 살펴 보겠습니다..

호스트 키

호스트 인증은 본질적으로 신뢰하는 사람이 봉투를 가져 와서 (마법의 수학으로 봉인 된)받는 사람의 주소를 확인하는 부분입니다. 그것은 주소에 대한 아주 상세한 설명이고, 우리가 바로 건너 뛸 복잡한 수학에 기초합니다. 이 문제를 해결하는 데 중요한 몇 가지 사항이 있습니다.

중앙 권한이 없으므로 실제 보안은 호스트 키, 공개 키 및 개인 키에 있습니다. (후자의 두 키는 시스템에 대한 액세스 권한이 주어지면 구성됩니다.)
일반적으로 SSH를 통해 다른 컴퓨터에 연결하면 호스트 키가 저장됩니다. 이것은 미래의 행동을 더 빠르게 (또는 덜 장황하게).
호스트 키가 변경되면 가장 가능성이 높으며주의해야합니다!

호스트 키는 인증 전에 SSH 서버의 ID를 설정하기 위해 사용되기 때문에 연결하기 전에 반드시 키를 확인해야합니다. 아래의 확인 대화 상자가 나타납니다..

그래도 걱정하지 않아도됩니다! 종종 보안이 중요 할 때 호스트 키 (위의 ECDSA 지문)가 확인 될 수있는 특별한 장소가 있습니다. 전적으로 온라인 벤처 기업의 경우 보안 로그인 전용 사이트에 보관됩니다. IT 부서에 전화하여이 키를 전화로 확인해야 할 수도 있습니다 (또는 선택할 수도 있습니다). 나는 심지어 열쇠가 당신의 작업 배지 또는 특별한 "긴급 전화 번호"목록에있는 몇몇 장소에 대해 들었습니다. 또한 대상 컴퓨터에 실제로 액세스 할 수있는 경우 직접 확인할 수도 있습니다!

시스템의 호스트 키 확인

키를 만드는 데 사용되는 암호화 알고리즘에는 4 가지 유형이 있지만 올해 초 OpenSSH의 기본값은 ECDSA입니다 (몇 가지 좋은 이유가 있습니다). 우리는 오늘 그 문제에 집중할 것입니다. 다음은 액세스 할 수있는 SSH 서버에서 실행할 수있는 명령입니다.

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

출력 결과는 다음과 같습니다.

256 ca : 62 : ea : 7c : e4 : 9e : 2e : a6 : 94 : 20 : 11 : db : 9c : 78 : c3 : 4c /etc/ssh/ssh_host_ecdsa_key.pub

첫 번째 숫자는 키의 비트 길이이고, 키 자체는 키이며, 마지막으로 키가 저장된 파일입니다. 원격으로 로그인하라는 메시지가 표시 될 때 볼 수있는 것과 중간 부분을 비교하십시오. 일치해야하며 모두 설정되어 있습니다. 그렇지 않으면 다른 일이 일어날 수 있습니다..

known_hosts 파일을보고 SSH를 통해 연결된 모든 호스트를 볼 수 있습니다. 일반적으로 다음 위치에 있습니다.

~ / .ssh / 알려진 호스트

텍스트 편집기에서 열 수 있습니다. 당신이 보는 경우에, 열쇠가 저장되는 방법에주의를 기울이십시오. 호스트 컴퓨터의 이름 (또는 웹 주소)과 IP 주소로 저장됩니다.

호스트 키 및 문제점 변경

호스트 키가 변경되거나 known_hosts 파일에 기록 된 것과 일치하지 않는 몇 가지 이유가 있습니다.

시스템이 재설치 / 재구성되었습니다..
보안 키로 인해 호스트 키가 수동으로 변경되었습니다..
OpenSSH 서버가 업데이트되어 보안 문제로 인해 다른 표준을 사용 중입니다..
IP 또는 DNS 임대가 변경되었습니다. 이것은 종종 다른 컴퓨터에 액세스하려고 함을 의미합니다..
시스템이 어떤 식 으로든 손상되어 호스트 키가 변경되었습니다..

대부분이 문제는 처음 세 가지 중 하나이며 변경 사항을 무시할 수 있습니다. IP / DNS 임대가 변경되면 서버에 문제가있을 수 있으며 다른 시스템으로 라우팅 될 수 있습니다. 변경 이유가 무엇인지 확실하지 않은 경우 목록의 마지막 것으로 가정해야합니다..

OpenSSH가 알 수없는 호스트를 처리하는 방법

OpenSSH에는 "StrictHostKeyChecking"변수 (따옴표 제외)에 반영된 알 수없는 호스트를 처리하는 방법에 대한 설정이 있습니다..

구성에 따라 알 수없는 호스트 (키가 known_hosts 파일에없는 호스트)와의 SSH 연결은 세 가지 방식으로 진행될 수 있습니다.

StrictHostKeyChecking은 no로 설정됩니다. OpenSSH는 호스트 키 상태에 관계없이 모든 SSH 서버에 자동으로 연결됩니다. 이것은 안전하지 않으며 권장되지 않습니다. OS를 다시 설치 한 후에 여러 호스트를 추가하는 경우를 제외하고는 다시 변경해야합니다.
StrictHostKeyChecking이 요청하도록 설정되었습니다. OpenSSH는 새로운 호스트 키를 보여주고 추가하기 전에 확인을 요청합니다. 연결이 변경된 호스트 키로가는 것을 막습니다. 기본값입니다..
StrictHostKeyChecking이 yes로 설정됩니다. "no"의 반대는 known_hosts 파일에 아직없는 호스트에 연결하지 못하도록합니다.

다음 패러다임을 사용하여이 변수를 명령 줄에서 쉽게 변경할 수 있습니다.

ssh -o 'StrictHostKeyChecking [option]'user @ host

[option]을 "no", "ask"또는 "yes"로 바꾸십시오.이 변수와 설정을 둘러싼 단일 직선 따옴표가 있음에 유의하십시오. 또한 user @ host를 연결할 서버의 사용자 이름과 호스트 이름으로 바꿉니다. 예 :

ssh -o 'StrictHostKeyChecking ask'[email protected]

변경된 키로 인해 차단 된 호스트

액세스하려는 서버의 키가 이미 변경된 경우 기본 OpenSSH 구성을 사용하여 액세스 할 수 없게됩니다. 해당 호스트의 StrictHostKeyChecking 값을 변경할 수는 있지만 완전히 철저하고 편집 적으로 안전하지는 않습니까? 대신 known_hosts 파일에서 문제가되는 값을 제거 할 수 있습니다.