ssh-copy-id 원리와 사용법: SSH 키 인증으로 비밀번호 없이 서버 접속하기 (Claude Code 활용)

한 줄 요약
ssh-copy-id는 내 공개키를 서버의 authorized_keys에 등록해 주는 도구예요. 등록 후에는 비밀번호 대신 키로 접속하고, 덕분에 Claude Code도 같은 서버에 접속해 작업할 수 있어요.

---

1. 핵심 개념: SSH 키 인증과 ssh-copy-id

SSH 키 인증이란?

SSH 인증 방식을 정의한 표준 문서 RFC 4252는 공개키(publickey) 인증을 이렇게 설명해요.

• 사용자는 개인키로 만든 서명을 서버에 보내요.
• 서버는 두 가지를 확인해요. 그 키가 해당 사용자에게 허용된 키인지, 서명이 올바른지.
• 둘 다 맞으면 접속을 허용하고, 하나라도 틀리면 거부해요.

핵심은 "개인키를 가지고 있다는 사실" 자체가 인증이 된다는 점이에요.

참고로 RFC 4252는 publickey 방식을 모든 SSH 구현이 지원해야 하는 유일한 필수 인증 방식으로 정해두고 있어요.

 

ssh-copy-id란?

ssh-copy-id는 내 공개키를 원격 서버 사용자의 ~/.ssh/authorized_keys 파일 끝에 추가해 주는 스크립트예요. 파일이나 폴더가 없으면 새로 만들어요.

서버에 직접 들어가서 파일을 열고 키를 붙여 넣는 작업을, 명령어 한 줄로 대신해 주는 셈이에요.

 

용어 한 줄 풀이

용어	한 줄 설명
SSH	원격 서버에 암호화된 통로로 접속하는 프로토콜
개인키 (private key)	나만 보관하는 비밀 파일. 서명을 만들 때 써요
공개키 (public key)	개인키와 짝을 이루는 파일. 서버에 올려도 되는 쪽이에요
서명 (signature)	개인키로만 만들 수 있고, 공개키로 진위를 확인할 수 있는 값
authorized_keys	서버에 있는 "이 공개키는 접속 허용" 목록 파일
ssh-agent	개인키를 메모리에 올려두고 대신 서명해 주는 보조 프로그램

왜 중요한가요?

• 비밀번호를 보내지 않아요. 키 방식에서 서버로 가는 것은 서명이에요.
• 사람이 입력하는 단계가 없어요. 스크립트나 자동화 도구도 같은 방식으로 접속할 수 있어요.
• 키 단위로 회수할 수 있어요. authorized_keys에서 해당 줄만 지우면 그 키로는 더 이상 접속할 수 없어요.

---

2. 쉽게 이해하기: 인감도장 비유

SSH 키 인증은 인감도장과 구조가 비슷해요.

SSH	인감 비유
개인키	내 인감도장 (나만 보관)
공개키	등록해 둔 인감 (도장 모양)
authorized_keys	서버에 비치된 "등록 인감 대장"
서명	새 서류에 도장을 찍는 행위
ssh-copy-id	인감을 대장에 처음 등록하는 절차

서버는 도장 자체를 달라고 하지 않아요. 도장이 찍힌 서류만 보고, 대장에 등록된 인감과 같은지 대조해요.

서류는 접속할 때마다 새로 만들어져요. RFC 4252에 따르면 서명 대상 데이터에는 연결마다 정해지는 세션 식별자가 들어가요. 그래서 다른 연결에서 만든 서명을 그대로 가져다 쓸 수 없는 구조예요.

 

접속 흐름 한눈에 보기

1. 준비: ssh-copy-id로 공개키를 서버 authorized_keys에 등록해요.
2. 접속 요청: 클라이언트가 "이 공개키로 인증할게요"라고 알려요.
3. 서명 전송: 개인키로 세션 식별자 등이 포함된 데이터에 서명해서 보내요.
4. 검증: 서버가 허용된 키인지, 서명이 맞는지 확인해요.
5. 결과: 둘 다 맞으면 접속이 열려요.

 

실제 명령어로 보기

키가 없다면 먼저 만들어요.

ssh-keygen -t ed25519 -f ~/.ssh/{키이름} -C "{메모}"

옵션	의미
-t ed25519	만들 키의 종류
-f	저장할 파일 이름. 개인키 {키이름}과 공개키 {키이름}.pub 두 개가 생겨요
-C	키에 붙이는 메모. 나중에 서버에서 어떤 키인지 구분할 때 써요

그다음 공개키를 서버에 등록해요.

ssh-copy-id -i ~/.ssh/{키이름}.pub -p {포트} {사용자명}@{서버IP}

옵션	의미
-i	등록할 공개키 파일. 지정하면 이 파일의 키만 사용해요
-p	서버 SSH 포트. 기본값(22)이 아닐 때 지정해요
{사용자명}@{서버IP}	어느 서버의 어느 계정에 등록할지

아래는 제 맥북에서 실행한 실제 결과예요. 서버 주소와 계정 정보는 치환했어요.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/{맥사용자명}/.ssh/{키이름}.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
{사용자명}@{서버IP}'s password:

Number of key(s) added:        1

Now try logging into the machine, with: "ssh -i /Users/{맥사용자명}/.ssh/{키이름} -p {포트} '{사용자명}@{서버IP}'"
and check to make sure that only the key(s) you wanted were added.

출력	의미
Source of key(s) to be installed	등록할 공개키 파일을 확인했어요
attempting to log in with the new key(s)...	이미 등록된 키인지 먼저 키로 로그인을 시도해요. 중복 등록을 막는 단계예요
1 key(s) remain to be installed	아직 등록되지 않은 키가 1개 있어요. 지금 뜨는 비밀번호 입력은 등록을 위한 거예요
password:	비밀번호를 쓰는 마지막 순간이에요
Number of key(s) added: 1	등록이 끝났어요
Now try logging into the machine...	키로 접속해 보고, 원하는 키만 추가됐는지 확인하라는 안내예요

 

비밀번호는 키를 등록하는 이 한 번만 입력해요.

마지막으로 안내된 명령어로 접속해 봐요. 비밀번호 없이 들어가지면 성공이에요.

ssh -i ~/.ssh/{키이름} -p {포트} {사용자명}@{서버IP}

---

3. 핵심 정리

• SSH 키 인증은 개인키로 만든 서명을, 서버가 등록된 공개키로 확인하는 방식이에요. (RFC 4252)
• ssh-copy-id는 공개키를 서버의 ~/.ssh/authorized_keys에 추가해 주는 도구예요.
• 등록할 때 비밀번호를 한 번 입력하고, 이후에는 키로 접속해요.
• 개인키는 내 PC에만 두고, 서버에는 공개키만 올라가요.
• 입력 단계가 없어서 Claude Code 같은 도구도 같은 서버에 접속할 수 있어요.

---

4. 추가 정보

4-1. 제 활용법: Claude Code에게 서버 접속 맡기기

제가 이 작업을 한 이유는 하나예요. 평소 제가 직접 접속하던 서버에 Claude Code도 접속해서 로그 확인이나 설정 점검을 하게 하려는 것이에요.

제 환경에서는 Claude Code가 로컬 터미널에서 ssh 명령을 실행하는 방식으로 서버에 접속해요. 그래서 비밀번호 입력 없이 접속되는 상태를 먼저 만들어 둔 거예요.

 

1단계. ~/.ssh/config에 서버 별칭 등록

매번 IP, 포트, 계정을 적지 않도록 별칭을 만들어요.

Host {서버별칭}
    HostName {서버IP}
    Port {포트}
    User {사용자명}
    IdentityFile ~/.ssh/{키이름}
    IdentitiesOnly yes
    BatchMode yes

항목	의미 (ssh_config(5) 기준)
Host	내가 부를 별칭
HostName / Port / User	실제 접속할 서버 주소, 포트, 계정
IdentityFile	이 서버에 쓸 개인키 파일
IdentitiesOnly yes	지정한 키 파일만 사용해요. ssh-agent에 다른 키가 있어도 시도하지 않아요
BatchMode yes	비밀번호 입력, 호스트 키 확인 같은 입력 요청을 꺼요

이제 ssh {서버별칭} 한 줄로 접속돼요. 명령어를 붙이면 원격에서 그 명령만 실행하고 돌아와요.

ssh {서버별칭} "df -h"

BatchMode yes를 넣은 이유가 있어요. Claude Code가 실행한 명령에서 비밀번호 입력 요청이 뜰 때 어떻게 처리되는지는 공식 문서에서 명확히 확인되지 않음이에요. 그래서 저는 입력 요청 자체가 뜨지 않게 막고, 키 인증이 실패하면 바로 오류로 끝나게 해 뒀어요.

주의할 점도 있어요.

• 이 설정은 제가 직접 ssh {서버별칭}으로 접속할 때도 똑같이 적용돼요.
• 처음 접속하는 서버는 호스트 키 확인 단계가 막혀 접속이 실패해요. 서버마다 한 번은 직접 접속해서 known_hosts에 등록해 두세요.

 

2단계. CLAUDE.md에 접속 방법 적어두기

Claude Code가 참고하는 CLAUDE.md에는 별칭만 적어요.

## 서버 접속
- 운영 서버는 `ssh {서버별칭}`으로 접속해요. 접속 정보는 ~/.ssh/config에 있어요.
- 원격에서는 조회 명령 위주로 실행하고, 변경 작업은 먼저 계획을 보여주세요.

이렇게 하면 IP, 포트, 계정 정보가 CLAUDE.md 파일에 남지 않아요.

 

3단계. 권한 설정으로 안전장치 두기

Claude Code 공식 문서(Configure permissions) 기준으로 정리하면 이래요.

• 기본 모드에서 Bash 명령은 일부 읽기 전용 명령을 제외하고 실행 전에 승인을 요청해요.
• 승인할 때 "Yes, and don't ask again"을 고르면 규칙이 .claude/settings.local.json에 저장되고, 이후 세션에도 적용돼요.
• ask 규칙은 더 구체적인 allow 규칙이 있어도 매번 확인을 요청해요.

 

저는 원격 서버 명령은 매번 확인하도록 ask 규칙을 넣어 둬요.

{
  "permissions": {
    "ask": ["Bash(ssh *)", "Bash(scp *)"]
  }
}

모든 프로젝트에 적용하려면 사용자 설정 파일 ~/.claude/settings.json에 넣으면 돼요.

알아둘 한계도 있어요.

• 규칙은 명령 텍스트 기준으로 매칭돼요. 공식 문서도 /usr/bin/ssh처럼 다른 형태로 호출하는 경우까지 막는 보안 경계는 아니라고 설명해요.
• CLAUDE.md의 지시는 Claude가 무엇을 시도할지에 영향을 줄 뿐이에요. 실제 허용과 차단은 권한 규칙이 담당해요.

원격 서버는 되돌리기 어려운 곳이에요. 조회는 편하게, 변경은 확인을 거치게 두는 것이 제 기준이에요.

 

4-2. 비밀번호 인증 vs 키 인증

구분	비밀번호 인증	키 인증
서버로 보내는 것	비밀번호 (암호화된 통로 안에서 전송)	개인키로 만든 서명
접속할 때 입력	매번 필요	없음 (패스프레이즈 키는 ssh-agent 사용 시)
자동화 도구 사용	입력 단계 때문에 어려워요	가능해요
접근 회수	비밀번호 변경 (같은 계정 사용자 모두 영향)	authorized_keys에서 해당 키 줄만 삭제

 

4-3. 주의사항

• 개인키는 공유하지 않아요. 서버, 깃 저장소, 블로그 어디에도 올리지 않아요. 서버에는 .pub 파일만 등록해요.
• 내 PC의 파일 권한을 확인해요. OpenSSH는 다른 사용자가 접근할 수 있는 개인키 파일을 무시해요.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/{키이름}

• 서버 쪽 권한도 영향을 줘요. sshd 설정의 StrictModes가 켜져 있으면, 로그인 전에 사용자 홈과 ~/.ssh 파일의 권한과 소유자를 검사해요. 키를 등록했는데 접속이 안 되면 이 부분을 확인해요.
• 패스프레이즈를 걸었다면 ssh-add ~/.ssh/{키이름}으로 ssh-agent에 올려 두면 매번 입력하지 않아도 돼요.
• 쓰지 않는 키는 회수해요. 서버의 authorized_keys에서 해당 줄을 지우면 돼요. 키를 만들 때 -C 메모를 달아 두면 찾기 쉬워요.
• 비밀번호 로그인 끄기(PasswordAuthentication no)는 키 접속을 확인한 뒤에 검토해요. 먼저 끄면 서버에 들어가지 못할 수 있어요. 회사 서버라면 관리자와 협의해요.