ssh는 절대 비밀번호를 요구하지 않습니다 않습니다. 그래서 전 세계 어딘가에

어떻게 든 내 SSH는 결코 암호를 묻기를 원하지 않습니다.

그래서 전 세계 어딘가에 임의의 서버에 VPS를 설정하고 ssh로 VPS에 연결하고 싶습니다.

키를 설정할 수 있지만 이렇게하면 :

ssh -l some-user IP

오류가 발생합니다.

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

세부 정보를 보면 암호가 옵션 중 하나임을 알 수 있습니다.

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

그러나 SSH는 비밀번호를 묻지 않습니다. 공개 키 방법이라고 생각되는 것으로 5 번 시도한 다음 실패합니다. 왜 ssh가 암호로 시도하지 않습니까?!

ssh_config 파일에는 다음과 같은 경우가 있습니다.

PasswordAuthentication yes

전체 로그

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root



답변

다음을 사용하여 공개 키 인증을 비활성화 한 상태에서 로그인을 시도하십시오.

ssh -o PubkeyAuthentication=no root@newserver


답변

아마도 파일 identityfile에 한 줄 이상이있을 것입니다 .ssh/config.

구성 identityfile중인 경우 host에도 전체적으로 적용됩니다. ssh즉, 서버에서 비밀번호 프롬프트를 요청하기 전에 모든 호스트에서 모든 ID 파일 (예 : 공개 키) 을 시도합니다.

이 문제를 해결할 수 있습니다

  1. identityfile줄만 제외하고 모두 제거
  2. 추가 PubkeyAuthentication no.ssh/config, 또는
  3. -o PubkeyAuthentication=no매개 변수를 사용 하여 ssh를 실행합니다 .

보낸 사람 man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple
    IdentityFile directives will add to the list of identities tried (this
    behaviour differs from that of other configuration directives).

공개 키가있는 몇 가지 일반적인 지침 :

  1. 일반적으로 클라이언트 (워크 스테이션) 당 하나의 개인 키만 있어야하며 클라이언트가 액세스해야하는 모든 서버에 일치하는 공개 키를 넣어야합니다. 즉, 서버간에 공개 키를 공유하고 여러 장치에서 동일한 개인 키를 사용하지 마십시오.
  2. 항상 장치에서 키 쌍을 생성하고 공개 키만 전송하십시오. 이렇게하면 서버가 손상 되더라도 개인 키는 여전히 안전하고 안전합니다. 이는 백업과 같은 놀라운 방법으로 발생할 수 있습니다.
  3. 다른 사람이 서버를 관리한다하면, 당신은 그들을 위해 공개 키를 제공해야한다; 그들은 키 쌍을 생성하고 개인 키를 보내서 는 안됩니다 . 그렇게하면 그들은 당신의 열쇠로 당신을 사칭 할 수 없습니다 (물론 그들은 원하는 것을 할 수 있습니다). 또한 공개 키를 사용하면 무결성 (즉, 공개 키를 변경하지 않은 사람) 만 보호해야합니다. 개인 키를 사용하면 기밀성 (즉, 아무도 키를 얻지 못함)을 보존해야하며 훼손되지 않았다는 것을 절대 확신 할 수 없습니다.
  4. 여러 개인 서버에 연결하기 위해 동일한 개인 키를 사용하더라도 서버를 손상해도 다른 서버는 손상되지 않습니다 (개인 키를 서버로 전송 한 경우는 제외).
  5. 워크 스테이션을 손상 시키면 개인 키가 노출됩니다. 개인 키가 여러 개인 경우이 방법으로 도움이되지 않습니다 (다르고 강력한 암호 문구가 있고 모든 암호를 공격자가 사용할 수있는 경우는 제외).

이것에는 예외가 있지만 너무 많지는 않습니다.


답변

로컬 ssh는 암호를 요구해서는 안되며 다른 쪽 끝의 ssh 서버는 암호를 요구하지 않아야합니다. 서버가 비밀번호 인증을 허용하지 않도록 설정되었을 수 있습니다. 내 비밀번호도 묻지 않을 것입니다.


답변