PuTTY는 PPK 형식의 개인 키 파일을 요구하고, Linux OpenSSH 서버는 대상 계정에서 공개 키를 허용합니다. 이 두 파일은 서로 다른 위치에 저장됩니다: PPK는 Windows 로컬에 남고, 공개 키는 서버의 authorized_keys에 추가됩니다.
PuTTYgen을 사용하여 새로운 키 쌍을 생성하거나 이미 존재하는 OpenSSH 개인 키를 가져올 수 있습니다. 두 경우 모두 배포 중에는 웹 세션이나 비상 콘솔을 유지하십시오. 새로 생성된 키는 공개 키가 서버에 허용될 때까지 서버에 접근할 수 없습니다.
호스트, 포트, 계정 및 초기 핑거프린트 검증 설정을 보려면 PuTTY를 사용하여 Linux 서버에 연결 설정하기 가이드를 따르십시오. 여기서는 키 준비와 PuTTY가 실제로 이를 사용하는 방법에 대해 다룹니다.
두 개의 키와 대상 Linux 계정 식별하기
SSH 쌍은 개인 키와 공개 키로 구성됩니다. 개인 키는 당신의 신원을 증명하기 위해 사용됩니다: 절대 공유하지 마십시오 및 서버에 업로드하지 마십시오. PuTTYgen은 이를 .ppk 형식으로 저장합니다. 이 파일은 Windows에서 패스프레이즈로 보호하고 필요시 암호화된 백업을 안전한 위치에 보관하십시오.
공개 키는 서버에 전달할 수 있습니다. OpenSSH의 경우, 이는 일반적으로 해당 Linux 계정의 ~/.ssh/authorized_keys 파일의 한 줄로 표시됩니다. 계정, 개인 디렉토리 및 허용된 경로는 변경하기 전에 확인해야 합니다. 관리되는 서버는 다른 위치를 AuthorizedKeysFile 설정으로 지정할 수 있습니다.
패스프레이즈는 로컬 개인 키를 보호합니다; 이는 Linux 계정의 비밀번호가 아닙니다. 키 인증은 또한 이중 인증의 적용을 받을 수 있습니다. 마지막으로, 호스트 키는 서버의 신원을 확인하는 데 사용됩니다: 이는 사용자의 키와 다르며 항상 확인해야 합니다.
PuTTYgen으로 키 쌍 생성하고 PPK 저장하기
Windows 로컬에서 PuTTYgen을 열고, 서버와 정책이 허용하는 경우 Ed25519를 사용하여 EdDSA를 선택하십시오. 버전에 따라 이러한 유형의 레이블은 다를 수 있습니다. RSA는 환경이 요구할 경우의 호환성 옵션으로 남아 있습니다; 문제를 회피하기 위해 이전 SHA-1 또는 SSH-1 서명을 재활성화하지 마십시오. 만약 Ubuntu에서 쌍을 생성하는 것을 선호한다면, Ubuntu에서 SSH 키 생성하기 가이드를 따르십시오; PuTTYgen은 Windows에서 설명된 경로에 해당합니다.
Generate를 클릭하고 도구의 마우스 이동 요청을 따릅니다. 민감한 정보를 노출하지 않는 인식 가능한 주석을 추가하십시오. Key passphrase와 Confirm passphrase에 입력한 후 Save private key를 클릭하십시오. 파일 .ppk의 위치를 기록하고, 오직 허가된 사용자만 접근할 수 있는 개인 폴더를 선택하십시오. 생성만으로는 파일이 저장되지 않습니다.
Public key for pasting into OpenSSH authorized_keys file에 표시된 값을 복사합니다. 이는 Linux 계정에 추가해야 할 줄입니다. Save public key 버튼은 RFC 4716을 포함한 다른 형식을 생성할 수 있습니다. OpenSSH 파일에 BEGIN SSH2 PUBLIC KEY 블록을 붙여넣지 마십시오. PuTTYgen이 제안한 PPK 형식 설정을 유지하십시오; 클라이언트가 형식을 인식하지 못한다면 형식을 약화시키기보다는 업데이트하십시오.
기존 OpenSSH 키를 PPK로 가져오기
이미 OpenSSH 개인 키가 있는 경우, PuTTYgen을 사용하여 Windows 로컬에 가져옵니다: Conversions > Import key을 선택하고, 개인 파일을 선택한 후 PuTTYgen이 요구하는 경우 패스프레이즈를 입력하십시오. 그런 다음 Save private key로 PPK 형식으로 복사본을 저장합니다.
이 작업은 PuTTY 용기로 변환합니다; 새로운 신원을 생성하지 않습니다. 공개 키와 그 핑거프린트는 원래 쌍의 것으로 남아야 합니다. PuTTYgen에서 이동 전과 후에 핑거프린트를 확인하고, 해당 공개 키가 Linux 계정에 잘 허가되었는지 확인하십시오. 공개 키만으로는 개인 키를 복원할 수 없습니다; 보통 .pub 확장명으로 명명됩니다. .pem 파일의 이름을 .ppk로 변경하는 것도 변환이 아닙니다: 형식이 다르므로 가져오고 PuTTYgen이 이를 인식하는지 확인해야 합니다.
개인 키를 웹 변환기로 전달하지 말고, 서버의 root 계정에서 복구하지 마십시오. 분실되거나 패스프레이즈를 잊어버린 경우, 새로운 쌍을 생성하고 비상 접근을 통해 공개 키의 허가를 요청하고 이를 테스트한 후 필요 없을 경우 오래된 허가를 제거하십시오.
다른 키를 덮어쓰지 않고 적절한 계정에 공개 키 추가하기
다음 명령은 이미 대상 계정으로 열린 Linux 셸에서 실행되며, PowerShell에서 자동으로 root가 아님을 확인하는 데 사용됩니다. 이는 우선 계정의 유효성과 관련 경로를 확인하는 데 도움이 됩니다:
whoami
printf '%sn' "$HOME"
ls -ld "$HOME" "$HOME/.ssh"
ls -l "$HOME/.ssh/authorized_keys"whoami가 예상한 계정을 표시하고 $HOME이 개인 디렉토리인 것을 확인하십시오. ls 명령은 폴더와 파일 소유자 및 권한의 존재를 점검합니다. 경로가 존재하지 않다는 메시지는 초기 설치 과정에서는 정상일 수 있습니다. 실수로 root 디렉토리에 파일을 만들지 마십시오.
일반적으로 이 계정에 연결되어 있으면, 이러한 명령은 디렉토리를 준비하고 Nano 에디터로 파일을 엽니다:
umask 077
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
nano "$HOME/.ssh/authorized_keys"
chmod 600 "$HOME/.ssh/authorized_keys"umask 077는 이 셸에서 기본 권한을 제한합니다. mkdir -p는 필요한 폴더가 없을 경우 내용을 삭제하지 않고 생성합니다. 700 모드는 .ssh 폴더를 계정에 예약하고, 600 모드는 파일을 소유자에게 예약합니다. Nano에서 PuTTYgen에서 복사한 공개 키 줄을 파일 끝에 추가하고, 기존 줄은 삭제하지 마십시오. 저장하고 편집기를 종료합니다. 파일이 이미 존재하는 경우 수정 전에 백업하십시오. > 리디렉션을 사용하여 이를 덮어쓰지 마십시오.
편집 후, 여전히 대상 계정의 셸에서 이 명령은 authorized_keys에 존재하는 공개 키의 핑거프린트를 읽습니다:
ssh-keygen -lf "$HOME/.ssh/authorized_keys" -E sha256예상되는 핑거프린트를 PuTTYgen에서 표시된 것과 비교하고, 파일에 여러 개의 키가 있을 경우 올바른 항목을 식별하십시오. 이 체크는 허가된 사용자 키에 관한 것이며, 원격 머신의 핑거프린트에 대한 것이 아닙니다. 비교를 단순화하기 위해 다른 키는 제거하지 마십시오.
개인 디렉토리, 소유자, ACL 또는 키 경로가 개인화 되어 있다면, 관리자가 구성 확인을 요청하십시오. chmod -R 및 무작위로 적용된 chown을 피하십시오: 이들은 SSH와 관련 없는 파일을 변경할 수 있습니다. Linux 로컬에서 다른 방법으로는 ssh-copy-id로 공개 키 설치하기가 있습니다. 이 명령은 Linux 클라이언트에 관계되며, Windows의 PuTTY에는 적용되지 않습니다.
PuTTY에서 PPK 선택하고 인증 확인하기
PuTTY에서 해당 세션을 로드하십시오. Connection > SSH > Auth > Credentials을 열고, Private key file for authentication에서 파일을 선택하십시오. Session으로 돌아가 구성 저장을 하십시오. 이 세션의 원격 계정은 이미 설정한 것입니다.
비상 세션을 유지하고 새로운 PuTTY 창을 열어 테스트를 수행하십시오. PuTTY가 알려지지 않은 호스트 핑거프린트를 경고하면, 신뢰할 수 있는 경로를 통해 얻은 값과 비교한 후 계속 진행하십시오. 개인 키의 패스프레이즈가 요구될 수 있습니다: 이는 PuTTY가 Linux 비밀번호를 요구하는 것이 아닙니다.
사용된 방법을 확인하기 위해, PuTTY의 Event Log를 열고 공개 키 인증을 위해 제안되고 수락된 키가 나타나는 것을 확인하십시오. 단순한 셸 접근만으로는 충분하지 않습니다: Pageant가 다른 키를 제공했을 수 있으며, PuTTY는 또한 다른 인증 방법을 가질 수 있습니다. 테스트를 고립시키기 위해 Pageant를 일시적으로 종료하거나 키를 제거하고 세션에서 PPK를 명시적으로 선택하십시오. PuTTY가 Linux 비밀번호를 요구하면, 이 테스트를 중단하십시오: 회귀 연결이 키가 작동했다는 것을 증명하지는 않습니다. 서버에서 요구한 추가 요소를 준수하십시오.
두 번째 연결의 셸에서 다음 명령은 도달한 계정과 머신을 확인하지만, 인증 방법을 확인하지는 않습니다:
whoami
hostname표시된 계정과 대상 계정을 비교하고, 기대하는 호스트 이름을 확인하십시오. PuTTY의 Event Log 및 필요시 서버 측 로그는 사용된 방법을 확립합니다. 결과 확인 후에만 비상 세션을 종료하십시오.
필요한 것보다 더 많은 권한없이 Pageant 사용하기
Pageant는 선택 사항입니다. 먼저 PPK로 직접 테스트를 성공하십시오. 다음 연결 시 패스프레이즈를 반복 입력하지 않게 하려면, Pageant를 실행하고 창을 열어 Add Key를 선택한 후 PPK 파일을 선택하십시오. 로컬에서 잠금을 해제하고 표시된 주석 또는 핑거프린트를 확인하십시오. PuTTY는 그때부터 에이전트에게 서명 거래를 요청할 수 있습니다.
패스프레이즈는 디스크에 파일을 보호하며; Pageant는 키가 사용 가능한 메모리 내에서 보관될 수 있도록 사용을 용이하게 합니다. 에이전트는 서버에 공개 키를 설치하지 않으며, 호스트 핑거프린트 검사를 대체하지 않습니다. Remove Key는 에이전트에서 키를 제거하지만 authorized_keys에서 제거하지는 않습니다. 이 컴퓨터에 대한 접근을 철회하려면, 여전히 허용된 세션에서 서버의 해당 공개 키 줄을 개별적으로 제거해야 합니다.
필요한 키만 로드하고, 신뢰할 수 있는 머신에 대한 특별한 필요가 없는 한 에이전트 포워딩은 비활성 상태로 두십시오. 컴퓨터에서 악의적인 프로세스가 에이전트의 서명을 악용하려고 시도할 수 있습니다. 필요하지 않은 경우 Pageant에서 키를 제거하거나 종료하십시오. 패스프레이즈를 단축 아이콘이나 스크립트에 입력하지 마십시오.
서버를 약화시키지 않고 거부 진단하기
- Couldn’t load private key 또는 Unable to use key file : 파일의 경로, 형식 및 클라이언트 버전을 확인하십시오. PuTTYgen을 사용하여 키를 올바르게 가져오십시오; 확장자 변경만으로는 충분하지 않습니다.
- Server refused our key : 원격 계정, 개인 키와 공개 키의 일치, 전체 OpenSSH 줄, 허용된 경로 및 권한/소유자를 확인하십시오. 서버를 관리하는 경우, 시도할 때의 로그를 확인하십시오.
- Too many authentication failures : 에이전트가 너무 많은 키를 제안할 수 있습니다. 테스트를 위해 올바른 키를 선택하고 Pageant에서 나머지를 제거하십시오.
MaxAuthTries를 임의로 늘리지 마십시오. - PuTTY가 비밀번호를 요구합니다 : 키의 패스프레이즈와 Linux 비밀번호를 가리키고, 추가적으로 보여지는 다른 요소를 구분하십시오. 계정 비밀번호가 요구되면 이 테스트를 중단하십시오; 이는 키 인증의 증명이 아닙니다.
독립 콘솔 또는 기존 관리 세션에서, 관리자는 해당 배포에 현재 있는 로깅 유닛을 볼 수 있습니다. 다음 명령은 표시된 유닛의 마지막 50개 항목을 읽습니다; 존재하는 것을 사용하십시오, 자주 ssh는 Debian 또는 Ubuntu에서 사용되며, 다른 배포에서는 sshd 사용됩니다:
sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pager빈 로그는 어떤 시도도 발생하지 않았다는 것을 증명하지 않습니다: 배포가 다른 유닛이나 로그 목적지를 사용할 수 있습니다. 인프라의 세부 정보를 가린 후, 유용한 줄만 공유하십시오. 구성에서 Match 규칙을 사용하거나 사용자 지정 경로를 사용하는 경우, 관리자가 해당 계정의 설정을 확인하도록 하십시오. 이 문서는 SSH 구성을 수정하거나 보안 검사를 비활성화 하도록 요구하지 않습니다.
StrictModes, MFA 또는 호스트 검사를 비활성화하여 테스트를 진행하지 마십시오. root를 단축키로 허용하지 말고 SSH-1 또는 약한 서명을 재활성화하지 마십시오. 개인 키 또는 그 패스프레이즈가 분실되면, 비상 접근을 통해 새로운 쌍을 배포하고 이를 테스트한 후 오래된 허가를 제거하십시오. 최종 점검은 네 가지 요소에 관한 것입니다: Windows의 올바른 개인 파일, 대상 계정의 올바른 공개 키, 예상하는 권한 및 PuTTY의 Event Log에서 이 키가 수락되었는지 여부.
출처
