고가용성 클러스터의 현재 활성 헤드에 연결해야 하는 스크립트가 있습니다.
클러스터의 각 노드에는 고정된 호스트 이름과 IP 주소가 있습니다.
현재 헤드에도 "가상 IP"가 있습니다. 전환이나 장애 조치가 발생하는 경우 다른 노드가 "가상 IP"로 구성되어 헤드 역할을 시작합니다.
내 스크립트가 가상 IP를 가리킬 수 있나요? ssh클러스터가 가상 IP를 다른 노드로 이동할 때 호스트 키 불일치에 대해 불평하지 않습니까?
답변1
예, 가능합니다.
sshd(8)(OpenSSH에서) 파일 형식을 지정합니다 known_host(섹션에서 SSH_KNOWN_HOSTS FILE FORMAT).
호스트 인증을 수행할 때 일치하는 행에 올바른 키가 있으면 인증이 허용됩니다.
이름이 같거나 호스트 키가 다른 여러 줄이 허용되지만 권장되지는 않습니다. 이는 다른 도메인의 호스트 이름의 축약된 버전이 파일에 포함될 때 필연적으로 발생합니다. 이러한 파일에는 충돌하는 정보가 포함될 수 있습니다. 두 파일 중 하나에서 유효한 정보가 발견되면 인증이 허용됩니다.
따라서 두 HA 헤더의 호스트 키를 ~/.ssh/known_hostsOR 에 추가하면 됩니다 /etc/ssh/ssh_known_hosts.
203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…6Yh5sHpkyIZvXLB
203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…R0RNVnMB6C4plFr
그리고 ssh불만 없이 둘 다에 연결됩니다.
답변2
예,첫 번째 답변맞다.
그러나 버전 8.5부터 OpenSSH 클라이언트에는 UpdateHostKeysssh_config 옵션이 기본적으로 활성화되어 있으며 이 옵션이 활성화되면 클라이언트가 연결된 호스트에 없는 모든 호스트 키를 자동으로 삭제하기 때문에 이 솔루션은 더 이상 작동하지 않습니다. 예를 들어, 클라이언트의 Known_hosts 파일에서 두 호스트 사이에 떠다니는 서비스 IP가 있고 각 호스트에는 자체 호스트 키가 있습니다.
이를 방지하려면 UpdateHostKeys no클라이언트 ~/.ssh/config파일에 설정을 지정하여 이전 동작을 복원해야 합니다.
답변3
이는 유효한 질문일 수 있지만 대부분의 경우 이는 XY 문제입니다.
첫째, 유동 IP는 고가용성 솔루션으로 적합하지 않습니다. 더 나은 솔루션을 구현하는 것이 비현실적인 경우가 있지만 이러한 경우는 드뭅니다(예: 기본 게이트웨이 주소).
클러스터의 기본 목적이 SSH 서버 역할을 하는 것이 아니라면 BAU 트래픽과 동일한 방식으로 SSH(라우팅 관리 트래픽)가 필요하지 않습니다. 클러스터 노드 중 하나에 오류가 발생하면 1) 이를 어떻게 확인하고 2) 문제를 해결합니까? 각 노드에 연결할 수 있어야 합니다. 어떤 노드가 클러스터 리더인지 알아야 합니다(별도의 장치에서 NAT를 사용하는 경우 각 노드 또는 컨트롤러의 클러스터 데몬에서 이를 가져와야 합니다).
하지만 그 모든 것을 제쳐두고 ...
SSH는 호스트 키 불일치에 대해 불평하지 않습니다.
ssh에게 이 작업을 수행하지 말라고 지시하면 그렇지 않습니다. ssh_config의 항목을 통해 가상 IP에 대해 특별히 이 작업을 수행할 수 있습니다. 스크립트가 비밀번호로 뭔가 지저분한 일을 하지 않는 한 expect보안 문제는 없습니다. 뭔가 지저분한 일을 하고 있다면 언제든지 주요 문제를 호스팅하고 처리 expect할 수 있습니다 .expect
모든 노드가 동일한 호스트 키를 갖는 경우에는 그렇지 않습니다.