data_www@home.yjm.kr's password: 
sending incremental file list  여기 암호를 안묻게  key넣었는데 자꾸 물어본다. 검토해보자.. WSL이라 중간 포워딩때문은 아닌거지?
11s 동안 생각함

결론부터 말하면, WSL이라서 중간 포워딩 때문에 비밀번호를 묻는 경우는 보통 아니다.
대부분 원인은 아래 4개 중 하나다.

실제로 공개키 인증이 안 먹고 있다
다른 키를 보고 있다
원격 서버가 그 키를 인정하지 않는다
rsync/ssh가 기대한 SSH 설정파일을 안 읽고 있다

즉, 제 판단으로는 “WSL 중간 포워딩”보다 SSH 키 인증 설정 자체를 먼저 의심하는 게 맞다.

가장 먼저 확인할 것

아래처럼 같은 사용자, 같은 호스트로 직접 SSH 디버그를 봐야 한다.

ssh -vvv data_www@home.yjm.kr

여기서 핵심은 이런 줄이다.

정상 방향
Offering public key:
Server accepts key:
Authenticated with public key
비정상 방향
Offering public key:
Server refused our key

또는 아예

Trying private key: ...
no such identity
중요한 판단

rsync에서만 암호를 묻는 게 아니라
ssh data_www@home.yjm.kr 자체도 암호를 묻는다면,

rsync 문제 아님
WSL 포워딩 문제도 아님
SSH 키 인증 실패 문제다
1) 로컬 WSL에서 키가 실제로 있는지 확인
ls -la ~/.ssh

보통 있어야 하는 것:

id_rsa / id_rsa.pub
또는 id_ed25519 / id_ed25519.pub

권한도 중요하다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pub

주의:

chmod 600 ~/.ssh/id_* 는 *.pub까지 같이 잡히면 안 좋을 수 있다
정확히 하려면 예:
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
2) 에이전트에 키가 올라가 있는지 확인
ssh-add -l

아무것도 안 나오거나 오류면, 에이전트에 키가 안 올라간 상태일 수 있다.

추가:

ssh-add ~/.ssh/id_ed25519

또는

ssh-add ~/.ssh/id_rsa

다시 확인:

ssh-add -l

단, 에이전트에 없어도 SSH는 직접 키 파일을 읽어 접속할 수 있다.
그래서 이건 보조 확인이다.

3) 원격 서버에 공개키가 정확히 들어갔는지 확인

원격 서버 home.yjm.kr의 data_www 계정 홈에 있는:

~/.ssh/authorized_keys

여기에 WSL에서 쓰는 공개키 내용이 정확히 한 줄로 들어 있어야 한다.

WSL 쪽 공개키 확인:

cat ~/.ssh/id_ed25519.pub

원격 서버 쪽 확인:

cat ~/.ssh/authorized_keys

둘이 정확히 같은 키인지 봐야 한다.

4) 원격 서버 권한 문제

이건 매우 흔하다.
키가 맞아도 권한 틀리면 OpenSSH가 무시한다.

원격 서버에서 data_www 계정 기준으로:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

홈 디렉터리 권한도 너무 이상하면 문제날 수 있다.
최소한 다른 사람이 쓰기 가능하면 안 좋다.

확인:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

보통 대략 이런 느낌이어야 한다.

~ : 너무 느슨하지 않게
~/.ssh : 700
authorized_keys : 600
5) rsync가 다른 SSH 설정을 쓰는 경우

ssh는 되는데 rsync만 비밀번호를 물으면 이걸 의심해야 한다.

예:

rsync -av ./ data_www@home.yjm.kr:/some/path/

이때 내부적으로 기본 ssh를 쓰는데,
사용자가 기대한 ~/.ssh/config의 IdentityFile을 안 타는 경우가 있다.

강제로 지정해서 테스트:

rsync -av -e "ssh -i ~/.ssh/id_ed25519" ./ data_www@home.yjm.kr:/some/path/

이걸로 되면 원인은 거의 이쪽이다.

6) SSH config 확인

WSL의 ~/.ssh/config에 이렇게 되어 있으면 좋다.

Host home.yjm.kr
    HostName home.yjm.kr
    User data_www
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes 가 중요할 때가 있다.
이게 없으면 SSH가 여러 키를 마구 던지다가 실패하거나 다른 키를 먼저 써서 꼬일 수 있다.

테스트:

ssh -T home.yjm.kr

또는

ssh -vvv home.yjm.kr
7) 서버 쪽 sshd 설정 확인

원격 서버에서 아래도 봐야 한다.

sudo grep -E 'PubkeyAuthentication|PasswordAuthentication|AuthorizedKeysFile' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null

정상적으로는 대체로 이런 방향이어야 한다.

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

PasswordAuthentication yes 는 있어도 무방하지만,
키 인증이 실패하면 결국 비밀번호로 떨어진다.

즉, 비밀번호를 묻는다는 건 대개 pubkey가 실패했다는 뜻이다.

8) WSL 포워딩/중간 서버 때문인지

질문의 핵심에 답하면:

단순히 WSL에서 직접 home.yjm.kr로 접속하는 경우
중간 포워딩 때문일 가능성 낮다
정말 점프호스트를 거치는 경우

예:

ssh -J user@middlehost data_www@home.yjm.kr

또는 ProxyJump, ProxyCommand 사용

이 경우엔 중간 호스트 문제 가능성도 있다.
하지만 그래도 본질은 보통 최종 목적지 서버에서 공개키 인증이 안 된 것이다.

즉,

포워딩 때문에 비밀번호 묻는다기보다
최종 호스트가 키를 못 받아서 비밀번호로 내려가는 경우가 일반적이다
9) 가장 빠른 진단 순서

이 순서로 보면 된다.

A. SSH 자체 테스트
ssh -vvv data_www@home.yjm.kr
B. 실제 어떤 키를 쓰는지 강제
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -vvv data_www@home.yjm.kr
C. rsync도 같은 키로 강제
rsync -av -e "ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes" ./ data_www@home.yjm.kr:/tmp/
10) 냉정하게 짚으면

지금 상태에서 “키 넣었는데 왜 또 암호 묻지?”라고 하면,
대부분은 사실상 아래 둘 중 하나다.

넣은 키와 실제 접속에 사용되는 키가 다름
서버의 authorized_keys / 권한 / sshd 설정이 틀림

즉, “키를 넣었다”는 사실만으로는 부족하다.
실제로 그 키가 제시되고, 서버가 그 키를 받아들였는지를 봐야 한다.

바로 붙여서 결과 보면 좋은 명령

WSL에서:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -vvv data_www@home.yjm.kr

원격 서버에서:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
cat ~/.ssh/authorized_keys

이 2개 결과를 보면 원인을 거의 바로 좁힐 수 있다.