ssh는 절대 비밀번호를 요구하지 않습니다


14

어떻게 든 내 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

답변:


17

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

ssh -o PubkeyAuthentication=no root@newserver

괜찮아! 작동했습니다! 나는 성공하지 않고 "반대"를 시도했다 -o PasswordAuthentication=yes. 그러나 이것이 내가 찾던 것입니다.
Alexis Wilke

3
@AlexisWilke 나는 그것이 작동 기쁘다! 그러나 Olli의 답변도 읽으십시오. 그는 여전히 당신의 무언가에 문제가 있다는 점에서 옳습니다 .ssh/config. 는 -o PubkeyAuthentication=no영구적 인 해결책으로 좋은하지 않습니다.
Klaus-Dieter Warzecha

이 트릭 (-o PubkeyAuthentication = no)은 여러 ID 파일이있는 시스템에서 잘 작동했습니다.
Valerio Schiavoni

17

아마도 파일 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. 워크 스테이션을 손상 시키면 개인 키가 노출됩니다. 개인 키가 여러 개인 경우이 방법으로 도움이되지 않습니다 (다르고 강력한 암호 문구가 있고 모든 암호를 공격자가 사용할 수있는 경우는 제외).

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


2
아아! "너무 많은"파일을 식별하고 5 개를 확인하고 중지합니다. 알았다! 그것은 모든 것을 설명합니다. 하위 폴더에있는 모든 항목을 자동으로 찾지 못하고 암호 기능이 자동으로 다시 작동하도록 하위 폴더에있는 모든 항목을 이동해야한다고 생각합니다.
Alexis Wilke

3
가능하면 필요한 모든 서비스에 대해 단일 공개 키만 사용해야합니다. 다른 방법으로 그렇게 할 이유가 거의 없습니다. 누군가 공개 키 (의 내용 authorized_keys)를 훔치면 아무 것도 할 수 없습니다. 또한 모든 개인 키 ( id_rsa/ id_dsa)가 동일한 컴퓨터에있는 경우 둘 이상의 사용은 중요하지 않습니다.
Olli

4

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


1
다른 서버는 완전히 새로운 서버이며 정확히 그렇게하도록 지시합니다. 뿐만 아니라 내 파트너는 아무 문제없이 로그인 할 수 있습니다! 컴퓨터에서 암호를 테스트하지 못하게하는 비린내가 있습니다 ... 실제로 로그를 보면 인증 된 인증에는 "암호"가 포함됩니다. 따라서 로컬 ssh 클라이언트는 암호를 요구해야하지만 암호를 건너 뛰기로 결정합니다.
Alexis Wilke

서버에서 제공하는 경우 클라이언트가 해당 옵션을 제공하지 않는 이유를 확인하는 것보다 서버에서 암호를 묻는 메시지를 표시하지 않는 이유를 쉽게 확인할 수 있습니다. 결국 많은 구성 옵션이 있으며 몇 가지 옵션이 있습니다. 귀하의 IP 주소를 가진 사람이 올바른 비밀번호없이 너무 많이 로그인을 시도했을 가능성이 있으며, 이후의 IP 시도는 비활성화되었을 수 있습니다. 쏴, 난 그냥 Olli의 답변을 읽었습니다. 그게 다야.
Marc
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.