A autenticação da chave SSH falha

29

Estou tentando fazer o ssh em um servidor CentOS sobre o qual não tenho controle .. o administrador adicionou minha chave pública ao servidor e insiste que a falha está comigo, mas não consigo descobrir o que está errado.

Configure em .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Permissão nos meus arquivos-chave:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Log de conexão que não consigo entender:

tim@tim-UX31A:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

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


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh sshd ssh-keys Tim
fonte
A partir das tampas, parece que a chave foi enviada, mas nenhuma resposta é recebida. -Você deveria logar como root ou logar como tim e depois usar o sudo? Às vezes, o login ssh como root está desativado. -Quais são as permissões do próprio diretório .ssh? -Você tem o servidor certo? O DNS está resolvendo corretamente? -Você pode criar as chaves novamente e, em seguida, usar ssh-copy-id para copiar manualmente a nova chave pública no arquivo allowed_keys. Apenas no caso de a chave ficar corrompida de alguma forma.
Kyle H
Obrigado por tentar ajudar! As permissões na minha pasta .ssh são: drwx ------ 2 tim tim 4096 Ok 20 20:13 .ssh. O login como root está correto - ele realmente funcionou algumas semanas atrás antes de reformatar meu computador. O administrador diz que adicionou as novas chaves corretamente, mas eu realmente não sei como isso pode ser minha culpa neste momento #
21116 Tim Tim
Como o @KyleH mencionou, você já tentou ssh [email protected]como o log menciona o Kerberos, o servidor CentOS pode ser integrado ao domínio (AD, IPA, ...). Você precisa descobrir qual usuário deve usar. Pergunte ao administrador. Por exemplo, estamos usando o IPA, portanto, permitimos que os usuários se conectem a determinados servidores com sua conta de domínio IPA e par de chaves e, se necessário, podem usar o sudo. Sem acesso root :)
Zina 21/10

Respostas:

18

Isso geralmente resolve a maioria dos problemas de permissão de chave autorizada por SSH no lado do servidor , supondo que alguém não tenha feito alterações adicionais nas permissões.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Se o seu administrador criou o arquivo .ssh / directory ou .ssh / allowed_keys como root (o que é mais comum como isso é realizado), não é permitido ter o arquivo de propriedade de outro usuário (mesmo que o root!).

O Userify (aviso de isenção de responsabilidade: co-fundador) faz isso exatamente da mesma maneira automaticamente. Https://github.com/userify/shim/blob/master/shim.py#L285

Jamieson Becker
fonte
Se esse fosse o problema, o cliente não teria tentado enviar a chave ao servidor em primeiro lugar; o log fornecido na pergunta é explícito.
Charles Duffy
Isso corrige o problema do lado do servidor. Você está certo de que o lado do cliente está ok.
Jamieson Becker
1
Isso finalmente resolveu meu problema. Passei horas tentando descobrir por que minhas chaves públicas / privadas não estavam sendo aceitas.
Daniel Harris
Outro usuário sugeriu sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rque irá poupar tempo digitando, mas pode ser mais difícil para um novato entender
Jamieson Becker
11

Eu tive exatamente o mesmo problema em dois servidores: um Linux executando Debian stretch e em um NAS (Synology DS715)

descobriu-se que, nos dois casos, as permissões do diretório inicial no servidor estavam erradas

o auth.log no servidor foi muito útil

Authentication refused: bad ownership or modes for directory /home/cyril

no Linux, ele tinha o bit de gravação / grupo ativado (drwxrwxr - x), então eu tive que remover pelo menos a gravação no grupo (chmod gw ~ /) e funcionou

na Synology, por qualquer motivo, houve um pouco de dificuldade

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Eu tive que mudar isso com

chmod -t ~/

e eu poderia conectar sem uma senha

Cyril Chaboisseau
fonte
Obrigado por isso chmod -t... Acabei com:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
Stéphane
6

Ao usar o CentOS 7, tenho certeza de que também se aplica a outros sistemas operacionais Linux que usam sshd. Com o acesso root, você pode determinar mais sobre por que a autenticação pode estar falhando. Para fazer isso:

  1. Habilite o log para sshd: vi /etc/ssh/sshd_config
  2. Sob o registro, descomente:

SyslogFacility AUTH LogLevel INFO

  1. Altere o LogLevel INFO para LogLevel DEBUG
  2. Salvar e sair
  3. Reinicie o sshd systemctl restart sshd
  4. Assista ao arquivo de mensagens tail -l /var/log/messages
  5. Usando outro terminal, tente conectar-se ao ssh
  6. Tentativa de se conectar com ssh
  7. Revise o log de autenticação para obter a causa exata

Por exemplo, eu estava tendo alguns dos mesmos problemas mencionados acima. 

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Usando essas etapas, eu pude confirmar que o problema era de permissões no arquivo allowed_keys. Ao definir chmod como 644 no arquivo de chaves autorizadas do meu usuário, o problema foi corrigido.

JonCav
fonte
4

Parece que as permissões na sua .sshpasta não foram copiadas e coladas corretamente. Você poderia adicioná-lo novamente?

Se o modo estrito estiver ativado, precisamos garantir que .sshas permissões corretas sejam:

  • .ssh/ deve ter permissões 0700/rwx------
  • .ssh/*.pub arquivos devem ser 644/rw-r--r--
  • .ssh/* (outros arquivos em .ssh) 0600/rw-------

Como as coisas o procuram em termos de permissão?

Kyle H
fonte
As permissões na minha pasta pessoal (tim) são 755 (drwxr-xr-x) e as permissões na própria pasta .ssh são 700 (drwx). id_rsa é 600 e arquivo pub é 644 ..: / obrigado novamente, espero que a informação ajuda
Tim
Eu tenho ssh trabalhando para muitos servidores. Meu diretório pessoal é drwxr-xr-x (0755), .ssh é rwx ------ (0700), dentro de .ssh minha chave de pub é -rw-r - r-- (0644) e o restante nessa pasta estão -rw ------- (0600). Portanto, suas permissões são boas e devem passar na verificação estrita do host. O que está no seu arquivo / etc / ssh_config? Alguma coisa em ~ / .ssh / config? Eu tive a criação de chave ssh por um motivo ou outro que não funcionou, embora não houvesse erros. Você pode tentar usar ssh-keygen para regenerar suas chaves, ssh-copy-id para copiar sua chave pub para o servidor remoto com autenticação por senha ativada?
Kyle H
Infelizmente não tenho acesso ao servidor, mas tentarei solicitar ao administrador que copie minha chave de publicação no servidor novamente na segunda-feira. Copiei o conteúdo dos arquivos de configuração para pastebin: pastebin.com/eEaVMcvt - obrigado novamente por seu Socorro!
Tim
Seja bem-vindo. Fico feliz em ajudar! Também gosto de resolver problemas e principalmente de ajudar outras pessoas com o Linux. Há uma linha ímpar em seu ssh-config que pode causar problemas. Qual é o ip 10.0.12.28?
Kyle H
@ KyleH está certo .. esse é quase certamente o problema. Eu adicionei outra resposta que mostra como corrigi-lo com acesso root. Se você controlar o seu homedir, você pode, eventualmente, corrigi-lo sozinho, mas é claro que você tem que ser capaz de log in :)
Jamieson Becker
4

Apenas no caso de alguém tropeçar nessa resposta - nenhuma das recomendações funcionou no meu cenário. No final, o problema foi que eu criei uma conta sem senha definida. Depois de definir a senha usermod -p "my password" usernamee desbloquear à força a conta, usermod -U usernametudo ficava meio pêssego.

Nathan Crause
fonte
Sua resposta me sinalizou para o meu caso diferente, mas também relacionado ao usuário, de tentar fazer login quando o diretório inicial que eu forneci estava mais aninhado do que aquele com o qual estava entrando ... É ótimo corrigir isso, obrigado!
Brett Zamir
1

Eu tive um problema semelhante , em que a conexão ssh tenta a chave ~/.ssh/id_rsaantes de parar inesperadamente:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

No meu caso, isso ocorreu devido a um antigo arquivo de chave pública localizado no .sshdiretório:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Mover / excluir a id_rsa.pubpartir do .sshdiretório resolveu o problema.

Pelo que entendi: quando há uma chave pública presente no lado do cliente, o SSH 1st valida a chave privada. Se falhar, não tentará usar a chave privada para conectar-se remotamente.

Enviei um email para a lista de discussão openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Elouan Keryell-Even
fonte
1

Encontramos este problema. Permissões e propriedade dos arquivos .ssh estavam corretas. Em / var / log / messages, encontramos:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

Portanto, a solução para o desenvolvedor vm em que não nos preocupamos com segurança é desativar o selinux. Edite / etc / sysconfig / selinux e altere SELINUX = desativado e reinicie.

gaoithe
fonte
1

Também encontrou esse problema. O setroubleshoot não parecia funcionar no meu ambiente, portanto não havia esse registro de log em / var / log / messages. Desabilitar o SELinux não era uma opção para mim, então eu fiz

restorecon -Rv ~/.ssh

Após esse login pela rsa key funcionou bem.

lapin_
fonte
1

Caso isso também salve alguém. Eu estava tentando copiar uma chave da minha máquina Ubuntu 18.04 para 2 servidores CentOS 7. Eu costumava ssh-copy-idtransferi-los. Um funcionou, um não. Então, eu passei por todas as permissões de depuração e não encontrei nada. Então, finalmente, puxei o arquivo /etc/ssh/sshd_confignos dois servidores e passei linha por linha através deles. Finalmente eu encontrei, provavelmente algo que alguém modificou muito antes de eu entrar no trabalho.

Uma leitura: AuthorizedKeysFile .ssh/authorized_keys

E outra leitura:, AuthorizedKeysFile ~/.ssh/authorized_keysque estava no servidor que não estava aceitando minhas chaves. Obviamente, olhando entre os dois arquivos e observando o comentário que declara os padrões de pesquisa padrão não incluem o principal, ~/eu o removi e reiniciei o sshd. Problema resolvido.

Aaron Chamberlain
fonte
0

Um log de erros do lado do cliente que termina assim:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

pode ser causado por uma restrição (remota) do lado do servidor no login raiz quando o arquivo de configuração sshd contém:

PermitRootLogin: no

A sugestão de JonCav para habilitar o log foi útil na depuração desse problema. Embora o spew de depuração do lado do cliente tenha sido extraordinariamente inútil, coloque o seguinte no arquivo sshd_config do servidor sshd :

SyslogFacility AUTH
LogLevel DEBUG

acabou produzindo mensagens de log úteis:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

No caso em que apenas o login root falha, e desde que a autenticação de chave seja permitida pela política de segurança, uma alteração no arquivo sshd_config pode ajudar:

 PermitRootLogin without-password

Sua milhagem pode variar, embora isso geralmente ajude, alguma outra configuração ainda pode interferir, de acordo com um comentário encontrado em alguns arquivos sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Mesmo que você não consiga alterar facilmente a configuração do servidor remoto para depuração dessa maneira, pode-se comprovar a configuração do lado do cliente até certo ponto, usando os mesmos arquivos de identidade para ssh em uma conta não raiz no mesmo servidor remoto.

Kbulgrien
fonte
0

O motivo, no meu caso, foi uma opção configurada de maneira personalizada AuthorizedKeysFileno arquivo /etc/ssh/sshd_config. Como foi definido como dir (home /home/webmaster/.ssh/authorized_keys) de outro usuário , o usuário que eu estava tentando acessar não tinha acesso a esse arquivo / diretório.

Depois de alterá-lo e reiniciar o ssh-server ( service ssh restart) tudo voltou ao normal. Agora posso fazer login com minha chave privada.

ihoru
fonte
0

Percebo por que a segurança pode incomodar as pessoas. Eu só tive o ssh won't use my keyproblema novamente. Eu o resolvi entrando no servidor remoto e executando

/usr/sbin/sshd -sDp 23456

e depois da minha área de trabalho (tentando ssh no servidor)

ssh -vvvv server -p 23456

No servidor eu consegui Authentication refused: bad ownership or modes for directory /

Alguns novos administradores de sistemas haviam atrapalhado a permissão e a propriedade, com as quais eu consertei:

chmod 0755 / ; chown root:root /

(Estou acostumado a precisar chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub mas a verificação / localização de permissões de root pelo sshd é nova para mim.) Agora vou procurar um rootkit e, em seguida, limpe e reinstale de qualquer maneira.

Alexx Roche
fonte
0

No meu caso, os problemas estavam com o shell exec incorreto.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Arquivo / etc / passwd alterado para esse usuário

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....
nelaaro
fonte
0

Eu tive esse problema no CentOS 7. Eu sou um usuário comum do Linux baseado no Debian, então eu era um peixe fora d'água. Percebi que em alguns servidores funcionou e em apenas um não. O audit.log não disse nada de útil e o secure.log também não deu nada. Eu descobri que a única diferença real eram algumas diferenças de contexto de segurança em arquivos e diretórios entre aqueles que funcionavam e os que não funcionavam. Obtenha segurança com

sudo ls -laZ <user-home>/.ssh

do diretório (estou assumindo muitos padrões no sshd_config).

Você deve ver alguns ssh_home_te user_home_tatributos. Caso contrário, use o chconcomando para adicionar os atributos ausentes.

Por exemplo

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

No meu caso, minha suspeita é que o usuário tenha sido criado de maneira não padrão. Sua casa era um diretório em /var/lib.

Mais informações em: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

hanzo2001
fonte
0

No nosso caso, os problemas estavam relacionados ao fato de que nossas regras de firewall e NATing não foram configuradas corretamente.

porta 22, estava sendo direcionada para o servidor incorreto onde nossas chaves e usuário não estavam sendo reconhecidos.

Se alguém chegar a esse ponto. tcpdump e telnet podem ser seus amigos

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Você notará que esses dois servidores possuem versões openssh diferentes. Isso me ajudou a identificar o problema rapidamente. Se seus hosts estiverem usando as mesmas versões ssh, você deverá tentar fazer um rastreamento compactado no destino para verificar se o tráfego está chegando ao destino.

O ssh pode gerar muito tráfego, o que dificulta o tcpdump out para encontrar o que você está procurando.

Isso me ajudou

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Tente telnetar a partir de um servidor 3 diferente do seu computador atual @ [mylocalip]. Você deseja ver qual tráfego realmente chega ao seu servidor.

nelaaro
fonte