Estou tendo um problema muito peculiar ao fazer o SSH funcionar na minha caixa do Linux. Eu tenho um usuário git sem senha identificado por uma chave OpenSSH. Se eu tentar ssh para ele a partir da mesma ou de uma diferente máquina virtual Linux na rede, ela falhará (veja abaixo as informações completas sobre depuração).
Mas agora, aqui está a parte estranha: eu sou capaz de usar o ssh da minha caixa do Windows 7, usando exatamente as mesmas chaves! Isso sugere que podemos estar olhando para uma problema do lado do cliente. Se as chaves no servidor fossem de alguma forma borked, eu não deveria ser capaz de me conectar de qualquer lugar.
Eu tenho triturado minhas rodas na lama por dias. Há uma tonelada de tópicos sobre o assunto, mas nenhuma das soluções funcionou ou foi aplicada.
As permissões ~ / .ssh foram definidas corretamente no cliente e no servidor.
Especificamente, ~ / .ssh / * foi definido como 600 (um encadeamento recomendado alterando authorized_keys (server) para 644, mas isso não teve efeito).
O diretório ~ / .ssh foi definido como 700.
Tudo no ~ é de propriedade do usuário / grupo de mesmo nome.
Cliente (/home/kris/.ssh):
drwx------ 2 kris kris 4096 Apr 11 01:17 .
drwx------ 38 kris kris 4096 Apr 11 01:29 ..
-rw------- 1 kris kris 458 Apr 11 16:22 config
-rw------- 1 kris kris 1675 Apr 10 22:29 id_rsa_kriscraig_git
-rw------- 1 kris kris 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw------- 1 kris kris 400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw------- 1 kris kris 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw------- 1 kris kris 400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw------- 1 kris kris 951 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris
-rw------- 1 kris kris 214 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris.pub
-rw------- 1 kris kris 381 Apr 10 22:29 id_rsa_kriscraig_git.pub
-rw------- 1 kris kris 1626 Apr 11 17:50 known_hosts
Servidor (/home/git/.ssh; é um pouco confuso agora devido a toda tentativa / erro que tenho feito):
drwx------ 2 git git 4096 Apr 11 01:36 .
drwx------ 8 git git 4096 Apr 9 17:55 ..
-rw-r--r-- 1 git git 2174 Apr 11 01:40 authorized_keys
-rw------- 1 git git 904 Aug 4 2012 authorized_keys_bak
-rw------- 1 git git 354 Aug 4 2012 authorized_keys_bak2
-rw------- 1 git git 2174 Apr 11 01:13 authorized_keys_bak3
-rw------- 1 git git 160 Apr 10 00:32 config
-rw------- 1 git git 1675 Aug 3 2012 id_rsa
-rw------- 1 git git 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw------- 1 git git 400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw------- 1 git git 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw------- 1 git git 400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw------- 1 git git 951 Apr 10 00:32 id_rsa_kriscraig_gitolite_Kris
-rw------- 1 git git 214 Apr 10 00:33 id_rsa_kriscraig_gitolite_Kris.pub
-rw------- 1 git git 381 Aug 3 2012 id_rsa.pub
-rw------- 1 git git 414 Aug 4 2012 known_hosts
Embora este seja provavelmente óbvio, verifiquei, de fato, que os caminhos de arquivo na configuração estão corretos.
Tentei gerar / distribuir novas chaves várias vezes.
Eu tentei copiar / colar os que já estão trabalhando no Windows, até mesmo usar o dos2unix para ter certeza de que não estávamos lidando com problemas de codificação (CRLF / LF, etc).
Gerei as chaves usando a abordagem padrão:
ssh-keygen -t rsa
Tentei brincar com as permissões dos diretórios principais dos pais sem nenhum benefício.
Eu mexi com as configurações locais, bem como / etc / ssh / * _ config
E sim, reiniciei o sshd todas as vezes. Eu mesmo reiniciei o servidor em intervalos aleatórios, apenas no caso.
Tenho certeza de que estou perdendo pelo menos algumas coisas. Eu não tenho dormido muito ultimamente ....
Vou tomar algumas sugestões neste momento. Eu não vou te recusar se acontecer que eu já tentei. =)
Entradas resultantes para duas tentativas ssh com falha em / var / log / secure:
Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14738]: Connection from (WAN IP) port 35326
Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14739]: Connection closed by (WAN IP)
Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14741]: Connection from (WAN IP) port 35328
Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14742]: Connection closed by (WAN IP)
[kris@CRAIGCOM-LINUX .ssh]$ ssh git@CRAIGCOM-LINUX -vvv
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /home/kris/.ssh/config
debug1: Applying options for CRAIGCOM-LINUX
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to (SERVER HOST) [(SERVER IP)] port 22.
debug1: Connection established.
debug1: identity file "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" type -1
debug1: loaded 1 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
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 118/256
debug2: bits set: 484/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '(SERVER HOST)' is known and matches the RSA host key.
debug1: Found key in /home/kris/.ssh/known_hosts:1
debug2: bits set: 522/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
debug3: no such identity: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).
Como você pode ver no log, ele está retornando "sem essa identidade" depois de tentar abrir o arquivo de chave privada. Eu acho que essa rejeição está acontecendo no lado do cliente. Tanto quanto eu posso dizer, não está enviando nada para o servidor, seja qual for; apenas abrindo e abruptamente fechando a conexão.
Para a vida de mim, eu não consigo descobrir por que ele está vomitando nos arquivos de chaves em ambas as caixas CentOS! As permissões são definidas perfeitamente, os arquivos são legíveis, nenhum servidor está usando o SELinux, as mesmas chaves estão funcionando perfeitamente bem a partir do cliente Windows, etc.
Eu estou bem usando o chapéu de sysadmin; mas no final do dia, sou um desenvolvedor, não uma pessoa de TI. Esse nível de depuração de SSH me levou para fora da minha área de especialização. Eu odeio dizer isso, mas eu simplesmente fico sem ideias. De acordo com cada coisa que eu consegui encontrar nas internets, isso deveria estar funcionando. Mas isso não. O que estou perdendo?
Obrigado pela sua ajuda! Espero que um de vocês reconheça esse problema e dê um jeito na direção certa. Se você precisar de mais detalhes, sinta-se à vontade para perguntar.
- Kris
Por favor, use o agente ssh.
ssh-add ~/.ssh/$keyfile . ssh-add -l
Se realmente houver um problema com sua chave, você deverá notar uma vez que tentar adicioná-la.