SSH를 사용하여 Linux에서 서버를 설정하는 방법

여러 대의 기계를 관리할 때, 같은 SSH 옵션이 이력에 빠르게 쌓입니다: 사용자, 포트, 개인 키, 가끔은 점프 호스트. 파일 ~/.ssh/config는 이 긴 줄을 짧은 이름으로 대체합니다. 예를 들어 ssh preprod와 같습니다.

서버를 수정할 필요는 없습니다. 이 설정은 귀하의 컴퓨터에 있으며, 클라이언트 OpenSSH에게 각 기계에 어떻게 접근하는지를 알려줍니다. 특히 여러 환경이 비슷할 때 잘못된 키나 잘못된 포트를 사용하는 것을 방지할 수 있습니다.

서버당 하나의 항목 만들기

폴더가 존재하지 않으면 만들고, 구성 파일을 엽니다:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/config

그런 다음 기계마다 하나의 블록을 추가합니다. 여기서 preprod는 단순히 로컬 별칭입니다. 주소, 계정, 포트 및 키 경로를 귀하의 값으로 교체하십시오.

Host preprod
    HostName 192.0.2.44
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_preprod
    IdentitiesOnly yes

이제 ssh preprod을 실행할 수 있습니다. HostName은 실제 DNS 이름이나 IP 주소, User는 원격 계정, Port는 SSH 포트를 나타냅니다. IdentityFile는 예상되는 개인 키를 선택합니다. IdentitiesOnly yes를 통해 클라이언트는 SSH 에이전트에 로드된 모든 키를 제안하지 않으므로 인증을 제한하는 서버에서의 무의미한 시도를 피할 수 있습니다.

이미 키를 사용 중이라면, 먼저 그 키가 잘 보호되어 있는지 확인하십시오. 개인 키는 귀하의 컴퓨터의 다른 계정에서 읽을 수 없어야 합니다:

chmod 600 ~/.ssh/id_ed25519_preprod
chmod 600 ~/.ssh/config

Ubuntu에서 SSH 키를 생성하는 방법는 키 쌍 생성에 대한 가이드를 포함합니다. 개인 키를 서버로 복사하지 마십시오. 오직 공개 키만이 원격에서 ~/.ssh/authorized_keys에 있어야 합니다.

파일 끝에 공통 설정 추가하기

하나의 config 파일은 여러 개의 Host 블록을 포함할 수 있습니다. OpenSSH 클라이언트는 대부분의 옵션에 대해 발견된 첫 번째 값을 기억합니다. 따라서 가장 구체적인 서버를 위쪽에 두고 일반적인 값을 아래쪽에 배치하십시오.

Host production
    HostName prod.example.net
    User deploy
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

Host sauvegarde
    HostName backup.example.net
    User backup
    Port 2201
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yes

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

Host * 블록은 모든 별칭에 적용됩니다. 정말 공통 설정, 여기서는 연결이 고착되지 않도록 주기적으로 신호를 보내는 경우에 적합합니다. 모든 서버가 동일한 계정을 사용하지 않는 경우 키나 사용자를 여기 넣지 마십시오.

같은 규칙을 따르는 호스트를 Host *.intra와 같은 패턴으로 모을 수도 있습니다. 예외는 이 블록 위에 두십시오. 모호한 별칭이나 너무 일찍 배치된 일반 규칙은 종종 예상치 못한 동작을 일으킵니다.

연결하기 전에 구성을 확인하십시오

다음 명령은 세션을 열지 않고 특정 별칭에 대한 최종 구성 정보를 표시합니다. 수정 후에 매우 유용합니다:

ssh -G preprod | grep -E '^(hostname|user|port|identityfile|identitiesonly) '

hostname, user 및 port가 올바른 기계와 일치하는지 확인하십시오. 또한 identityfile에 대해 반환된 경로를 확인하십시오. 키를 방금 이동했다면, SSH가 여전히 이전 파일을 가리키고 있을 수 있습니다.

그런 다음 간단한 테스트를 수행하십시오:

ssh preprod
ssh -v preprod

-v 옵션은 연결 단계와 읽은 구성 파일을 표시합니다. 이 출력을 티켓이나 채팅에 그대로 게시하지 마십시오. 호스트 이름, 계정 및 로컬 경로를 드러낼 수 있습니다.

config 파일만으로는 부족할 때

SSH 별칭은 옵션의 반복을 해결합니다. 키를 거부하는 서버, 닫힌 포트 또는 변경된 호스트 지문을 수정하지는 않습니다. 인증 요청이 자주 비밀번호를 요구한다면, 비밀번호를 키에서 제거하기보다는 ssh-agent를 사용하십시오.

점프 호스트를 통해 내부 서비스에 접근할 경우, ProxyJump로 별도의 항목을 유지하고 별도로 테스트하십시오. SSH 터널은 다른 요구에 응답합니다: 그것은 로컬 또는 원격 포트를 전달하지만 호스트 구성은 대체하지 않습니다.

~/.ssh를 chmod 700 ~/.ssh로 보호하십시오.
config 파일과 각 개인 키를 chmod 600으로 보호하십시오.
첫 번째 연결 전에 ssh -G nom_alias로 별칭을 확인하십시오.
각 새로운 서버는 해당 별칭으로 테스트한 후, 공통 옵션은 파일 맨 아래에 배치된 Host * 블록에 유지하십시오.

공식 문서 ssh_config(5)는 각 지시문을 자세히 설명합니다. 프로덕션 머신에서 별칭을 사용하기 전에 ssh -G의 출력을 두 분간 다시 살펴보십시오: SSH가 잘못된 키를 선택한 이유를 찾는 것보다 더 빠릅니다.