Desconectado: nenhum método de autenticação suportado disponível

12

Eu tenho o mesmo problema exato descrito neste tópico , mas a resposta aceita não é a correta para mim, porque o diretório inicial do usuário é local.

Eu acho que configurei tudo corretamente no lado do cliente (Windows 7, PAGEANT, PUTTYGEN e PLINK do PuTTY), mas não pareço fazer o mecanismo de chave pública funcionar (o login ssh baseado em senha funciona). Eu segui todas as etapas, sugestões e dicas em:

Agora, suspeito que esteja faltando algo no lado do servidor (Linux, sshd), por isso estou postando o /etc/ssh/sshd_configconteúdo atual :

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Alguma idéia do que estou fazendo de errado?

UPDATE: Encontrei uma dica para executar o sshd no modo de depuração , e aqui está a saída:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Agora, noto as duas bad ownership or modes for directory /home/winwinmensagens, mas verifiquei a propriedade ou os modos do diretório / home / winwin e AFAICT.

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

E:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

E:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

O que poderia estar errado?

ATUALIZAÇÃO II: Tentei chmod 600conforme sugerido na resposta abaixo:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

E:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

Mas ainda não funciona. Por que ainda estou recebendo o Authentication refused: bad ownership or modes for directory /home/winwinerro?

— WinWin
fonte

9

Tente obter as permissões graváveis do grupo no diretório inicial:

chmod g-w ~/

Torne sua pasta .ssh legível / gravável / executável somente por você :

chmod 700 ~/.ssh

Torne seu arquivo de chaves autorizado legível / gravável somente por você :

chmod 600 ~/.ssh/authorized_keys

Isso deve remover os erros de permissão.

— John T
fonte

Eu fiz exatamente como você sugeriu ~/.sshe ~/.ssh/authorized_keys. Ainda sem sorte. Quanto a obter as permissões graváveis do grupo no próprio diretório inicial, não posso fazer isso, pois isso prejudicaria todo o objetivo desse usuário / grupo para o qual foi criado. O diretório inicial deste usuário deve ser gravável pelo grupo (com o mesmo nome exato e gid!). +1 por tentar ajudar.

— WinWin

Obrigado! chmod g-w ~/me salvou depois de horas de loucura e puxar cabelo quando eu não podia ssh com massa em nome de um dos usuários, com outros usuários trabalhando ok ...

— PavelS

Gah ya obrigado, eu criei o meu diretório home com meu outro usuário, e eu estava faltando chmod gw ~ /

— Clarence Liu

5

Sucesso!

Tudo o que eu precisava fazer era mudar StrictModespara não .

De acordo com a seção 3.14 nas perguntas frequentes do OpenSSH e http://blogs.nullvision.com/?p=114 .

Uau.

— WinWin
fonte

Hmm, isso é mais uma solução alternativa do que uma solução. Deixe-me verificar algo na minha caixa.

— Rob

Meu ls -lad .sshestá mostrando drwx, então chmod 700 ~/.sshe os arquivos dentro são todos -rw, então chmod 600 ~/.ssh/*-SHOULD- funciona.

— Rob

Deixa pra lá, viu O diretório inicial deste usuário deve ser gravável pelo grupo (com o mesmo nome e gid!) Abaixo

— Rob

Desta forma é sem usuário!

— Amor

3

Teve um problema semelhante. Ao bisbilhotar, notei que meus diretórios pessoais estavam criptografados e suspeitava que esse era o problema. Copiei o arquivo de chaves autorizadas para um diretório fora do diretório inicial criptografado, alterei as permissões adequadamente (chmod 700 [dir], chmod 600 [dir] / allowed_keys, etc.).

Em seguida, edite seu sshd_config para informar ao sshd o novo local do arquivo de chaves autorizado, reinicie o sshd e pronto.

Parece ter corrigido o meu problema.

— vermelho
fonte

2

Parece que suas permissões para o diretório pessoal (ou possivelmente sua pasta .ssh / allowed_keys) estão incorretas. A correção desses deve corrigir o problema de login. Tente chmod 600 /home/winwin/.ssh/*
Você pode precisar chmod 700 /home/winwin/.sshtambém.

O SSHd se recusará a carregar seu authorized_keysarquivo se ele puder ser gravado por qualquer pessoa que não seja seu usuário (como proprietário), porque é um risco à segurança.

— Darth Android
fonte

Obrigado +1. Veja minha atualização acima, pois ainda não consigo descobrir quais devem ser as permissões / propriedades corretas.

— WinWin

Eu apenas tentei chmod 600 /home/winwin/.ssh/*. Isso não ajudou. : - /

— WinWin

1

@WinWin, você também o definiu no .sshdiretório? (Atualizei minha resposta).

— Darth Android

Sim eu fiz. Ainda sem sorte.

— WinWin

2

Lutei por isso e finalmente encontrei uma solução que não causa uma potencial falha de segurança como StrictModes Não faz.

Verifique se suas configurações são as seguintes:

chmod 0755 / home / {userdir}

chmod 0700 / home / {userdir} /.ssh

chmod 0600 / home / {userdir} /.ssh/authorized_keys

Onde {userdir} é o diretório em questão.

A chave é chmod 0755, que garante que apenas o usuário possa gravar na unidade doméstica. Copiei isso da minha configuração de usuário que funcionou e pronto! Os outros nomes de usuário começaram a funcionar também!

Espero que isso ajude outras pessoas como eu e economize algumas horas de tempo.

— smcjones
fonte

1

Essa mensagem de erro também pode ser causada pelo SELinux, impedindo o acesso do sshd authorized_keys. Tente o seguinte:

restorecon -FRvv ~/.ssh

( desta resposta )

— RomanSt
fonte

0

chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;

— Tio Bob
fonte

3

Bem-vindo ao Super Usuário! Seria bom se você pudesse explicar o que esses comandos fazem.

— Slhck

0

No meu caso, era o diretório inicial que tinha outro proprietário (raiz) que o usuário real ao qual esse diretório inicial pertence (minha estupidez ao criar o diretório inicial com raiz para outro usuário).

Chown [user]:[group] /home/[user]

resolveu esse problema (e, é claro, atenha-se às permissões de arquivo / diretório, conforme compartilhadas em outras respostas).

— Philippe
fonte