Como saber se posso usar os keypairs do ssh?

Question

Após a execução bem-sucedida, meu script de construção tenta copiar o binário final para o meu servidor FTP usando o comando scp . Como a compilação demora um pouco, não quero ser solicitada a senha toda vez, então tentei configurar um par de chaves SSH.

[wbarlow@build-machine]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/wbarlow/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/wbarlow/.ssh/id_rsa.
Your public key has been saved in /home/wbarlow/.ssh/id_rsa.pub.
The key fingerprint is:
7f:b9:c7:a8:1b:77:ce:f8:b6:2a:e3:da:30:68:72:b7 wbarlow@build-machine

[wbarlow@build-machine]$ ssh-copy-id wbarlow@ftp-server
wbarlow@ftp-server's password: 
Now try logging into the machine, with "ssh 'wbarlow@ftp-server'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Então eu tentei entrar no meu servidor ftp, mas ainda fui solicitado por uma senha. Confirmei que a chave recém-criada estava presente.

[wbarlow@build-machine]$ ssh wbarlow@ftp-server
wbarlow@ftp-server's password: 

[wbarlow@ftp-server]$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGUbr4vUeiY7D6sSrsHm469QAqCClchL
7h/HZ7TAc+1F2KsTTF078OSINqzz8NpKJqhlEusLn644PzYn9LmGTIc7IsMG9s+B2n4bZX
9Ypb0VqLSqTgfE2I0j84+SfAQ6MvGJQ0NupIXxXbaMLDlNq1cetnR8NeN+9JeBq4sI8p/a
ijFVARQ7/XSKwQQN30Nl6flTEM1CTDECJs5YsPOu3P54mF6PG2mBdFra6+VQfAZ6fboq9O
d24VNHLYVtUdK5RpWgx8agUalov0xq/3m2VeC5arrYpCVH1rGx6EMxoQS25kk7t9mzBUCj
ulXGWQX2DPR/Em0OIfvVfe/l4xtFfH wbarlow@build-machine

Eu posso usar a chave pública para autenticar com outras máquinas (ou seja, meu host do repositório Git), então não acho que o problema esteja no lado do cliente.

Então - como posso verificar se o servidor FTP está configurado para aceitar chaves autorizadas e que tipo de chaves ele está configurado para aceitar? Como posso verificar se as chaves estão sendo armazenadas no lugar esperado (meu diretório pessoal no ftp-server é /var/ftp/wbarlow/ , mas também tentei copiar a pasta .ssh para /home/wbarlow/ .)?

Meu diretório .ssh é o modo 700 e meu arquivo authorized_keys é o modo 600. Eu também tentei usar 755 para o diretório .ssh .

Eu encontrei meu arquivo /etc/ssh/sshd_config no servidor ftp. Eu não vou postar a coisa toda, mas tem as seguintes linhas:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

Tanto quanto eu posso dizer da documentação , Eu acho que essas linhas estão definidas corretamente para o que eu quero fazer (chave s / é algo não relacionado a keypairs ssh, certo?).

Abaixo está a saída detalhada durante a conexão.

[wbarlow@build-machine]:~$ ssh -v wbarlow@ftp-server
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ftp-server [(ip hidden)] port 22.
debug1: Connection established.
debug1: identity file /home/wbarlow/.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/wbarlow/.ssh/id_rsa-cert type -1
debug1: identity file /home/wbarlow/.ssh/id_dsa type -1
debug1: identity file /home/wbarlow/.ssh/id_dsa-cert type -1
debug1: identity file /home/wbarlow/.ssh/id_ecdsa type -1
debug1: identity file /home/wbarlow/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5*
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: 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 [SNIP]
debug1: Host 'ftp-server' is known and matches the RSA host key.
debug1: Found key in /home/wbarlow/.ssh/known_hosts:1
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-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

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

    

Answer 1

As configurações de configuração do servidor SSH geralmente estão em /etc/ssh/sshd_config , mas a primeira coisa que eu verificaria seria a localização e as permissões da chave pública e seu diretório pai que você copiou para o servidor.
Observando que as permissões corretas de authorized_keys no controle remoto são críticas para o ssh funcionar - e por isso usamos ssh-copy-id e não simplesmente copiando a chave pública para o controle remoto. Para entender isso, pode ser útil dividir o que o ssh-copy-id faz.

A primeira coisa que faz é proteger a cópia id_rsa.pub para o servidor de destino, por exemplo

scp -P port $HOME/.ssh/id_rsa.pub username@ipaddress:destination_path

e coloque em ~/.ssh/ da máquina remota.

ele também id_rsa.pub to authorized_keys , então você acaba com

$ ~/.ssh/authorized_keys

na máquina remota.
Ele também define as permissões críticas , ou seja, authorized_keys do arquivo não deve ser menos seguro que

-rw------- 1 wbarlow wbarlow  802 Nov 25 13:54 authorized_keys

O diretório

e .ssh não pode ser menos seguro que 755 , por exemplo,

drwx------ 2 wbarlow wbarlow  4096 Jul 29 00:30 .ssh

Eu costumo usar o comando

ssh-copy-id -i ~/.ssh/id_rsa.pub remote_user@remoteIP

Dessa forma, a chave específica que eu quero entra no controle remoto, mas eu não acho que seria o seu problema, já que suspeito que o ssh irá verificar todas as chaves privadas disponíveis em sua máquina local ao tentar estabelecer uma conexão.

Além disso, como sempre, certifique-se de verificar as permissões básicas das pastas que o contêm ($ HOME) para que outros usuários / programas tenham privilégios de arquivo apropriados.