에이전트 포워딩 (r1)

SSH 에이전트는 SSH 클라이언트가 원격 서버에 인증할 때 필요한 비밀키를 안전하게 관리하고 사용하는 백그라운드 프로그램이다. 사용자가 ssh-agent를 실행하면, 에이전트는 메모리 내에 사용자의 암호화된 비밀키를 로드하여 보관한다. 이후 SSH 클라이언트가 연결을 시도할 때마다, 에이전트는 클라이언트의 요청을 받아 저장된 키를 사용하여 인증 서명을 생성하고 제공한다. 이 과정에서 비밀키 자체는 에이전트의 메모리 공간을 벗어나지 않으므로, 디스크에 평문으로 저장되는 위험을 피할 수 있다.

에이전트의 핵심 역할은 사용자가 한 번만 패스프레이즈를 입력하게 하는 것이다. 키가 패스프레이즈로 보호되어 있을 경우, ssh-agent를 시작하고 키를 추가할 때 단 한 번만 암호를 입력하면 된다. 그 후에는 에이전트가 모든 인증 요청을 대신 처리하므로, 여러 서버에 접속하거나 동일한 서버에 반복적으로 접속할 때마다 패스프레이즈를 다시 입력할 필요가 없어진다. 이는 특히 자동화된 스크립트나 점프 호스트를 경유하는 다단계 접속에서 작업 효율성을 크게 향상시킨다.

에이전트는 일반적으로 유닉스 도메인 소켓이나 윈도우의 네임드 파이프 같은 보안 통신 채널을 통해 클라이언트와 통신한다. 이 소켓의 경로는 SSH_AUTH_SOCK이라는 환경 변수에 저장되어, SSH 클라이언트가 에이전트를 찾고 요청을 보낼 수 있도록 한다. 에이전트 포워딩이 활성화되면, 이 통신 채널이 SSH 연결을 통해 원격 서버로 안전하게 전달(포워딩)되는 메커니즘이 작동하게 된다.

SSH 에이전트는 사용자의 개인 키를 메모리에 보관하고, SSH 클라이언트가 연결을 요청할 때 필요한 서명 작업을 대신 수행하는 백그라운드 프로세스이다. 에이전트 포워딩이 활성화되면, 클라이언트 머신의 SSH 에이전트는 로컬 유닉스 도메인 소켓 (예: /tmp/ssh-XXXXXXX/agent.12345)을 통해 통신한다.

사용자가 중간 서버(예: 점프 호스트)에 SSH로 접속할 때, 클라이언트는 이 로컬 소켓에 대한 접근 권한을 암호화된 SSH 채널을 통해 원격 서버로 전달(포워딩)한다. 이 과정에서 실제 개인 키 데이터 자체는 전송되지 않는다. 대신, 원격 서버에는 클라이언트 측 소켓을 가리키는 새로운 소켓(예: $SSH_AUTH_SOCK 환경 변수가 가리키는 경로)이 생성된다.

원격 서버에서 사용자가 또 다른 서버로의 SSH 연결을 시도하면, 로컬 SSH 클라이언트는 포워딩된 소켓 경로를 찾아 인증 요청을 보낸다. 이 요청은 암호화된 채널을 통해 클라이언트 머신의 원본 SSH 에이전트로 전달되고, 에이전트가 개인 키로 서명을 생성하여 다시 응답한다. 이 서명만이 네트워크를 통해 전송되어 최종 목표 서버의 인증을 완료한다.

이 메커니즘의 핵심은 키 자체의 이동이 아닌, 인증 요청과 서명 결과만이 안전한 터널을 통해 중계된다는 점이다. 그러나 이는 원격 서버의 사용자 프로세스가 포워딩된 소켓에 접근하여 인증 요청을 보낼 수 있게 만든다는 보안적 함의를 가진다[1].

클라이언트 측에서 에이전트 포워딩을 활성화하는 주요 방법은 사용자의 ~/.ssh/config 파일을 수정하는 것이다. 이 파일에 ForwardAgent yes 지시어를 특정 호스트나 호스트 그룹에 대해 설정하면, 해당 연결 시 에이전트 포워딩이 자동으로 사용된다. 설정 파일을 사용하면 매번 명령어에 옵션을 추가할 필요가 없어 편리하다.

구체적인 설정 예시는 다음과 같다.

위 예시는 bastion.example.com 호스트로 연결할 때마다 에이전트 포워딩이 자동으로 수행되도록 한다. 와일드카드(*)를 사용하여 여러 호스트에 대해 일괄 설정할 수도 있다. 예를 들어, Host *.internal.net과 같이 설정하면 해당 도메인의 모든 서버에 대해 정책이 적용된다.

ssh_config 파일이 존재하지 않으면 새로 생성할 수 있다. 설정 변경 후에는 별도의 재시작이 필요하지 않으며, 다음 SSH 연결부터 적용된다. 전역 설정 파일인 /etc/ssh/ssh_config를 수정하여 시스템 전체에 기본값을 설정할 수도 있으나, 일반적으로는 사용자별 설정 파일을 편집하는 것이 권장된다.

서버 측에서 에이전트 포워딩을 허용하려면 SSH 데몬(sshd)의 설정 파일을 수정해야 합니다. 일반적으로 이 파일은 /etc/ssh/sshd_config 경로에 위치합니다. 설정을 변경한 후에는 SSH 데몬을 재시작하여 변경 사항을 적용해야 합니다.

주요 설정 옵션은 AllowAgentForwarding입니다. 이 지시어의 기본값은 대부분의 배포판에서 yes로 설정되어 있어, 클라이언트가 요청할 경우 에이전트 포워딩을 허용합니다. 그러나 보안 정책에 따라 이를 명시적으로 비활성화(no)할 수 있습니다. 설정 예시는 다음과 같습니다.

```

# 에이전트 포워딩 허용 (기본값)

AllowAgentForwarding yes

# 에이전트 포워딩 금지

AllowAgentForwarding no

```

보다 세밀한 제어가 필요한 경우, Match 블록을 사용하여 특정 사용자, 그룹, IP 주소 또는 호스트명에 대해서만 에이전트 포워딩을 허용하거나 차단할 수 있습니다. 예를 들어, 관리자 그룹만 에이전트 포워딩을 사용하도록 설정할 수 있습니다.

```

Match Group administrators

AllowAgentForwarding yes

Match Group developers

AllowAgentForwarding no

```

서버 측 설정은 클라이언트의 요청을 수용할지 여부를 결정하는 최종 관문 역할을 합니다. 클라이언트에서 -A 옵션을 사용하거나 ssh_config에 ForwardAgent yes를 설정하더라도, 서버의 sshd_config에서 AllowAgentForwarding이 no로 설정되어 있으면 에이전트 포워딩은 작동하지 않습니다. 설정 변경 후에는 sudo systemctl restart sshd 또는 sudo service ssh restart와 같은 명령어로 SSH 데몬을 재시작해야 적용됩니다[2].

에이전트 포워딩은 SSH 클라이언트를 실행할 때 -A 옵션을 사용하여 일시적으로 활성화할 수 있습니다. 이 방법은 전역 설정을 변경하지 않고 현재 세션에 대해서만 포워딩 기능을 적용할 때 유용합니다.

기본 사용법은 ssh -A 사용자명@호스트명입니다. 예를 들어, alice 사용자로 server.example.com에 접속하며 에이전트 포워딩을 사용하려면 ssh -A alice@server.example.com 명령어를 실행합니다. 이 명령은 로컬 머신의 SSH 에이전트가 관리하는 인증 키를 원격 서버로 전달합니다. 이후 원격 서버에서 다른 서버로의 SSH 연결 시, 로컬의 프라이빗 키 없이도 인증이 가능해집니다.

-A 옵션은 ssh_config 파일에 ForwardAgent yes를 설정하는 것과 동일한 효과를 가지지만, 해당 명령어 세션에만 한정됩니다. 반대로, 설정 파일에서 포워딩이 활성화되어 있더라도 -a 옵션을 사용하면 일시적으로 비활성화할 수 있습니다. 이는 특정 연결에 대해서만 보안을 강화하고자 할 때 활용됩니다.

이러한 명령어 옵션은 테스트 목적이거나, 특정 작업을 위해 일회성으로 에이전트 포워딩이 필요할 때 편리합니다. 그러나 보안 위험을 고려하여, 불필요한 경우나 신뢰할 수 없는 호스트에 연결할 때는 사용을 자제하는 것이 좋습니다.

점프 호스트는 내부 네트워크에 대한 게이트웨이 역할을 하는 특수한 서버이다. 이 호스트는 외부 인터넷과 내부 보호망 사이에 위치하여, 모든 SSH 접속이 반드시 이 서버를 거치도록 강제한다. 이를 통해 내부 서버들을 직접 외부에 노출시키지 않고도 안전한 원격 접근을 제공한다.

에이전트 포워딩은 점프 호스트를 통한 작업 흐름을 크게 단순화한다. 사용자는 자신의 로컬 머신에 저장된 SSH 개인 키를 점프 호스트에 복사하거나 업로드할 필요가 없다. 대신, 로컬 SSH 에이전트가 관리하는 키 인증 정보가 점프 호스트로 안전하게 전달된다. 점프 호스트는 이 인증 정보를 사용하여 최종 목표 내부 서버에 대한 연결을 성립한다. 이 과정에서 개인 키 자체는 로컬 시스템을 떠나지 않는다.

이 방식의 주요 이점은 편의성과 보안 관리의 용이성에 있다. 시스템 관리자는 개별 내부 서버에 대한 접근 제어를 점프 호스트 하나에 집중할 수 있다. 사용자 키의 배포나 폐기가 점프 호스트 수준에서 관리되므로, 내부 서버마다 키를 일일이 설정할 필요가 줄어든다. 또한, 모든 접속 로그가 점프 호스트에 집중되어 감사(audit)가 용이해진다.

그러나 점프 호스트 자체가 강력하게 보호되어야 하며, 여기에 에이전트 포워딩을 사용할 때는 관련된 보안 고려사항 및 위험을 반드시 이해하고 적용해야 한다. 점프 호스트가 침해당할 경우, 공격자는 포워딩된 에이전트 소켓을 악용하여 내부 네트워크의 다른 서버들로의 접근 권한을 획득할 수 있다.

다중 서버 환경에서 에이전트 포워딩은 관리 효율성과 작업 편의성을 크게 향상시킨다. 시스템 관리자나 개발자가 여러 대의 서버에 순차적으로 접속해야 하는 경우, 각 서버마다 비밀번호를 입력하거나 개별 SSH 키를 복사하여 관리할 필요가 없어진다. 사용자는 최초의 클라이언트 시스템에서만 한 번 SSH 에이전트에 비밀키를 등록하면, 에이전트 포워딩이 설정된 경로를 통해 연결되는 모든 서버에서 동일한 키를 사용한 인증이 가능해진다.

예를 들어, 웹 애플리케이션 서버, 데이터베이스 서버, 로그 서버로 구성된 환경에서 작업할 때, 사용자는 점프 호스트를 통해 웹 서버에 접속한 후, 다시 웹 서버에서 데이터베이스 서버로 SSH 연결을 시도할 수 있다. 이때 에이전트 포워딩이 활성화되어 있다면, 데이터베이스 서버는 최종 사용자의 원래 클라이언트에 위치한 SSH 에이전트에게 인증 요청을 포워딩하여 접속을 허가한다. 이 과정은 사용자에게 투명하게 이루어지며, 중간 서버에는 비밀키가 저장되지 않는다.

이러한 구조는 특히 자동화 스크립트나 CI/CD 파이프라인에서 유용하다. 스크립트가 여러 서버에 배포를 수행해야 할 때, 에이전트 포워딩을 활용하면 복잡한 키 배포 절차 없이도 안전하게 인증 체인을 구축할 수 있다. 그러나 이 편의성은 신뢰할 수 있는 호스트로의 포워딩을 제한하지 않으면 보안 위험으로 이어질 수 있으므로, ssh_config의 ForwardAgent 지시어를 신중하게 설정하거나 -A 옵션을 선택적으로 사용해야 한다.

중간 서버에 로그인한 공격자는 SSH 에이전트가 제공하는 소켓을 통해 에이전트에 접근할 수 있습니다. 이 소켓은 일반적으로 사용자의 홈 디렉터리 아래에 위치하며, 에이전트 포워딩이 활성화되면 원격 서버로 전달됩니다. 공격자는 이 소켓 파일을 사용하여 에이전트에 저장된 개인 키를 직접 사용할 수는 없지만, 에이전트에게 서명 요청을 보내 인증을 수행할 수 있습니다[4]. 이는 공격자가 사용자의 키로 다른 시스템에 접근하는 것을 가능하게 합니다.

주요 위험은 권한 상승에 있습니다. 공격자가 침투한 중간 서버가 낮은 권한을 가진 계정이더라도, 포워딩된 에이전트를 통해 사용자가 접근 권한을 가진 모든 서버(예: 프로덕션 서버, 데이터베이스 서버)로의 인증이 가능해집니다. 이는 공격자의 영향 범위를 극적으로 확장시킵니다. 또한, 만약 루트 권한을 획득한 공격자가 소켓에 접근하면, 시스템의 모든 사용자 세션에 대해 에이전트 포워딩을 하이재킹할 수 있는 가능성이 있습니다.

에이전트 포워딩의 위험을 완화하기 위해서는 신뢰할 수 있는 호스트로의 연결을 엄격히 제한해야 합니다. 신뢰할 수 없는 네트워크나 관리 상태가 불분명한 서버에서는 에이전트 포워딩을 사용하지 않는 것이 기본 원칙입니다. 또한, ssh-agent에 등록하는 키를 특정 목적에 맞춰 제한하거나, ProxyJump와 같은 대안을 고려하는 것이 보안 강화에 도움이 됩니다.

에이전트 포워딩을 활성화하면, 클라이언트의 SSH 에이전트 소켓이 원격 서버로 전달됩니다. 이는 원격 서버가 로컬의 개인 키를 사용하여 인증할 수 있게 하지만, 동시에 신뢰할 수 있는 호스트를 엄격하게 관리해야 할 필요성을 높입니다.

에이전트 포워딩이 활성화된 상태에서 로그인한 원격 서버는, 사용자가 이후 접속하는 모든 호스트에 대해 로컬의 SSH 키를 사용할 수 있는 권한을 간접적으로 획득합니다. 따라서 악의적인 사용자나 컴프로마이즈된 서버는 이 권한을 악용하여 다른 시스템에 무단으로 접근할 수 있습니다. 에이전트 포워딩의 위험은 단일 호스트에 국한되지 않고, 그 호스트에서 다시 접속 가능한 모든 호스트로 연쇄적으로 확대될 수 있습니다.

이러한 위험을 완화하기 위해 신뢰할 수 있는 호스트 관리는 몇 가지 원칙을 따릅니다. 가장 중요한 것은 에이전트 포워딩을 필요한 최소한의 호스트에만 제한적으로 허용하는 것입니다. 사용자는 ssh -A 옵션을 신중하게 사용하거나, ~/.ssh/config 파일에서 특정 호스트에 대해서만 ForwardAgent yes 지시어를 설정해야 합니다. 시스템 관리자는 서버 측 /etc/ssh/sshd_config에서 AllowAgentForwarding 설정을 통해 전역적 허용 여부를 통제할 수 있습니다.

또한, 점프 호스트나 베스천 호스트와 같이 에이전트 포워딩이 필수적인 중간 서버의 보안을 극대화해야 합니다. 이 서버들은 최소 권한 원칙에 따라 강화되고, 정기적인 패치와 모니터링이 이루어져야 합니다. 궁극적으로 에이전트 포워딩을 사용하는 환경에서는 모든 관련 호스트가 동일한 높은 수준의 신뢰를 가진다고 가정하고 관리해야 합니다.

ProxyJump는 OpenSSH 7.3 버전부터 도입된 기능으로, 에이전트 포워딩을 사용하지 않고도 안전하게 중간 서버(점프 호스트)를 경유하여 목표 서버에 접속하는 방법을 제공한다. 이 기능은 -J 명령행 옵션이나 ~/.ssh/config 파일의 ProxyJump 지시어를 통해 사용한다. 동작 원리상, 클라이언트는 먼저 점프 호스트에 연결한 후, 해당 연결을 통해 목표 호스트로의 새로운 연결을 터널링한다. 이 과정에서 SSH 에이전트의 프라이빗 키가 점프 호스트로 전달되지 않기 때문에 보안성이 향상된다.

ProxyJump는 ~/.ssh/config 파일에 설정하여 편리하게 사용할 수 있다. 다음은 일반적인 구성 예시이다.

위와 같이 설정하면 ssh internal-server 명령 하나로 자동으로 점프 호스트를 경유하여 내부 서버에 접속한다. 명령행에서는 ssh -J jumpuser@bastion.example.com appuser@10.0.1.5 형식으로 직접 사용할 수도 있다.

ProxyJump는 에이전트 포워딩에 비해 몇 가지 명확한 보안적 이점을 가진다. 가장 큰 차이는 프라이빗 키가 네트워크를 통해 전송되거나 중간 호스트에 소켓이 노출되지 않는다는 점이다. 클라이언트는 로컬 SSH 에이전트를 사용하여 점프 호스트에 인증하고, 점프 호스트에서는 목표 서버로의 연결만을 중계한다. 따라서 점프 호스트가 해킹당하더라도 에이전트의 키가 유출되거나 다른 서버로의 인증을 악용당할 위험이 현저히 낮아진다. 이는 다중 인증 환경에서도 보안 정책을 더 쉽게 적용할 수 있게 한다.

SSH 에이전트 포워딩을 사용할 때는 ssh -A 옵션을 통해 전체 에이전트에 로드된 모든 개인 키가 원격 서버에 노출될 수 있다는 점에 주의해야 한다. 이는 보안 위험을 증가시킨다. 특히, 원격 서버가 손상된 경우 공격자는 포워딩된 에이전트 소켓을 통해 다른 서버로의 인증을 시도할 수 있다.

이러한 위험을 완화하기 위해 제한된 키를 사용하는 전략이 권장된다. 이는 에이전트 포워딩에만 사용될 특정 SSH 키 쌍을 생성하고, 해당 공개 키의 사용을 특정 명령이나 특정 호스트에 대한 접속으로 제한하는 것을 의미한다. ssh-keygen 명령어로 새로운 키 쌍을 생성한 후, 원격 서버의 ~/.ssh/authorized_keys 파일에 해당 공개 키를 등록할 때 command나 from 같은 옵션을 사용하여 권한을 제한할 수 있다.

예를 들어, authorized_keys 파일에 아래와 같은 형식으로 키를 등록하면, 해당 키로 접속했을 때 특정 스크립트만 실행되도록 강제하거나 특정 IP에서의 접속만 허용할 수 있다.

```

command="/usr/local/bin/backup-script.sh",from="192.168.1.100" ssh-rsa AAAAB3NzaC1yc2E...

```

에이전트 포워딩을 위해 별도의 제한된 키를 사용하는 일반적인 절차는 다음과 같다.

1. 전용 키 쌍 생성: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_forwarding

2. 공개 키를 점프 호스트나 관리 대상 서버에 등록할 때 사용 제한 옵션을 적용한다.

3. 로컬 에이전트에는 이 제한된 키만 추가한다: ssh-add ~/.ssh/id_ed25519_forwarding

4. 기존의 주요 키(예: 프로덕션 서버 접근용)는 에이전트에 추가하지 않거나 별도로 관리한다.

이 방식을 통해 에이전트 포워딩이 활성화된 상태에서도, 만약 원격 서버가 탈취되더라도 공격자가 할 수 있는 행동이 명시적으로 제한된 키의 범위 내로 한정된다. 따라서 최소 권한의 원칙을 준수하며 보안 위험을 상당히 줄일 수 있다.

에이전트 포워딩 시간 제한은 SSH 에이전트의 인증 소켓이 원격 서버에 노출되는 기간을 제한하여 보안 위험을 완화하는 방법이다. 기본적으로 에이전트 포워딩이 활성화되면, 사용자가 로그아웃하거나 연결을 종료할 때까지 원격 서버의 프로세스가 해당 소켓에 접근할 수 있다. 이는 장시간 연결이 유지되는 세션에서 특히 위험할 수 있다.

이 시간 제한을 구현하기 위해 ssh-agent의 -t 옵션을 사용할 수 있다. 이 옵션은 키를 에이전트에 추가할 때 해당 키의 최대 수명(라이프타임)을 초 단위로 설정한다. 예를 들어, ssh-add -t 3600 ~/.ssh/id_rsa 명령어는 비밀키를 에이전트에 추가하되, 3600초(1시간) 후에는 자동으로 만료되도록 한다. 이 시간이 지나면 원격 서버에서 더 이상 해당 키를 사용한 인증이 불가능해진다.

이러한 시간 제한은 점프 호스트를 통해 다단계로 서버에 접근하는 복잡한 환경에서 유용하다. 각 단계의 연결에 대해 키 사용 시간을 제한함으로써, 만약 중간 서버가 손상되더라도 공격자가 에이전트 소켓을 무제한으로 악용하는 것을 방지할 수 있다. 그러나 이 방법은 장기 실행 작업에는 부적합할 수 있으며, 주기적으로 재인증이 필요해질 수 있다는 단점이 있다.

에이전트 포워딩 실패는 주로 SSH 에이전트가 제대로 실행되지 않았거나, SSH 클라이언트와 서버 간의 설정 불일치, 파일 시스템 권한 문제에서 비롯된다.

가장 흔한 원인은 로컬 머신에서 SSH 에이전트가 시작되지 않은 상태이다. ssh-add -L 명령어를 실행했을 때 "Could not open a connection to your authentication agent."라는 메시지가 나타나면, 에이전트가 실행 중이지 않다는 의미이다. 이 경우 eval $(ssh-agent) 명령어로 에이전트를 시작하고 ssh-add 명령어로 개인 키를 등록해야 한다. 또한, 클라이언트 측 ~/.ssh/config 파일에서 해당 호스트에 대한 ForwardAgent yes 설정이 누락되었거나, 서버 측 /etc/ssh/sshd_config에서 AllowAgentForwarding 옵션이 no로 설정되어 있을 수 있다.

파일 및 소켓 권한 문제도 주요 원인이다. 로컬의 에이전트 통신 소켓(일반적으로 $SSH_AUTH_SOCK 환경 변수가 가리키는 경로)이나 원격 서버의 사용자 홈 디렉토리, ~/.ssh 디렉토리의 권한이 너무 개방적이면(예: 그룹이나 다른 사용자에게 쓰기 권한이 부여됨) SSH 데몬이 보안상 이유로 에이전트 포워딩을 거부한다. 다음 표는 일반적인 권한 오류와 해결 방안을 정리한 것이다.

환경 변수 전달 실패도 원인이 될 수 있다. ssh 명령이 원격 세션에 SSH_AUTH_SOCK 환경 변수를 올바르게 전달하지 못하는 경우이다. 이는 ssh 클라이언트가 로그인 셸을 통해 연결하지 않거나, 원격 서버의 셸 설정 파일(예: ~/.bashrc, ~/.profile)에서 해당 변수를 덮어쓰는 경우 발생할 수 있다. ssh -v 또는 ssh -vvv 옵션을 사용하여 디버그 모드로 연결을 시도하면, "debug1: Offering public key", "debug1: Server accepts key" 또는 "authentication agent connection failed"와 같은 메시지를 통해 정확한 실패 지점을 파악할 수 있다.

에이전트 포워딩 문제를 진단할 때는 ssh 명령어의 -v (verbose) 옵션을 사용하는 것이 기본적인 방법이다. -v 옵션을 하나에서 세 개까지 추가하여(-vvv) 상세한 디버그 정보를 확인할 수 있다. 출력 로그에서 debug1: Offering public key, debug1: Server accepts key, debug1: Authentication succeeded와 같은 줄을 찾아 인증 과정의 성공 여부를 파악한다. 특히 debug1: Requesting authentication agent forwarding. 메시지가 나타나는지 확인하여 에이전트 포워딩 요청이 정상적으로 전송되었는지 검토한다.

에이전트 소켓의 존재와 접근 권한을 확인하는 명령어도 필수적이다. echo $SSH_AUTH_SOCK 명령어를 실행하면 클라이언트 측에서 에이전트 소켓의 경로를 확인할 수 있다. 서버 측에서는 ls -la $SSH_AUTH_SOCK 명령어로 소켓 파일의 소유자와 권한을 점검해야 한다. 소켓 파일이 존재하지 않거나, 사용자 권한으로 읽고 쓸 수 없는 경우 에이전트 포워딩은 실패한다.

에이전트 자체의 상태를 확인하려면 ssh-add -l 명령어로 메모리에 로드된 키의 지문 목록을 조회한다. ssh -T git@github.com과 같은 명령어로 특정 호스트에 대한 인증이 가능한지 직접 테스트해볼 수도 있다. 모든 디버깅 시도 후에도 문제가 지속되면, 클라이언트의 ~/.ssh/config 파일과 서버의 /etc/ssh/sshd_config 파일에서 ForwardAgent 설정이 올바르게 구성되었는지 다시 한번 검토해야 한다.