gitolite: la solicitud de asignación de PTY falló en el canal 0

Question

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

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 que está bien que supongo que (además de la advertencia ... PTY)

Ahora, de vuelta al servidor, me gustaría jenkins para poder conectarme a mi repositorio de git también.

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

Inicio de sesión en arrakis como git usuario (el usuario 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 sospechoso, así que sacó de authorized_keys y trató 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

Answer 1

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 proporcione -T, o la opción de configuración RequestTTY esté configurada en no (esta última estaba disponible por primera vez en OpenSSH 5.9). La diferencia en el comportamiento surge en cómo el cliente trata con tener esta solicitud denegada por el servidor (por ejemplo, porque no-pty se da en el authorized_keys de entrada aplicable):

• Antes de OpenSSH 5.6:
  • el cliente mostrará la “solicitud de asignación de PTY” mensaje, y
  • continuar en modo
• “nO PTY” en abre SH 5.6-5.8:
  • el cliente se mostrará la “solicitud de asignación de PTY” mensaje, y
  • abortar la conexión
• En OpenSSH 5.9 (y versiones posteriores):
  • el cliente mostrará el mensaje "Error en la solicitud de asignación de PTY" y
  • si no se proporcionó -t, y RequestTTY es auto (el valor predeterminado), entonces
    • siguen en el modo de “NO PTY”
  • más (-t dado, o la opción de configuración RequestTTY es yes o force)
    • abortar la conexión

Desde ssh de su servidor aparece a abortar cuando se rechaza su solicitud de asignación de pty, es probable que esté ejecutando OpenSSH 5,6-5,8 (al menos por el cliente binario). Del mismo modo, como la estación de su trabajo ssh muestra la advertencia, pero continúa, probablemente ejecute un OpenSSH desde antes de 5.6, o uno que sea 5.9 o posterior. Puede verificar sus versiones con ssh -V.

Puede impedir que la diferencia de comportamiento utilizando siempre dando la opción -T para que el cliente (cualquier versión) no solicita una Pty desde el servidor:

ssh -T git@YourServer 

Durante el acceso Git real, el cliente nunca intenta para asignar un 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 de Git; solo afectó su prueba de autenticación (dependiendo de la versión del cliente OpenSSH que estaba ejecutando) porque la falta de un argumento de comando causa una solicitud de asignación pty implícita (para una sesión "interactiva").

---

Desde el OpenSSH 5.6 release announcement:

• canal de muertes cuando las solicitudes de asignación de pty fallan. Fija cliente pegado si el servidor rechaza la asignación Pty (bz # 1698)

bz#1698 parece ser una referencia a una report logged in the “Portable OpenSSH” Bugzilla.

---

Desde el mensaje de registro de entrada de OpenSSH clientloop.c rev 1.234:

mejorar nuestro comportamiento cuando la asignación TTY falla: si estamos en RequestTTY = modo automático (por defecto), entonces no tratar al TTY error de asignación como fatal, pero basta con restaurar el TTY local al modo cocido y continuar. Esto es más elegante en dispositivos que nunca asignan TTY.

Si RequestTTY se establece en "sí" o "forzar", la falla en asignar un TTY es fatal.

Answer 2

saber por qué sólo afecta al acceso local, lo que se necesita para depurarlo como in this article.

ssh -vvv git@arrakis 

Si el archivo de configuración del demonio SSH /etc/ssh/sshd_config contiene la línea SyslogFacility AUTHPRIV (des-comentado), se puede echar un vistazo a los registros de SSH en /var/log/secure.

Dicho esto, consulte GitoliteV3: No creo que use no-pty en la configuración actual.

Answer 3

Al lado de Chris Johnsen muy completo nota respuesta que da explícitamente el comando info no mostrará la advertencia PTY:

ssh git@arrakis info 

En ese caso SSH tiene en cuenta que esto no es una sesión interactiva y no solicitar una TTY.