답변이이 질문에 대한 답변 일 수 있는 매우 유사한 질문 이 있습니다. 불행히도 "문제가 내가 생각했던 것이 아니기 때문에 내가 묻는 질문에 대답 할 필요가 없습니다."의 경우입니다.

설정

서버 bastion.ec2 는 다음을 통해 내 워크 스테이션 에서 ssh 연결을 수락합니다.ssh -i mykey.pem myname@bastion.ec2
서버 service1.ec2는 SSH 연결을 허용 에만 bastion.ec2에서 경유를ssh -i sharedkey.pem shareduser@service1.ec2

요구 사항

두 키는 모두 내 워크 스테이션에만 있으므로 키를 복사하지 않으면 실제로 두 번째 명령을 수행 할 수 없습니다
보안상의 이유로 ssh 키를 bastion.ec2로 복사하는 대신 ssh-agent 전달을 사용하고 싶습니다.

해결책

이곳에 오셨습니다. 두 번째 연결을 위해 다른 키를 어떻게 전달할 수 있습니까?

shareduser가 mykey.pub를 가지고 있다면 다음과 같이 ~/.ssh/authorized_keys작동합니다.

ssh -i mykey.pem myname@bastion.ec2 ssh shareduser@service1.ec2

그러나 모든 사용자가 모든 서버에 자신의 공개 키를 넣기를 원하지는 않습니다.

ssh

— 브루노 브로 노 스키
소스

22

1 단계

현지 에이전트가 준비되었는지 확인하십시오

키 경로를 지정하거나 암호를 입력하지 않고 요새 서버 로 ssh 할 수 있다고해서 ssh 에이전트가 실행 중이고 키를 보유하고있는 것은 아닙니다. 일부 최신 OS (예 : OSX)가이를 처리합니다.

로컬 컴퓨터에서

$ ssh-add -L
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem

^{그림 1}

즉, 에이전트가 실행 중이며 키가 있습니다.

$ ssh-add -L
The agent has no identities.

^{그림 2}

즉, 에이전트에 키를 추가하지 않았습니다. 다음과 같이 수정하십시오.

ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem

^{그림 3}

2 단계

원격 에이전트가 준비되었는지 확인하십시오

요새 서버에 SSH를 연결하고 그림 1 과 그림 2 의 점검을 반복하십시오 . 그러나 얻을 가능성이 큰 오류는 다음과 같습니다.

$ ssh-add -L
Could not open a connection to your authentication agent.

^{그림 4}

이는 SSH 클라이언트가 인증 에이전트 연결을 전달하지 않음을 의미합니다.

서버 -A의 sshd 구성에서 허용하는 한, 이를 플래그로 강제 설정할 수 있습니다 ( 기본값 ).

$ ssh -A bastion.ec2

^{그림 5}

3 단계

올바른 키를 사용하고 있는지 확인하십시오

에이전트에 키를 추가 한 경우 에이전트가 전달되고 원격 에이전트가 로컬 키를 나열합니다. 연결되지 않은 이유는 두 가지뿐입니다. 올바른 키를 사용하지 않거나 올바른 사용자 이름을 사용하고 있지 않습니다.

공개 키를 개인 키로 출력하십시오.

$ cd
$ cd .ssh
$ ssh-keygen -y -f mykey.pem
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13
$ ssh-keygen -y -f sharedkey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13

^{그림 6}

이들은 당신이에서보고 된 것과 동일해야 ssh-add -L까지 ==끝 부분.

이제 연결에 실패한 상자에 들어가서 연결 $HOME/.ssh/authorized_keys하려는 사용자 의 파일 내용을 살펴보십시오 . 위 명령으로 출력 한 공개 키가 해당 파일에 한 줄씩 있어야합니다. sharedkey.pubBro 2 큐브가 이메일을 보낸 것이 옳다 는 것을 믿을 수 없습니다 . 검증! 이를 위해서는 해당 사용자로 SSH를 사용할 수있는 다른 사람이 사용자에게 authorized_keys 파일을 받거나 루트 액세스 권한을 얻어야합니다. 지금까지 와서 여전히 작동하지 않는다면 바로 가기를 넘어서는 것입니다.

4 단계

편하게 해

위의 단계가 완료 되었으면합니다. 이제이 워크 스테이션을 사용하는 한이 두통을 해결해 봅시다.

로컬 ssh-client 구성

Host *
    # A lot of people put an IdentityFile line in this Host * section.
    # Don't do that unless you will use only 1 key everywhere forever.
    #IdentityFile id_rsa

Host bastion.ec2
    # You want to make sure you always forward your agent to this host.
    # But don't forward to untrusted hosts. So don't put it in Host *
    ForwardAgent yes
    # Go a head and put the IP here in case DNS ever fails you.
    # Comment it out if you want. Having it recorded is a good backup.
    HostName 172.31.0.1
    # You don't want to create a proxy loop later, so be explicit here.
    ProxyCommand none
    # SSH should try using all keys in your .ssh folder, but if you
    # know you want this key, being explicit speeds authentication.
    IdentityFile ~/.ssh/mykey.pem

# Connect effortlessly by hostname or IP address
# This assumes that your internal DNS uses the fake TLD ec2
# This assumes that 172.31.0.0 is your C-Class subnet
Host *.ec2 172.31.*
    # This command says proxy all ssh connections through bastion as if
    # you had done an ssh -A
    ProxyCommand ssh -W %h:%p bastion.ec2
    ForwardAgent yes
    # These next lines are documentation you leave as a love letter to
    # your future self when all else fails or you have to help a
    # coworker and decide to look at your own config.
    # ssh-add ~/.ssh/*.pem
    # ssh -At bastion.ecs ssh admin@172.31.18.19

^{그림 7}

그림 7 에서 다른 것을 빼 내지 않으면 ProxyCommand&를 올바르게 사용해야 ForwardAgent합니다.

.bash_profile 자동 채우기

ssh-add컴퓨터에 로그인 할 때마다 수동으로 작업하지 않아도됩니다 . ~/.bash_profile로그인 할 때마다 실행되는 스크립트입니다 **. 그림 에서 선을 넣으십시오 . 거기에 3 과 항상 에이전트를 준비해야합니다.

** .bashrc새로운 각 [대화 형] 터미널에 대해 실행되는 것과 혼동하지 마십시오 . 모든 터미널 세션을 닫아도 에이전트는 계속 실행됩니다. 키를 새로 고침 할 필요가 없습니다

.bash_profile을 사용하는 대신

또한 OSX / macOS Launch Agent를 추가하는 요점을 만들었습니다 . ssh-agent부팅 시이 방법을 사용할 수 있습니다 . 설치가 매우 쉽습니다.

curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash

— 브루노 브로 노 스키
소스

2 단계 : 호스트가 허용하지 않으면 강제 ForwardAgent yes로 수행 할 수 없습니다 -A.

— dlamblin

@dlamblin에게 감사드립니다. 관련 정보와 sshd 문서에 대한 링크를 추가했습니다.

— Bruno Bronosky

1

이곳에 오셨습니다. 두 번째 연결을 위해 다른 키를 어떻게 전달할 수 있습니까?

키를 전달하지 않습니다. 에이전트를 전달하면 첫 번째 점프에서 인증에 사용하는 것보다 완전히 독립적 인 키를 가질 수 있습니다. 를 사용하여 상담원의 키를 확인하십시오 ssh-add -L.

그러나 더 나은 방법은 연결을 통해 실행하면 ProxyCommand ssh -W %h:%p myname@bastion.ec2에이전트, 힙 또는 명령 행 옵션을 전달할 필요가없고 직접 호스트에서 인증 할 필요가 없다는 것입니다.

구성에 간단히 넣을 수 있습니다 (참조 man ssh_config).

— 자쿠지
소스

1

운 좋게도 나는 당신이 여기서 말하는 것을 실제로 알고 있지만 일반 사용자는 그렇지 않습니다. "키가 아닌 에이전트를 전달합니다"라는 의미로 의미론을 주장합니다. 당신은 나에게 이것을 해결할 수있을만큼 충분히 주었다. 그래서 나는 내 자신을 추가하기 전에 당신의 대답을 바로 잡을 기회를주고 싶다. 힌트 : ssh-add mykey.pem sharedkey.pem다음 확인을 함께 ssh-add -L다음ssh -At myname@bastion.ec2 ssh shareduser@service1.ec2

— 브루노 Bronosky

다른 사용자 이름과 다른 키를 사용하는 SSH 에이전트 전달

설정