O sistema está executando o selinux no modo enforcing? Nesse caso, você restaurou o contexto no arquivo authorized_keys?
O SELinux pode impedir que o sshd leia um arquivo authorized_keys quando ele foi modificado.
Eu posso fazer login no meu servidor com uma senha, mas não com a minha chave pública. Estou rodando o CentOS release 6.3 (Final) em um servidor Rackspace.com
Eu adicionei meu ~ / .ssh / id_rsa.pub local ao ~ / .ssh / authorized_keys do servidor remoto e as permissões remotas parecem bem.
$ ll -d .
drwxr-x---. 15 fort apache 4096 Feb 22 16:07 .
$ ll -d .ssh
drwx------. 2 fort apache 4096 Feb 17 19:40 .ssh
$ ll -d .ssh/authorized_keys
-rw-------. 1 fort fort 2034 Feb 18 06:06 .ssh/authorized_keys
Verifiquei se o servidor está aceitando a autenticação de chave pública:
$ ssh -o PreferredAuthentications=none fort@fort
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).
Conectando com -vvv mostra a falha
$ ssh -vvv -o PreferredAuthentications=publickey fort@fort
OpenSSH_7.3p1, LibreSSL 2.4.1
debug1: Reading configuration data /Users/kim/.ssh/config
...
debug1: Connecting to cedar.greencitypartnerships.org [108.166.125.240] port 22.
debug1: Connection established.
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/kim/.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: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).
$
Isso é tudo o que vejo quando estamos seguindo / var / log / secure no servidor
# tail -f /var/log/secure
...
Feb 24 06:12:16 fort sshd[3064]: Connection closed by 97.113.252.17
Aqui é o que eu recebo seguindo outro servidor Eu - posso-- logar em
# tail -f /var/log/secure
...
Feb 23 22:14:12 cedar sshd[2187]: Accepted publickey for cedar from 192.168.56.1 port 53004 ssh2
Feb 23 22:14:12 cedar sshd[2187]: pam_unix(sshd:session): session opened for user cedar by (uid=0)
Eu então tentei criar uma chave pública no próprio servidor, adicionando-a ao ~ / .ssh / authorized_keys do servidor. Eu tenho o mesmo fracasso
$ ssh -o PreferredAuthentications=publickey localhost
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).
e
# tail -f /var/log/secure
...
Feb 24 06:30:37 fort sshd[3841]: Connection closed by ::1
Em seguida, tentei executar o sshd no modo de depuração em outra porta. Eu - era - capaz de logar desta vez.
# /usr/sbin/sshd -d -p 27
e no mesmo servidor ...
$ ssh -p 27 -o PreferredAuthentications=publickey localhost
Last login: Fri Feb 24 06:34:37 2017 from 97-113-252-17.tukw.qwest.net
Environment:
LANG=en_US.UTF-8
USER=fort
...
$
Para confirmar que o sshd não começou a funcionar porque eu estava executando no modo de depuração, iniciei-o normalmente. Mais uma vez, consegui fazer o login com êxito.
# /usr/sbin/sshd -p 27
#
e
$ ssh -p 27 -o PreferredAuthentications=publickey localhost
Last login: Fri Feb 24 06:39:30 2017 from localhost
[fort@fort ~]$
e
# tail -f /var/log/secure
...
Feb 24 06:46:58 fort sshd[4595]: Server listening on 0.0.0.0 port 27.
Feb 24 06:46:58 fort sshd[4595]: Server listening on :: port 27.
Feb 24 06:48:13 fort sshd[4629]: Accepted publickey for fort from ::1 port 51302 ssh2
Feb 24 06:48:13 fort sshd[4629]: pam_unix(sshd:session): session opened for user fort by (uid=0)
Mudei o LogLevel para DEBUG e reiniciei o sshd nas duas portas 22 e 27.
Aqui é onde a conexão da porta 22 falha:
debug1: trying public key file /home/fort/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 502/502 (e=0/0)
debug1: trying public key file /home/fort/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for fort from ::1 port 44994 ssh2
Aqui é onde a conexão da porta 27 é bem-sucedida
debug1: trying public key file /home/fort/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/fort/.ssh/authorized_keys, line 6
Found matching RSA key: 8f:87:0e:15:b5:88:49:04:b7:34:79:9d:7e:c2:8d:fa
O que pode estar me permitindo usar autenticação de chave pública na porta 27, mas não na porta 22? Poderia haver configurações alternativas usadas pelo /etc/init.d/sshd? O que devo tentar em seguida para obter autenticação de chave pública funcionando na porta 22?
O sistema está executando o selinux no modo enforcing? Nesse caso, você restaurou o contexto no arquivo authorized_keys?
O SELinux pode impedir que o sshd leia um arquivo authorized_keys quando ele foi modificado.
Meu tipo SELinux ~ / .ssh / authorized_keys foi configurado incorretamente com httpd_sys_content_t. Provavelmente, isso foi feito porque o conteúdo do apache estava sendo exibido diretamente do diretório inicial.
$ ls -lZ .ssh/authorized_keys
-rw-------. fort fort unconfined_u:object_r:httpd_sys_content_t:s0 .ssh/authorized_keys
A razão pela qual eu consegui fazer o ssh trabalhar na porta 27 foi que o processo tinha o tipo "unconfined_t", não "sshd_t".
$ ps axZ | grep /usr/sbin/sshd | grep -v grep
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 505 ? Ss 0:00 /usr/sbin/sshd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 942 ? Ss 0:00 /usr/sbin/sshd -p 27
Aqui está a correção. restorecon altera o tipo de httpd_sys_content_t de volta para ssh_home_t.
# restorecon -vR .ssh
restorecon reset /home/fort/.ssh context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/authorized_keys context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/known_hosts context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/authorized_keys2 context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/id_rsa.pub context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/id_rsa context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
Agora ...
$ ssh -o PreferredAuthentications = localhost de publickey Último acesso: Sábado Fev 25 16:13:45 2017 De 97-113-252-17.tukw.qwest.net [fort @ fort ~] $
Tags ssh networking linux