☰

rsync: Permissão negada (chave pública) com SSH

tag-icon • tag-icon linux ssh permissions rsync cron
rsync: Permissão negada (chave pública) com SSH

Eu tenho um servidor no qual me conecto em SSH com meus arquivos principais, como id_rsa.pub. Estou usando o Debian no lado do cliente e do servidor.

Segui um tutorial para desabilitar a autenticação root e o uso de senha para maior segurança (configurando o /etc/ssh/sshd/sshd_configarquivo no servidor).

Até agora, eu poderia facilmente rsyncsincronizar meus arquivos do meu computador para o servidor.

Alguns dias atrás, Eu usei um cron jobjob e para isso tive que redefinir minha senha root no lado do servidor.

Desde então, tem sido impossível usar rsyncin SSH; Recebo a seguinte mensagem:

[email protected]: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far)[sender]
rsync error: unexplained error (code 255) at io.c(235)[sender=3.1.3]

Existem alguns tópicos semelhantes, mas acho que meu caso é um pouco diferente porque acho que o problema é devido à redefinição de minha senha no servidor. Também fiz uma pergunta no site Ask Ubuntu, mas acho que talvez as pessoas aqui sejam mais especialistas em questões de permissão.

Não tenho ideia de como resolver o problema (gerencio um pouco em comandos de terminal, mas não sou especialista em informática). Você poderia me ajudar por favor?

Apenas para sua informação, encontre o tutorial ajustando a /etc/ssh/sshd_configsenha para não usar:

#Uncomment or add the following line. 
#This allows the server to give its DSA footprint in case of an ssh connection.
HostKey /etc/ssh/ssh/ssh_host_dsa_key

#Then set the next parameter to 20s (for example). 
#This is the time during which a connection without being logged in will be opened. 
#If we had kept the good old password technique, leave 2 or 3 minutes to type it, it's not too much. 
#But since we're using the key now, we'll be logged in immediately. #So we can really reduce the thing and put it down to 20 seconds for example.
LoginGraceTime 20s

#this is the maximum number of attempts before being thrown by the server.... 
#Since with the key, no possible error, you can put it to 1 possible test.
MaxAuthTries 1

#Then, we will tell the SSH server where the keys are and tell it that we will use them as an authentication method
PubkeyAuthentication yes
AuthorizedKeysFile.ssh/authorized_keys

#And of course, we'll disable all other authentication methods
RSAAuthentication no.
UsePAM no
KerberosAuthentication no
GSSAPIA Authentication no.
PasswordAuthentication no

#Then, we will tell that we only allow users of the sshusers group (for more security)
AllowGroups sshusers

#The MaxStartups setting indicates the number of un-authenticated ssh connections you can launch at the same time. 
#2 is more than enough, knowing that with the keys, it's instantaneous.
MaxStartups 2

Responder1

Oh não!

Acabei de encontrar a solução... Meu comando foi:

sudo rsync -avz -e "ssh -p <port>" <source> <destination>

Mas eu tive que fazer isso de forma simples (sem sudo):

rsync -avz -e "ssh -p <port>" <source> <destination>

Não tenho certeza sobre a causa, mas acho que o rootusuário do meu computador desktop não tinha permissão para acessar meu servidor em SSH, pois a chave era apenas para o meu classicusuário Desktop (portanto, sem sudo).

Alguém pode confirmar? Obrigado.

informação relacionada