gitolite - programacion - movistar tv españa

gitolite: error en la solicitud de asignación de PTY en el canal 0 (3)

Tanto jenkins (el ci-server) como mi repositorio git están alojados en el mismo servidor. El git repo está controlado por gitolita. Si accedo al repositorio desde afuera, por ejemplo, desde mi estación de trabajo obtengo

ssh git@arrakis PTY allocation request failed on channel 0 hello simou, this is git@arrakis running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4 R W testing Connection to arrakis closed.

Lo cual está bien, supongo (además de la advertencia PTY ...)

Ahora, de vuelta al servidor, me gustaría que jenkins también pueda conectarse a mi repositorio git.

jenkins@arrakis:~> ssh git@arrakis gitolite: PTY allocation request failed on channel 0

Iniciar sesión en arrakis como usuario git (el usuario de gitolite):

git@arrakis:~> cat ~git/.ssh/authorized_keys command="/home/git/gitServer/gitolite/src/gitolite-shell jenkins",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-rsa <PUBLIC-KEY> jenkins@arrakis

La entrada "no-pty" me hizo sospechosa, así que la eliminé de authorized_keys y lo intenté de nuevo:

jenkins@arrakis:~> ssh git@arrakis hello jenkins, this is git@arrakis running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4 R W testing Connection to arrakis closed.

Esto resuelve mi problema en este punto, pero no estoy seguro de las consecuencias de eliminar "no-pty".

¿Y por qué solo afecta el acceso local, ya que el acceso remoto no parece verse afectado en absoluto?

openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon

Junto a la respuesta muy completa de Chris Johnsen, tenga en cuenta que dar explícitamente el comando de info no mostrará la advertencia de PTY:

ssh git@arrakis info

En ese caso, SSH considera que esta no es una sesión interactiva y no solicitará un TTY.

La diferencia de comportamiento entre su estación de trabajo y su servidor probablemente se deba al uso de diferentes versiones del cliente OpenSSH ( ssh ) en cada sistema (no remoto frente a local). El cliente solicitará una pty del servidor a menos que se indique -T , o la opción de configuración de RequestTTY esté configurada en no (la última estuvo disponible primero en OpenSSH 5.9). La diferencia en el comportamiento surge en la forma en que el cliente trata que el servidor no-pty esta solicitud (por ejemplo, porque no-pty se da no-pty en la entrada de authorized_keys aplicable):

Antes de OpenSSH 5.6:
- el cliente mostrará el mensaje "Error en la solicitud de asignación PTY", y
- continuar en modo "no pty"
En OpenSSH 5.6-5.8:
- el cliente mostrará el mensaje "Error en la solicitud de asignación PTY", y
- abortar la conexión
En OpenSSH 5.9 (y posteriores):
- el cliente mostrará el mensaje "Error en la solicitud de asignación PTY", y
- Si no se proporcionó -t , y RequestTTY es auto (el valor predeterminado), entonces
  - continuar en modo "no pty"
- else ( -t dado, o la opción de configuración de RequestTTY es yes o force )
  - abortar la conexión

Dado que la ssh su servidor parece abortarse cuando se rechaza su solicitud de asignación de pty, probablemente está ejecutando OpenSSH 5.6-5.8 (al menos para el binario del cliente). Del mismo modo, dado que ssh la estación de trabajo muestra la advertencia, pero continúa, es probable que esté ejecutando un OpenSSH anterior a 5.6, o uno que sea 5.9 o posterior. Puedes consultar tus versiones con ssh -V .

Puede evitar la diferencia de comportamiento utilizando siempre la opción -T para que el cliente (cualquier versión) nunca solicite una pty del servidor:

ssh -T git@YourServer

Durante el acceso real a Git, el cliente nunca intenta asignar una pty porque Git le dará al cliente un comando específico para ejecutar (por ejemplo, ssh server git-upload-pack path/to/repository ) en lugar de solicitar una sesión "interactiva" (por ejemplo, ssh server ). En otras palabras, no-pty no debería haber estado causando problemas para el acceso real a Git; solo afectó sus pruebas de autenticación (dependiendo de la versión del cliente OpenSSH que estaba ejecutando) porque la falta de un argumento de comando provoca una solicitud de asignación de pty implícita (para una sesión "interactiva").

Desde el anuncio de lanzamiento de OpenSSH 5.6 :

Mata el canal cuando las solicitudes de asignación de pty fallan. Se corrigió el cliente bloqueado si el servidor rechazaba la asignación de pty (bz # 1698)

bz#1698 parece ser una referencia a un informe registrado en el Bugzilla "OpenSSH portátil" .

Desde el mensaje de check-in de OpenSSH clientloop.c rev 1.234 :

mejore nuestro comportamiento cuando falla la asignación de TTY: si estamos en RequestTTY = modo automático (el valor predeterminado), no considere el error de asignación de TTY como fatal, sino que simplemente restaure el TTY local al modo preparado y continúe. Esto es más elegante en los dispositivos que nunca asignan TTY.
Si RequestTTY se configura en "sí" o "forzar", entonces la falla en la asignación de un TTY es fatal.

Para saber por qué afecta solo al acceso local, deberá depurarlo como en este artículo .

ssh -vvv git@arrakis

Si su archivo de configuración del demonio SSH /etc/ssh/sshd_config contiene la línea SyslogFacility AUTHPRIV (sin comentarios), puede consultar los registros de SSH en /var/log/secure .

Dicho esto, echa un vistazo a GitoliteV3 : no creo que use no-pty en la configuración actual.