opensshd / openssh - permita o par de chaves ou a senha

1

Eu gostaria de configurar o meu sshd para permitir que os usuários autentiquem com um par de chaves e, em seguida, recorra à autenticação de senha. Mas estou lutando para conseguir isso a partir das informações no arquivo man pages / sshd_config.

Meu sshd_config:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Quando me conecto, parece que a chave privada está sendo enviada, mas ainda é solicitada uma senha:

[colinm@server bin]$ ssh -v colinm@dev-server
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to dev-server [10.168.172.81] port 22.
debug1: Connection established.
debug1: identity file /home/colinm/.ssh/identity type -1
debug1: identity file /home/colinm/.ssh/id_rsa type 1
debug1: identity file /home/colinm/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
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: Host 'dev-server' is known and matches the RSA host key.
debug1: Found key in /home/colinm/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /home/colinm/.ssh/identity
debug1: Offering public key: /home/colinm/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/colinm/.ssh/id_dsa
debug1: Next authentication method: password
colinm@dev-server's password:

É possível ter um servidor aceitando OU como um mecanismo de autenticação?

(sim, a chave pública é copiada para ~ / .ssh / authorized_keys, e eu reiniciei o sshd com esta configuração).

Mais depuração não mostra falha com o par de chaves:

...
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/colinm/.ssh/identity
debug3: no such identity: /home/colinm/.ssh/identity
debug1: Offering public key: /home/colinm/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/colinm/.ssh/id_dsa
debug3: no such identity: /home/colinm/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
    
por symcbean 28.08.2015 / 14:11

1 resposta

4

Normalmente, sshd permite autenticação de chave pública, autenticação de senha e outras que você ativou. Da sua saída, você pode ver que o GSSAPI é tentado primeiro, mas isso não foi bem-sucedido. Em seguida, as chaves públicas são oferecidas, mas elas não foram aceitas e, finalmente, a autenticação por senha solicita uma senha. Se você digitar uma senha errada (ou o login estiver desabilitado para essa conta), ela falhará, deixando você sem nada.

Embora tenha carregado a chave pública no arquivo ~/.ssh/authorized_keys , isso não é suficiente para que a autenticação de chave funcione. O serviço sshd é bastante rigoroso nas permissões também. O diretório ~/.ssh deve ter o modo 700 e os arquivos devem ter o modo 600. O proprietário do diretório ~/.ssh deve ser o próprio usuário, não o root ou qualquer outra pessoa.

    
por 28.08.2015 / 14:21