Eu tenho uma nova caixa RHEL4 Linux que estou usando para copiar dados para antigas caixas Solaris 2.6 e RHEL3 Linux com scp. Eu descobri que, com a mesma configuração, funciona para alguns usuários, mas não para outros. Para o usuário jane, isso funciona bem:
jane @ host1 $ ssh -v remhost
debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/osborjo/.ssh/identity
debug1: Offering public key: /mnt/home/osborjo/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
para jack de usuário, não:
jack @ host1 ssh -v remhost
debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/oper1/.ssh/identity
debug1: Offering public key: /mnt/home/oper1/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Eu olhei as permissões para todas as chaves e arquivos, eles parecem os mesmos. Como estou usando diretórios base montados pelo NFS, as chaves do host remoto e do host local estão no mesmo diretório. É assim que as coisas parecem para jane:
jane @ host1 $ ls -l $ HOME / .ssh
-rw-rw-r-- 1 jane operator 394 Jan 27 16:28 authorized_keys
-rw------- 1 jane operator 1675 Jan 27 16:27 id_rsa
-rw-r--r-- 1 jane operator 394 Jan 27 16:27 id_rsa.pub
-rw-rw-r-- 1 jane operator 1205 Jan 27 16:46 known_hosts
Para jack de usuário:
jack @ host1 $ ls -l $ HOME / .ssh
-rw-rw-r-- 1 jack engineer 394 Jan 27 16:28 authorized_keys
-rw------- 1 jack engineer 1675 Jan 27 16:27 id_rsa
-rw-r--r-- 1 jack engineer 394 Jan 27 16:27 id_rsa.pub
-rw-rw-r-- 1 jack engineer 1205 Jan 27 16:46 known_hosts
Como último esforço, eu copiei as authorized_keys, id_rsa e id_rsa.pub de jill para jack, e mudei o nome de usuário em authorized_keys e id_rsa.pub com vi. Ainda não funcionou. Parece que há algo diferente entre os dois usuários, mas não consigo descobrir o que é isso.
Eu encontrei a resposta. Estava nas permissões do diretório home do usuário jack. O conector do usuário tinha permissões de gravação de grupo no diretório inicial, enquanto o jane não. O problema é que todos os tutoriais na Web especificam as permissões para o diretório .ssh e os arquivos, mas não mencionam que o próprio diretório de usuários precisa ter permissão de gravação para o grupo desativado.
Você já tentou restringir a permissão do diretório .ssh ? Porque na maioria dos casos isso funcionaria. Não tenho certeza se a configuração "estrita" é verdadeira, mas encontrei o mesmo problema várias vezes antes, e a alteração das permissões no diretório .ssh corrigiu o problema.
Eu tive o mesmo problema, mas com um usuário ssh'ing para outro usuário local para o mesmo sistema.
Todas as permissões são as mesmas para os dois usuários.
A experimentação mostrou que os usuários A e B poderiam fazer login como um ao outro, mas nenhum deles poderia se conectar como usuário C.
Descobriu-se que o usuário C (sendo um usuário do sistema) não possuía uma entrada de sombra, embora ele tivesse uma entrada passwd.
Espero que isso seja útil para alguém com o mesmo problema mais tarde.
Sistema: OpenIndiana oi_151a
Eu uso o CentOS, que na verdade é o RHEL. Eu me encontrei na situação em que o contêiner SELinux do diretório / arquivos .ssh estava errado.
Verifique o /var/log/audit/audit.log para obter detalhes sobre as atividades do SELiunx.
Tags ssh solaris linux public-key