Proxy PuTTY X11: se intentó un protocolo de autorización incorrecto


13

Estoy tratando de conectarme a un servidor Ubuntu para trabajar en Qt-creator. Antes de que todo salga mal, seguí este tutorial. Descargué masilla y Xming y todo funcionaba bien.

entonces, de repente, mientras trabajaba en Qt-creator no pude guardar ningún cambio. Entonces, cerré Qt-creator y reinicié la sesión de masilla. me preguntó sobre el nombre de usuario y la contraseña (como de costumbre) luego, después de iniciar sesión en el servidor y cuando intenté ejecutar Qt-creator (como de costumbre), aparece el siguiente mensaje:

PuTTY X11 proxy: wrong authorisation protocol attempted
Can't open display: localhost:10.0

Entonces, traté de resolver el problema usando dos enfoques encontrados en Internet:

el primero es obtener el dpyname protoname hexkeyuso:

xauth list 

que debería devolver la clave que luego se podría agregar usando:

xauth add

Sin embargo, no funcionó ya que el xauth listcomando no devolvió nada.

la segunda solución fue ir a:

./etc/ssh/sshd_config

abra el archivo: sshd_config y edite la ForwardX11Trustedlínea para leer yes, y si no existe dicha línea, agréguela.

ForwardX11Trusted yes

luego reinicie el servidor ssh y debería funcionar.

Sin embargo, tampoco funcionó. No pude abrir el archivo sshd_configusando xdg-openo gedity aparece el mismo mensaje nuevamente.

Entonces, ¿por qué sucede esto y cuál es la solución?


La buena noticia es: ahora puedo abrir el archivo: sshd_configusando el sudo nanocomando y agregar la línea: ForwardX11Trusted yes.. la mala noticia es: ¡después del "paso de adición" el problema aún existe!
— McLan

¿Cuál es el comando completo cuando lo usas xauth add?
— Nate de Kalamazoo

ForwardX11Trustedes una opción para el cliente OpenSSH, no para el servidor. Agregarlo podría evitar que se sshdinicie, dependiendo de la versión.
— Gert van den Berg

Respuestas:


7

Mientras estaba conectado como su, después de algunos errores tipo "proxy PuTTY X11: intento de protocolo de autorización incorrecto", me di cuenta de que era un problema de autenticación. Luego recordé copiar el archivo .Xauthority de mi propio perfil / directorio de inicio a / root. ¡Problema resuelto!


Esto parece una respuesta a un problema diferente (aunque con los mismos síntomas).
— DavidPostill

Esto funcionó para Raspbian Jessie en RaspberryPi
— Dexter

Esto también funcionó para mí en RPI. Desde PuTTy en Win10 simple leafpadfuncionó bien, pero sudo leafpadarrojó un error en la descripción anterior. La copia .Xauthorityfuncionó a la perfección. ¡Muchas gracias!
— Petr Újezdský

ok para el problema de autorización ... pero todavía me da "No se puede abrir la pantalla:" ... alguna idea
— ZEE

2

Resuelto

Lo resolví usando una mezcla de los dos mencionados anteriormente.

1. Agregué la siguiente línea a '/ etc / ssh / sshd_config'

ForwardX11Trusted yes

2. Instalé xauth usando

sudo apt-get install xauth

xauth listestaba vacío para mí antes de reiniciar. Sin embargo, se pobló después del reinicio. Lo hice xauth listdespués de probarlo con masilla.

Luego reinicié ssh y funcionó. ¡Hurra!

Nota: Lo que realmente hice fue reiniciar mi Raspberry Pi


3
ForwardX11Trusted no es una opción válida para sshd_config. Es un parámetro de cliente, no un parámetro de daemon de servidor
— HeatfanJohn

Lo había hecho hace bastante tiempo. No lo se ahora.
— Dheeraj Bhaskar

2

Tuve un problema similar en un servidor en el trabajo porque la carpeta de inicio no tenía espacio en disco. Después de iniciar sesión, no pudo escribir el archivo Xauthority y ... no pudo reenviar.

Liberar espacio resolvió el problema.

Me imagino que tendría un problema similar si los permisos de la carpeta de inicio o .Xauthority se configuraran incorrectamente, por lo que no tenía acceso de escritura.


1

En mi caso, noté que podía abrir la pantalla con root, pero estaba haciendo una su - grid, y esta cuadrícula de usuario era la que tenía el problema,

la solución fue cerrar esta sesión y abrir una nueva sesión directamente con grid, y funcionó, algo sobre hacer el su - grid estaba fallando ...


0

Tuve un problema similar en un servidor. El motivo fue que el usuario obtuvo un número incorrecto de visualización (DISPLAY = localhost: 10.0). Cuando el usuario se conecta al servidor a través de SSH (como usuario llamado test1) obtiene DISPLAY = localhost: 11.0. Cuando se conecta como otro usuario y luego se convierte en usuario (prueba1), obtiene un número incorrecto de visualización (DISPLAY = localhost: 10.0). Cuando configuro el número derecho de DISPLAY (DISPLAY = localhost: 11.0) funciona.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.