SSH 클라이언트에 대한 사용자 지정 연결 옵션을 구성하는 방법

소개

SSH(Secure Shell)는 원격 관리를 위해 Linux 서버에 연결하는 가장 일반적인 방법입니다. 명령줄을 통해 단일 서버에 연결하는 것은 비교적 간단하지만 여러 원격 시스템에 연결하기 위한 많은 워크플로우 최적화가 있습니다.

대부분의 시스템에서 가장 일반적으로 사용되는 명령줄 SSH 클라이언트인 OpenSSH를 사용하면 사용자 지정 연결 옵션을 제공할 수 있습니다. 이들은 서버마다 다른 옵션을 포함하는 구성 파일에 저장할 수 있습니다. 이렇게 하면 각 호스트에 대해 사용하는 다양한 연결 옵션을 분리 및 구성하는 데 도움이 되며 연결해야 할 때마다 명령줄에 광범위한 옵션을 제공하지 않아도 됩니다.

이 가이드에서는 SSH 클라이언트 구성 파일의 구조를 다루고 몇 가지 일반적인 옵션을 살펴보겠습니다.

전제 조건

이 가이드를 완료하려면 SSH에 대한 실무 지식과 연결할 때 제공할 수 있는 몇 가지 옵션이 필요합니다. 또한 최소한 테스트 목적으로 일부 사용자 또는 서버에 대해 SSH 키 기반 인증을 구성해야 합니다.

SSH 구성 파일 구조 및 해석 알고리즘

시스템의 각 사용자는 자신의 홈 디렉토리 내에 자체 SSH 구성 파일을 유지할 수 있습니다. 여기에는 연결 매개변수를 지정하기 위해 명령줄에서 사용하는 모든 옵션이 포함될 수 있습니다. ssh 명령에 추가 플래그를 추가하여 연결 시 구성 파일에 정의된 값을 항상 재정의할 수 있습니다.

SSH 클라이언트 구성 파일의 위치

클라이언트 측 구성 파일은 ~/.ssh/config에 있습니다. ~는 홈 디렉토리에 대한 범용 바로 가기입니다. 종종 이 파일은 기본적으로 생성되지 않으므로 직접 생성해야 할 수도 있습니다. touch 명령은 존재하지 않는 경우 생성합니다(존재하는 경우 마지막으로 수정된 타임스탬프를 업데이트합니다).

touch ~/.ssh/config

구성 파일 구조

config 파일은 호스트, 즉 원격 서버별로 구성됩니다. 각 호스트 정의는 일치하는 특정 호스트에 대한 연결 옵션을 정의할 수 있습니다. 더 넓은 범위를 가져야 하는 옵션에 대해서도 와일드카드가 지원됩니다.

각 섹션은 뒤따르는 구성 옵션과 일치해야 하는 호스트를 정의하는 헤더로 시작합니다. 일치하는 호스트에 대한 특정 구성 항목은 아래에 정의되어 있습니다. 각 항목은 정의되지 않은 항목의 기본값을 상속하므로 기본값과 다른 항목만 지정해야 합니다. 각 섹션은 하나의 Host 헤더에서 다음 Host 헤더까지 확장됩니다.

일반적으로 구성 목적과 가독성을 위해 각 호스트에 대해 설정되는 옵션은 들여쓰기됩니다. 이것은 어려운 요구 사항은 아니지만 한 눈에 해석할 수 있는 유용한 규칙입니다.

일반적인 형식은 다음과 같습니다.

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

여기에는 해당 호스트가 일치하는지 여부에 따라 각 연결 시도에 적용되는 4개의 섹션이 있습니다.

해석 알고리즘

SSH가 구성 값을 적용하기 위해 파일을 해석하는 방식을 이해하는 것이 중요합니다. 이것은 와일드카드와 Host * 일반 호스트 정의를 사용할 때 의미가 있습니다.

SSH는 명령줄에 제공된 호스트 이름을 구성 섹션을 정의하는 각 Host 헤더와 일치시킵니다.

예를 들어 다음 정의를 고려하십시오.

Host devel
    HostName devel.example.com
    User tom

이 호스트를 사용하면 명령줄에 다음을 입력하여 tom@devel.example.com으로 연결할 수 있습니다.

ssh devel

SSH는 구성 파일의 맨 위에서 시작하고 각 Host 정의를 확인하여 명령줄에 지정된 값과 일치하는지 확인합니다. 일치하는 첫 번째 호스트 정의가 발견되면 관련된 각 SSH 옵션이 향후 연결에 적용됩니다.

그런 다음 SSH는 파일 아래로 이동하여 다른 Host 정의도 일치하는지 확인합니다. 명령줄에 제공된 현재 호스트 이름과 일치하는 다른 정의가 발견되면 새 섹션과 연결된 SSH 옵션을 고려합니다. 그런 다음 이전 섹션에서 아직 정의하지 않은 새 섹션에 대해 정의된 모든 SSH 옵션을 적용합니다.

이것은 중요한 포인트입니다. SSH는 명령줄에 지정된 호스트 이름과 일치하는 각 Host 섹션을 순서대로 해석합니다. 이 과정에서 항상 각 옵션에 지정된 첫 번째 값을 사용합니다. 이전에 일치된 섹션에서 이미 제공된 값을 재정의할 방법이 없습니다.

즉, config 파일은 가장 구체적인 구성을 맨 위에 두는 규칙을 따라야 합니다. 이전 매칭 섹션에서 정의하지 않은 옵션을 적용하려면 나중에 더 일반적인 정의가 나와야 합니다.

이전 섹션의 예를 다시 살펴보겠습니다.

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

여기에서 처음 두 섹션이 리터럴 호스트 이름(또는 별칭)으로 정의된 것을 볼 수 있습니다. 즉, 와일드카드를 사용하지 않습니다. ssh firsthost를 사용하여 연결하면 맨 처음 섹션이 가장 먼저 적용됩니다. 그러면 이 연결에 대한 Hostname, User 및 IdentityFile이 설정됩니다.

두 번째 섹션을 확인하고 일치하지 않는 것을 발견하고 계속 진행합니다. 그런 다음 세 번째 섹션을 찾아 일치하는지 확인합니다. 이전 섹션의 값이 이미 있는지 확인하기 위해 ANOTHER_OPTION을 확인합니다. 그렇지 않은 경우 이 섹션의 값을 적용합니다. 그런 다음 Host * 정의가 모든 연결과 일치하므로 마지막 섹션과 일치합니다. 다른 섹션의 모의 CHANGE_DEFAULT 옵션에 대한 값이 없으므로 이 섹션의 값을 가져옵니다. 그런 다음 이 프로세스에서 수집된 옵션으로 연결됩니다.

명령줄에서 ssh secondhost를 호출하는 척하면서 다시 시도해 봅시다.

다시 첫 번째 섹션에서 시작하여 일치하는지 확인합니다. 이것은 firsthost에 대한 연결에만 일치하므로 이 섹션을 건너뜁니다. 두 번째 섹션으로 이동합니다. 이 섹션이 요청과 일치하면 이 연결에 대한 ANOTHER_OPTION 값을 수집합니다.

그런 다음 SSH는 세 번째 정의를 보고 와일드카드가 현재 연결과 일치하는지 확인합니다. 그런 다음 ANOTHER_OPTION에 대한 값이 이미 있는지 확인합니다. 이 옵션은 이미 일치된 두 번째 섹션에서 정의되었으므로 세 번째 섹션의 값은 삭제되고 영향을 미치지 않습니다.

그런 다음 SSH는 네 번째 섹션을 확인하고 이전에 일치된 섹션에서 정의되지 않은 옵션을 적용합니다. 그런 다음 수집한 값을 사용하여 연결을 시도합니다.

연결 옵션

이제 구성 파일을 작성하는 방법에 대한 아이디어를 얻었으므로 몇 가지 일반적인 옵션과 명령줄에서 이를 지정하는 데 사용할 형식에 대해 논의하겠습니다.

우리가 다룰 첫 번째 설정은 원격 호스트에 연결하는 데 필요한 최소 설정입니다. 즉, SSH 서버가 실행 중인 호스트 이름, 사용자 이름 및 포트입니다.

명령줄에서 포트 4567에서 SSH 데몬을 실행하는 example.com이라는 호스트에 apollo라는 사용자로 연결하려면 다음을 수행할 수 있습니다. 다음과 같이 ssh를 실행합니다.

ssh -p 4567 apollo@example.com

그러나 다음과 같이 -o 플래그와 함께 전체 옵션 이름을 사용할 수도 있습니다.

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"

SSH 매뉴얼 페이지에서 사용 가능한 전체 옵션 목록을 찾을 수 있습니다.

config 파일에서 이를 설정하려면 home과 같은 Host 헤더 이름을 선택해야 합니다.

Host home
    HostName example.com
    User apollo
    Port 4567

일반적인 SSH 구성 옵션

지금까지 연결을 설정하는 데 필요한 몇 가지 옵션에 대해 논의했습니다. 다음과 같은 옵션을 다뤘습니다.

HostName: 연결을 설정하는 데 사용해야 하는 실제 호스트 이름입니다. 이는 Host 헤더에 정의된 별칭을 대체합니다. 이 옵션은 호스트 정의가 연결할 실제 유효한 주소를 지정하는 경우에는 필요하지 않습니다.
사용자: 연결에 사용할 사용자 이름입니다.
포트: 원격 SSH 데몬이 실행 중인 포트입니다. 이 옵션은 원격 SSH 인스턴스가 기본 포트 22에서 실행되지 않는 경우에만 필요합니다.

탐색할 가치가 있는 다른 많은 유용한 옵션이 있습니다. 기능에 따라 구분된 몇 가지 일반적인 옵션에 대해 논의할 것입니다.

일반 조정 및 연결 항목

ServerAliveInterval: 이 옵션은 SSH가 서버의 응답을 테스트하기 위해 패킷을 보낼 때를 알도록 구성할 수 있습니다. 이것은 연결이 불안정하고 여전히 연결이 가능한지 알고 싶을 때 유용할 수 있습니다.\n
LogLevel: SSH가 클라이언트 측에 로그인하는 세부 수준을 구성합니다. 이것은 특정 상황에서 로깅을 끄거나 디버깅을 시도할 때 자세한 정보를 증가시키는 데 사용할 수 있습니다. 가장 낮은 것부터 가장 자세한 것까지 수준은 QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2 및 DEBUG3입니다.\n
StrictHostKeyChecking: 이 옵션은 ssh SSH가 호스트를 ~/.ssh/known_hosts 파일에 자동으로 추가할지 여부를 구성합니다. 기본적으로 이것은 원격 서버에서 받은 호스트 키가 known_hosts 파일에서 찾은 것과 일치하지 않는 경우 경고를 표시하는 "ask\로 설정됩니다. 지속적으로 연결하는 경우 다수의 임시 호스트(예: 테스트 서버)에 대해 이 설정을 "no\로 설정하는 것이 좋습니다. 그러면 SSH가 자동으로 호스트를 파일에 추가합니다. 이는 알려진 호스트가 주소를 변경하지 않아야 할 때 주소를 변경하는 경우 보안에 영향을 미칠 수 있으므로 활성화하기 전에 신중하게 생각하십시오.\n
UserKnownHostsFile: 이 옵션은 SSH가 연결된 호스트에 대한 정보를 저장할 위치를 지정합니다. 일반적으로 이 설정에 대해 걱정할 필요는 없지만 /dev/null로 설정하여 위에서 엄격한 호스트 검사를 해제한 경우 해당 설정을 버릴 수 있습니다.\n
VisualHostKey: 이 옵션은 연결 시 원격 호스트 키의 ASCII 표현을 표시하도록 SSH에 지시할 수 있습니다. 이 기능을 켜면 나중에 다른 컴퓨터에서 연결해야 하는 경우 호스트 키를 인식할 수 있으므로 호스트 키에 익숙해질 수 있는 유용한 방법이 될 수 있습니다.\n
압축: 압축을 켜면 매우 느린 연결에 유용할 수 있습니다. 대부분의 사용자에게는 이것이 필요하지 않습니다.\n

위의 구성 항목을 염두에 두고 여러 가지 유용한 구성 조정을 할 수 있습니다.

예를 들어 클라우드 제공업체에서 매우 빠르게 호스트를 생성하고 제거하는 경우 다음과 같은 것이 유용할 수 있습니다.

Host home
    VisualHostKey yes

Host cloud*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel QUIET

Host *
    StrictHostKeyChecking ask
    UserKnownHostsFile ~/.ssh/known_hosts
    LogLevel INFO
    ServerAliveInterval 120

이렇게 하면 홈 연결에 대한 시각적 호스트 키가 켜지므로 키에 익숙해질 수 있으므로 키가 변경되는지 또는 다른 시스템에서 연결할 때 인식할 수 있습니다. 또한 호스트를 확인하지 않고 오류를 기록하지 않도록 cloud*로 시작하는 모든 호스트를 설정했습니다. 다른 호스트의 경우 제정신 대체 값이 있습니다.

연결 전달

SSH의 일반적인 용도 중 하나는 원격 호스트를 통해 로컬 연결을 터널링하도록 허용하거나 원격 시스템이 로컬 시스템을 통해 터널링하도록 허용하는 연결 전달입니다. 별도의 지정된 "게이트웨이\ 서버를 통해 방화벽 뒤에 있는 원격 시스템에 연결해야 할 때 때때로 필요합니다. SSH는 또한 원격 호스트에 대한 포워딩 정보를 포함하는 SOCKS5와 같은 프로토콜을 사용하여 동적 포워딩을 수행할 수 있습니다.

이 동작을 제어하는 옵션은 다음과 같습니다.

LocalForward: 이 옵션은 로컬 포트의 트래픽을 원격 시스템으로 전달하여 원격 네트워크로 터널링하는 연결을 지정하는 데 사용됩니다. 첫 번째 인수는 트래픽을 보내려는 로컬 포트여야 하고 두 번째 인수는 원격 끝에서 트래픽을 보내려는 주소와 포트여야 합니다.\n
RemoteForward: 이 옵션은 로컬 시스템에서 터널링하기 위해 트래픽을 보낼 수 있는 원격 포트를 정의하는 데 사용됩니다. 첫 번째 인수는 원격 시스템에서 트래픽이 전달되는 원격 포트여야 합니다. 두 번째 인수는 트래픽이 로컬 시스템에 도착할 때 트래픽을 가리키는 주소와 포트여야 합니다.\n
DynamicForward: SOCKS5와 같은 동적 전달 프로토콜과 함께 사용할 수 있는 로컬 포트를 구성하는 데 사용됩니다. 동적 전달 프로토콜을 사용하는 트래픽은 로컬 컴퓨터의 이 포트로 전달될 수 있으며 원격 끝에서는 포함된 값에 따라 라우팅됩니다.\n

이러한 옵션은 여기에서 볼 수 있듯이 양방향으로 포트를 전달하는 데 사용할 수 있습니다.

# This will allow us to use port 8080 on the local machine
# in order to access example.com at port 80 from the remote machine
Host local_to_remote
    LocalForward 8080 example.com:80

# This will allow us to offer access to internal.com at port 443
# to the remote machine through port 7777 on the other side
Host remote_to_local
    RemoteForward 7777 internal.com:443

이는 SSH를 통하지 않고는 직접 액세스할 수 없는 서버에서 실행되는 개인 대시보드 또는 다른 웹 애플리케이션에 대한 브라우저 창을 열어야 할 때 특히 유용합니다.

기타 포워딩

연결 전달과 함께 SSH는 다른 유형의 전달도 허용합니다.

로컬 시스템의 에이전트에 저장된 모든 SSH 키를 전달할 수 있으므로 로컬 시스템에 저장된 자격 증명을 사용하여 원격 시스템에서 연결할 수 있습니다. 원격 시스템에서 응용 프로그램을 시작하고 X11 전달을 사용하여 그래픽 디스플레이를 로컬 시스템으로 전달할 수도 있습니다. X11은 Linux 디스플레이 서버이며 Linux 데스크톱 시스템 없이 사용하기에는 그다지 직관적이지 않지만 원격 및 로컬 Linux 환경을 모두 사용하는 경우 매우 유용할 수 있습니다.

이러한 기능과 관련된 지시문은 다음과 같습니다.

ForwardAgent: 이 옵션을 사용하면 로컬 컴퓨터에 저장된 인증 키를 연결하려는 시스템으로 전달할 수 있습니다. 이렇게 하면 홈 키를 사용하여 호스트 간에 이동할 수 있습니다.\n
ForwardX11: 원격 시스템에서 실행 중인 애플리케이션의 그래픽 화면을 전달할 수 있으려면 이 옵션을 켤 수 있습니다.\n

키 지정

호스트에 대해 구성된 SSH 키가 있는 경우 이러한 옵션은 각 호스트에 사용할 키를 관리하는 데 도움이 될 수 있습니다.

IdentityFile: 이 옵션은 각 호스트에 사용할 키의 위치를 지정하는 데 사용할 수 있습니다. SSH는 기본적으로 ~/.ssh에 있는 키를 사용하지만 서버별로 할당된 키가 있는 경우 찾을 수 있는 정확한 경로를 지정하는 데 사용할 수 있습니다.\n
IdentitiesOnly: 이 옵션은 SSH가 config 파일에 제공된 ID에만 의존하도록 강제하는 데 사용할 수 있습니다. 이는 SSH 에이전트의 메모리에 해당 호스트에 대해 유효하지 않은 대체 키가 있는 경우 필요할 수 있습니다.\n

이러한 옵션은 서로 다른 호스트에 대한 많은 수의 키를 추적하고 하나 이상의 SSH 에이전트를 사용하여 지원해야 하는 경우에 특히 유용합니다.

결론

SSH가 값을 해석하는 방식을 염두에 두는 한 합리적인 폴백으로 다양한 특정 값 세트를 설정할 수 있습니다.

비행기 Wi-Fi와 같이 매우 열악하거나 간헐적인 연결을 통해 SSH를 사용해야 하는 경우 불리한 상황에서 SSH가 작동하도록 설계된 mosh를 사용해 볼 수도 있습니다.