내 ssh ID 파일을 ~ / .ssh / 폴더에 넣었습니다. 아마 거기에 약 30 파일이 있습니다.
서버에 연결할 때 사용할 ID 파일을 다음과 같이 지정합니다.
ssh -i ~ / .ssh / client1-identity client1@10.1.1.10
그러나 신원 파일을 지정하지 않으면 다음과 같이 사용하십시오.
ssh user123@example.com
오류가 발생합니다
user123에 대해 너무 많은 인증 실패
ID 파일을 지정하지 않고 ssh가 ID 파일을 찾을 수 있으면 모든 파일을 시도하기 때문에 이해합니다.
또한 ~/.ssh/config파일을 편집하고 다음과 같이 지정할 수 있음을 이해합니다 .
호스트 example.com 우선 인증 키보드 대화 형, 비밀번호
해당 연결이 알려진 ID 파일을 시도하지 못하도록합니다.
따라서 신원 파일을 ~/.ssh/디렉토리 외부로 옮길 수 있거나 구성 파일에서 신원 파일 인증을 사용하지 않으려는 각 호스트를 지정할 수 있지만 SSH가 기본 검색을하지 않도록 구입하도록 지시 할 수있는 방법이 있습니까? 신원 파일? 아니면 검색 할 항목을 지정 하시겠습니까?
답변
IdentitiesOnly=yes옵션을 함께 사용할 수 있습니다 IdentityFile( ssh_config 매뉴얼 페이지 참조 ). 이렇게하면 어떤 파일을 찾아야하는지 지정할 수 있습니다.
이 예에서 ssh는 ssh_config 파일에 제공된 ID + 명령 줄에 나열된 4 개의 ID 만 찾습니다 (에이전트가 제공 한 ID는 무시 됨).
ssh -o IdentitiesOnly=yes \
-o IdentityFile=id1.key \
-o IdentityFile=id2.key \
-i id3.key \
-i id4.key \
user123@example.com
양식 -i과 -o IdentityFile=상호 교환이 가능합니다.
답변
user76528의 짧은 대답은 정확하지만 방금이 문제가 있었고 일부 정교화가 유용 할 것이라고 생각했습니다. “ssh가 ID 파일 구성 옵션을 무시하는 이유”에 대해 궁금한 경우이 솔루션에 관심이 있습니까?
첫째, ssh_config의 다른 모든 옵션과 달리 ssh는 IdentityFile찾은 첫 번째 옵션을 사용하지 않습니다 . 대신이 IdentityFile옵션은 해당 파일을 사용 된 ID 목록에 추가합니다. 여러 IdentityFile옵션을 쌓을 수 있으며 ssh 클라이언트는 서버가 옵션을 수락하거나 연결을 거부 할 때까지 모든 옵션을 시도합니다.
둘째, ssh-agent를 사용하는 경우 ssh는 ssh_config의 IdentityFile (또는 -i) 옵션에서 키를 지정하지 않은 경우에도 에이전트의 키 사용을 자동으로 시도합니다. 이것이 Too many authentication failures for user오류 가 발생할 수있는 일반적인 이유 입니다. 은 Using IdentitiesOnly yes옵션은이 동작을 비활성화합니다.
여러 시스템에 여러 사용자로 ssh하는 경우 IdentitiesOnly yesssh_config의 전역 섹션을 각각 IdentityFile적절한 호스트 하위 섹션에 배치 하는 것이 좋습니다 .
답변
나는 일반적으로 그렇게합니다 :
$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com
옵션은 다음과 같습니다.
-o IdentitiesOnly=yes-SSH를 통해 CLI를 통해 제공되고$HOME/.sshssh-agent 는 제공하지 않는 키만 사용하도록 SSH에 지시합니다.-F /dev/null-사용을 비활성화합니다$HOME/.ssh/config-i ~/path/to/some_id_rsa-연결에 명시 적으로 사용하려는 키
예
$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec 8 19:03:24 2015 from 153.65.219.15
someserver$
위의 출력 에서 CLI를 통해 개인 키만 ssh식별 my_id_rsa했으며이 키를 사용하여 일부 서버에 연결합니다.
특히이 섹션은 다음과 같습니다.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
과:
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
답변
키가 많은 경우 “너무 많은 인증 실패”오류가 발생합니다. 비밀번호가 있고 단순히 비밀번호를 사용하여 로그인하려면 다음과 같이하십시오.
암호 인증 만 사용하고 공개 키를 사용하지 않고 다소 잘못된 “키보드 대화 형”(암호를 포함하는 슈퍼 세트)을 사용하지 않으려면 명령 행에서이를 수행 할 수 있습니다.
ssh -o PreferredAuthentications=password user@example.com
답변
IdentityFile을 사용하지만 암호 문구를 피하기 위해 ssh-agent를 계속 사용하십시오.
허용되는 사용 솔루션은 IdentitiesOnly yesssh-agent를 이용할 수 없으므로 키를로드 할 때 암호문에 대한 프롬프트가 반복적으로 나타납니다.
ssh-agent‘너무 많은 인증 실패’오류 를 계속 사용 하고 피하려면 다음을 시도하십시오.
-
키를 자동으로로드하는 대화식 콘솔 시작 스크립트를 제거하십시오
ssh-agent. -
AddKeysToAgent yes클라이언트의 ssh 구성에 추가 하십시오. 그러면 처음 연결할 때 암호 문구를 입력하라는 메시지가 표시되지만 에이전트에 키를 추가하십시오. -
사용
ssh-add -D당신이 ‘너무 많은 인증’오류를 얻을 때. 이것은 단순히 ssh-agent 캐시를 ‘재설정'(삭제)합니다. 그런 다음 동일한 세션 내에서 다시 연결을 시도하십시오. 암호를 입력하라는 메시지가 표시되면 수락하면 에이전트에 추가됩니다. 에이전트에는 하나의 키만 있기 때문에 연결할 수 있습니다. 그런 다음 ssh-agent는 동일한 세션 중에 향후 연결을 위해 여전히 프롬프트를 표시하지 않습니다.Host ex example.com User joe HostName example.com PreferredAuthentications publickey,password IdentityFile /path/to/id_rsa AddKeysToAgent yes
답변
ssh 클라이언트와는 환경 변수에 ssh-agent의해 클라이언트에 이름이 지정된 Unix 도메인 소켓을 통해 통신하고 SSH_AUTH_SOCK있습니다 (시작시 에이전트에 의해 설정 됨).
따라서 클라이언트의 단일 호출로 에이전트를 조회하지 못하게하려면이 변수를 빈 문자열과 같이 유효하지 않은 것으로 명시 적으로 설정할 수 있습니다.
$ SSH_AUTH_SOCK= ssh user@server
이와 같은 클라이언트 호출은 에이전트와의 통신에 실패하고 파일로 사용 가능한 ID ~/.ssh/또는을 사용하여 명령 행에 지정된 ID 만 서버에 제공 할 수 있습니다 -i.
debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
답변
당신은 거의 모든 답을 얻었습니다.
Host *
PreferredAuthentications keyboard-interactive,password
나를 위해 일했다.