☰

rsync: Permiso denegado (clave pública) con SSH

tag-icon • tag-icon linux ssh permissions rsync cron
rsync: Permiso denegado (clave pública) con SSH

Tengo un servidor al que me conecto en SSH con mis archivos clave como id_rsa.pub. Estoy usando Debian en el lado del cliente y del servidor.

Seguí un tutorial para deshabilitar la autenticación de root y el uso de contraseña para mayor seguridad (configurando el /etc/ssh/sshd/sshd_configarchivo en el servidor).

Hasta ahora, podía utilizarlo fácilmente rsyncpara sincronizar mis archivos desde mi computadora al servidor.

Hace unos días, Usé un trabajo crontrabajo y para eso tuve que restablecer mi contraseña de root en el lado del servidor.

Desde entonces, me ha sido imposible usarlo rsyncen SSH; Recibo el siguiente mensaje:

[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]

Hay algunos temas similares, pero creo que mi caso es un poco diferente porque creo que el problema se debe a restablecer mi contraseña en el servidor. También hice una pregunta en el sitio Ask Ubuntu, pero creo que tal vez la gente aquí sea más experta en cuestiones de permisos.

No tengo idea de cómo solucionar el problema (me las arreglo un poco con los comandos del terminal, pero no soy un experto en informática). ¿Usted me podría ayudar por favor?

Solo para su información, busque el tutorial que modifica la /etc/ssh/sshd_configcontraseña para no usarla:

#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

Respuesta1

¡Oh, no!

Acabo de encontrar la solución... Mi comando fue:

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

Pero tuve que hacerlo simplemente (sin sudo):

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

No estoy seguro de la causa, pero creo que al rootusuario de mi computadora de escritorio no se le permitió acceder a mi servidor en SSH ya que la clave era solo para mi classicusuario de escritorio (es decir, sin sudo).

¿Alguien puede confirmarlo? Gracias.

información relacionada