Error al conectarse al servidor a través de SSH: "El servidor se negó a asignar pty"

10

Tengo un STRATO V-PowerServer ejecutándose con Ubuntu 10.10 para mis cosas, pero últimamente tengo problemas para conectarme al servidor a través de ssh.

Básicamente, todo lo que tengo es acceso ssh al servidor y, si es necesario, puedo iniciar en un modo de recuperación donde todas mis cosas están en / reparación para poder hacer cualquier corrección en el sistema.

El problema es que cuando intento conectarme al servidor a través de ssh obtengo este error:

Using username "florian".
florian@mydomain.de's password:
Server refused to allocate pty
Linux hwn36335 2.6.18-028stab070.5 #1 SMP Fri Sep 17 15:37:23 MSD 2010 i686 GNU/Linux
     Ubuntu 10.10

                 Welcome to Ubuntu!
                                    * Documentation:  https://help.ubuntu.com/
                                                                              /home/florian/.zlogin:1: command not found: display_info

Entonces el shell no se abre y no puedo ingresar ningún comando. Ya he intentado buscar en Google "El servidor se negó a asignar pty", pero no pude encontrar nada que me ayudara, aunque el problema ya le ha sucedido a otras personas. Además, a veces incluso recibo un error diferente: "la solicitud de asignación de pty falló en el canal 0" en lugar del otro error. Para este problema, todo lo que pude encontrar fue esto:

http://blog.dinotools.de/2010/10/03/fehler-pty-allocation-request-failed-on-channel-0

Pero desafortunadamente no ayudó ...

¿Alguien tiene una idea de por qué se produce este error y qué podría intentar solucionarlo?

Sería genial si pudieras darme consejos. Sé algunas cosas básicas y sé cómo trabajar con mi servidor, pero si va tan profundo en la resolución de problemas, estoy en mis límites ... ;-) ¡Gracias!

Adición 1:

/var/log/auth.log

Jan 24 16:20:01 h1696522 CRON[3417]: PAM unable to dlopen(/lib/security/pam_smbpass.so): /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory
Jan 24 16:20:01 h1696522 CRON[3417]: PAM adding faulty module: /lib/security/pam_smbpass.so
Jan 24 16:20:01 h1696522 CRON[3417]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Jan 24 16:20:03 h1696522 CRON[3417]: pam_unix(cron:session): session closed for user www-data

/var/log/daemon.log

Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50003.vdb - dwr50003.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50004.vdb - dwr50004.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50005.vdb - dwr50005.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50006.vdb - dwr50006.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50007.vdb - dwr50007.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50008.vdb - dwr50008.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwr50009.vdb - dwr50009.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/dwrtoday.vdb - dwrtoday.vdb with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/updates/timestamp -    timestamp with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: /var/drweb/bases/update.drl -   update.drl with such CRC32 already exists, downloading has been skipped
Jan 24 16:00:02 h1696522 update.pl[14292]: deleting old files ...
Jan 24 16:00:02 h1696522 update.pl[14292]: moving downloaded files from temporary to working directory ...
Jan 24 16:00:02 h1696522 update.pl[14292]: sending notifications ...
Jan 24 16:00:02 h1696522 update.pl[14292]: summary => updated: 0, removed: 0 files and 0 messages
Jan 24 16:00:02 h1696522 update.pl[14292]: Finish Success:   2011-01-24 16:00:02
Jan 24 16:00:02 h1696522 update.pl[14292]: Socket path is /var/drweb/run/updateSock

— florianbaethge
fuente

1

No se desvíe por el error pty, debe verificar que su. los archivos en el directorio de inicio de su usuario no están rotos. Cree otro usuario y compare cuáles son los archivos predeterminados en el nuevo directorio de usuarios con los archivos de florian.

— Patrick R

Gracias ... He agregado otro usuario pero los archivos allí son los mismos. .bash_rc tiene una ligera diferencia, pero como mi shell está configurado en zsh, ni siquiera debería intentar usar este, ¿verdad? @Fussy: agregué las últimas líneas de mi auth.log y mi daemon.log a la pregunta. Este material de drweb parece ser parte de la instalación original, que tenía Plesk (todavía estaba en 8.04 que actualicé hace un tiempo)

— florianbaethge

3

¿Intentaste recrear dispositivos pty y tty?

root@mydomain.de:~# /sbin/MAKEDEV tty
root@mydomain.de:~# /sbin/MAKEDEV pty

Parece ser un problema conocido en servidores virtuales ...

Si no tiene acceso a ningún shell, puede intentar enviar el comando a través de ssh:

florian@localmachine:~$ ssh root@mydomain.de "/sbin/MAKEDEV tty"
florian@localmachine:~$ ssh root@mydomain.de "/sbin/MAKEDEV pty"

Editado para reflejar su comentario:

Si usa un chroot, también debe montar / proc, / dev y / sys:

root@h1696522:/# mount -o bind /proc /repair/proc
root@h1696522:/# mount -o bind /dev /repair/dev
root@h1696522:/# mount -o bind /sys /repair/sys

Debería funcionar ahora.

— petrus
fuente

Sí, tengo acceso cuando uso el modo de recuperación (y hago chroot para / reparar): root @ h1696522: / home # / sbin / MAKEDEV tty / sbin / MAKEDEV: advertencia: no se puede leer / proc / devices root @ h1696522: / inicio # / sbin / MAKEDEV pty / sbin / MAKEDEV: advertencia: no se puede leer / proc / devices / sbin / MAKEDEV: advertencia: no se puede leer / proc / devices

— florianbaethge

Esto funcionó para mí! ¡Muchas gracias por su ayuda!

— florianbaethge

7

Si tienes acceso a la consola

mount devpts /dev/pts -t devpts

— Andre
fuente

1

Si puede usar SSH como root (y a veces los sistemas están configurados para permitirlo), puede usar este método anterior a través de SSH. De hecho, lo acabo de hacer. ssh root@host "mount devpts /dev/pts -t devpts"fue exactamente lo que ordenó el médico.

— Emmaly Wilson el

Esto funcionó para mí, pero necesito hacerlo en cada reinicio ahora. ¿Cómo automatizo esto?

— Andrew Savinykh

3

Las veces que me encontré con este error lo arreglé certificando que el paquete udev estaba instalado y ejecutándose. Udev se encarga de crear nodos de dispositivo cuando son necesarios, como el PTS / x que necesita ssh. Darle una oportunidad.

— volcado de memoria
fuente

1

Prueba esto:

ssh root@host "mount -o remount /dev/pts"

— Evgeniy
fuente

0

Tuve que hacer una combinación de lo que se publica aquí. Mis permisos eran incorrectos y /dev/ptsya estaba montado.

mount -t devpts -o remount,seclabel,nosuid,noexec,uid=0,gid=5,mode=620 devpts /dev/pts

Use esto para verificar que sus permisos sean correctos.

grep devpts /proc/mounts

También consultar /dev/pts. Debe ser 755 y propiedad de root.

ls -dl /dev/pts
chmod 755 /dev/pts
chown root:root /dev/pts

Verifique el archivo sshd_config. PermitTTY no debe establecerse en no. Si es así, coméntelo o configúrelo en sí. Luego reinicie sshd.

vi /etc/ssh/sshd_config
service sshd restart
systemctl restart sshd

— coquedad
fuente