첫 SSH 세션, 돌아갈 방법과 함께.

접근 세부 정보와 복구 경로 수집

실제 서버 주소, SSH 포트, 로그인 사용자 이름, 초기 인증 방법, 그리고 서버의 호스트 키 지문에 대한 신뢰할 수 있는 출처가 필요합니다. 구성 도구에서 선택한 호스트 이름은 DNS를 설정하거나 계정을 생성하지 않습니다. 이러한 세부 정보는 Linux 이미지에 대한 가정이 아니라 실제 서비스 설정에서 얻으세요.

콘솔 또는 복구 환경에 접근하는 방법과 누가 접근 권한을 복구할 수 있는지 확인하십시오. 지금 해당 복구 경로를 열 수 있는지 점검하고, 잠금 상태에서 권한이나 복구 자격 증명이 없다는 사실을 뒤늦게 발견하지 마십시오. 독립적인 복구 경로가 없다면, 마련될 때까지 접근 설정을 변경하지 마십시오.

예제는 자체 컴퓨터의 Bash 클라이언트 터미널과 Ubuntu/Debian 서버를 사용합니다. 실제 세부 정보로 대체하십시오: builder, 포트 22 및 192.0.2.10, 이는 예약된 예제 주소입니다. 명령어는 사용자 환경에 맞게 검토해야 할 지침입니다. 이 가이드는 OffVPS 서버에 연결하거나 구성하지 않았습니다.

기존 키를 교체하지 않고 클라이언트 키 생성

개인 키는 클라이언트 컴퓨터에 남아 있습니다. 일치하는 공개 키는 서버 계정의 authorized keys에 설치할 수 있습니다. 둘 다 서버의 호스트 키가 아닙니다. 호스트 키는 별도의 키로, 접속 중인 머신을 식별하는 데 도움이 됩니다. 개인 키와 암호를 지원 메시지, 저장소 및 서버 업로드에서 제외하십시오.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

먼저 경로를 확인하십시오. SSH 디렉터리가 없으면 권한 700로 생성하십시오. 지정된 키 파일이 이미 존재하면 다른 이름을 선택하거나 기존 키를 의도적으로 재사용하십시오. 덮어쓰지 마십시오. 암호를 사용하여 전용 키를 생성하십시오:

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

두 번째 명령은 개인 키 자료가 아닌 공개 키 지문을 표시합니다. ssh-keygen 매뉴얼 은 키 유형, 출력 파일 및 지문을 설명합니다. 관리형 장치가 다른 키 정책을 요구하면 해당 정책을 따르고 서버 지원을 확인하십시오. 복구 계획이 이에 의존하는 경우 개인 키의 적절히 보호된 복구 사본을 보관하십시오.

인증 전에 서버 검증

신뢰할 수 있는 콘솔 또는 다른 인증된 설정 채널을 통해 서버의 Ed25519 호스트 키 지문을 확보하십시오. 표준 OpenSSH 경로를 사용하는 서버에서 관리자는 다음 명령으로 공개 파일을 검사할 수 있습니다:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

전체 SHA256 지문과 알고리즘을 첫 SSH 연결 프롬프트와 비교하십시오. 동일한 미검증 네트워크 연결을 통해서만 검색한 지문은 독립적인 검증이 아닙니다. 서버가 다른 호스트 키 알고리즘을 제공하면 서로 다른 값을 비교하지 말고 해당 키의 지문을 확보하십시오. OpenSSH의 호스트 키 검증 지침 은 이 비교를 설명합니다.

나중에 방문할 때 키가 예기치 않게 변경되면 중지하십시오. 재구축으로 호스트 키가 합법적으로 교체될 수 있지만, 복구 채널을 통해 해당 이벤트와 새 지문을 검증하십시오. 연결을 성공시키기 위해 경고를 무시하거나 이전 known-host 항목을 삭제하지 마십시오.

공개 키만 설치하고 첫 세션 열기

공개 키가 승인된 설정 절차를 통해 이미 설치되었다면 직접 연결하십시오. 그렇지 않으면 기존 검증된 접근 방법을 사용하여 의도한 계정에 공개 키를 추가하십시오. ssh-copy-id이 있는 클라이언트에서, 그리고 해당 초기 로그인 방법이 작동할 때만, 이 명령은 선택한 공개 키를 추가합니다:

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu의 OpenSSH 가이드 는 공개 키 설치 및 권한 요구 사항을 설명합니다. 전체 authorized_keys 파일을 교체하거나 다른 관리자의 항목을 변경하지 마십시오. 그런 다음 키 기반 세션을 여십시오:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

로그인 후 확인하십시오 id 및 hostname. 계정이 설정 세부 정보와 일치하는지 확인하세요. 호스트 이름만으로는 호스트 키 검증이 되지 않습니다. 작업에 관리 권한이 필요하다면 다음을 실행하세요. sudo -v 그리고 이 계정에 의도한 권한 경로가 있는지 확인하세요. 이 첫 번째 세션은 열어 두세요.

진정으로 별도의 두 번째 로그인 증명

다른 클라이언트 터미널을 열고 SSH 연결 공유 소켓을 재사용할 수 없는 새 연결을 요청하세요. 비밀번호 폴백이 깨진 키 설정을 숨기지 않도록 이 테스트를 공개 키 인증으로 제한하세요:

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

확인 id, hostname 그리고 필요한 경우, sudo -v 이 두 번째 세션에서도 마찬가지입니다. 클라이언트가 기존 연결을 재사용한다면 새 터미널만으로는 충분하지 않습니다. ControlPath=none 공유를 비활성화합니다. 다음을 참조하세요: OpenSSH 클라이언트 구성. 이 독립 연결이 성공하고 복구 경로를 계속 사용할 수 있게 된 후에만 원래 세션을 닫으세요.

이후 접근 변경 전에

이 첫 번째 세션에서는 SSH 포트, 인증 방법 및 방화벽 규칙을 그대로 두세요. 나중에 변경하기 전에 현재 구성을 저장하고 신뢰할 수 있는 콘솔을 통해 복원하는 방법을 문서화하세요. 다른 방법을 비활성화하기 전에 키 로그인이 작동하는지 확인하세요. 한 번에 검토된 변경 하나씩 수행하는 동안 첫 번째 세션을 열어 두세요.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

이 OpenSSH 실행 파일 경로가 있는 시스템에서는 -t 구성 구문과 호스트 키 정상 여부를 확인하고, -T 적용된 설정도 보고합니다. 연결별 Match 규칙에는 테스트 중인 계정과 주소에 대한 -C 매개변수가 필요할 수 있습니다. 이러한 검사는 방화벽 도달 가능성을 테스트하거나 새 로그인이 작동함을 증명하지 않습니다. 다음을 참조하세요: sshd 테스트 모드. 서비스 구성을 적용하거나 다시 로드하기 전에 오류를 해결한 다음, 독립 로그인 검사를 반복하세요.

실패를 사용하여 다음 점검 선택

• 시간 초과: 복구 경로를 통해 주소, 포트, 공급자 규칙 및 호스트 방화벽을 확인하세요.
• 연결 거부됨: SSH이 예상 주소와 포트에서 수신 대기 중인지 확인하세요.
• 권한 거부됨: 아직 열려 있는 세션에서 사용자 이름, 선택한 공개 키 및 계정 키 파일 권한을 확인하세요.
• 호스트 ID 변경됨: 계속하기 전에 머신과 새 지문을 독립적으로 확인하세요.

검증된 호스트 키 지문, 계정, 포트 및 복구 절차를 운영 노트에 기록하세요. 키 자료는 비공개로 유지하세요. 접근이 반복 가능해지면 다음으로 진행하세요: 첫 번째 API 릴리스 또는 애플리케이션의 리소스 예산.