Impossible de se connecter au serveur via SSH - «Le serveur a refusé d'allouer pty»

10

J'ai un STRATO V-PowerServer fonctionnant avec Ubuntu 10.10 pour mes affaires, mais j'ai récemment rencontré des problèmes de connexion au serveur via ssh.

Fondamentalement, tout ce que j'ai, c'est un accès ssh au serveur et si nécessaire, je peux démarrer en mode de récupération où tous mes trucs sont en / réparation afin que je puisse faire des correctifs sur le système.

Le problème est que lorsque j'essaie de me connecter au serveur via ssh, j'obtiens cette erreur:

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

Donc le shell ne s'ouvre pas et je ne peux entrer aucune commande. J'ai déjà essayé de google pour "Le serveur a refusé d'allouer pty" mais je n'ai rien trouvé qui a aidé, bien que le problème soit déjà arrivé à d'autres personnes. De plus, j'obtiens parfois même une erreur différente: "la demande d'allocation de pty a échoué sur le canal 0" au lieu de l'autre erreur. Pour ce problème, je n'ai trouvé que ceci:

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

Mais malheureusement, cela n'a pas aidé ...

Quelqu'un at-il une idée de la raison de cette erreur et de ce que je pourrais essayer de la réparer?

Ce serait génial si vous pouviez me donner des conseils. Je connais certaines choses de base et je sais comment travailler avec mon serveur mais si cela va aussi loin dans la résolution de problèmes, je suis à mes limites ... ;-) Merci!

Ajout 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
source

1

Ne vous laissez pas distraire par l'erreur pty, vous devez vérifier que votre. les fichiers du répertoire personnel de votre utilisateur ne sont pas endommagés. Créez un autre utilisateur et comparez les fichiers par défaut du nouveau répertoire des utilisateurs aux fichiers de florian.

— Patrick R

Merci ... J'ai ajouté un autre utilisateur mais les fichiers sont les mêmes. .bash_rc a une légère différence mais comme mon shell est réglé sur zsh, il ne devrait même pas essayer d'utiliser celui-ci, non? @Fussy: J'ai ajouté les dernières lignes de mon auth.log et mon daemon.log à la question. Ce truc drweb semble être un reste de l'installation d'origine, qui avait Plesk dessus (c'était toujours sur 8.04 que j'ai mis à jour il y a un certain temps)

— florianbaethge

3

Avez-vous essayé de recréer des périphériques pty et tty?

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

Cela semble être un problème connu sur les serveurs virtuels ...

Si vous n'avez accès à aucun shell, vous pouvez essayer d'envoyer la commande via ssh:

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

Modifié pour refléter votre commentaire:

Si vous utilisez un chroot, vous devez également monter / proc, / dev et / 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

Ça devrait marcher maintenant.

— petrus
source

Oui, j'ai accès lorsque j'utilise le mode de récupération (et chrootez vers / réparer): root @ h1696522: / home # / sbin / MAKEDEV tty / sbin / MAKEDEV: avertissement: impossible de lire / proc / devices root @ h1696522: / home # / sbin / MAKEDEV pty / sbin / MAKEDEV: avertissement: impossible de lire / proc / devices / sbin / MAKEDEV: avertissement: impossible de lire / proc / devices

— florianbaethge

Cela a fonctionné pour moi !!! Merci beaucoup pour votre aide!

— florianbaethge

7

Si vous avez accès à la console

mount devpts /dev/pts -t devpts

— André
source

1

Si vous pouvez SSH en tant que root (et parfois les systèmes sont configurés pour le permettre), vous pouvez utiliser cette méthode ci-dessus via SSH. En fait, je viens de le faire. ssh root@host "mount devpts /dev/pts -t devpts"était exactement ce que le médecin avait ordonné.

— Emmaly Wilson

Cela a fonctionné pour moi, mais je dois le faire à chaque redémarrage maintenant. Comment automatiser cela?

— Andrew Savinykh

3

Les fois où j'ai rencontré cette erreur, je l'ai corrigée en certifiant que le paquet udev était installé et fonctionnait. Udev s'occupe de créer des nœuds de périphériques quand ils sont nécessaires, comme le PTS / x dont a besoin ssh. Essaie.

— coredump
source

1

Essaye ça:

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

— Evgeniy
source

0

J'ai dû faire une combinaison de ce qui est affiché ici. Mes autorisations étaient incorrectes et /dev/ptsétaient déjà montées.

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

Utilisez-le pour vérifier que vos autorisations sont correctes.

grep devpts /proc/mounts

Vérifiez également /dev/pts. Il doit être 755 et appartenir à root.

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

Vérifiez le fichier sshd_config. PermitTTY ne doit pas être défini sur no. Si c'est le cas, mettez-le en commentaire ou réglez-le sur oui. Redémarrez ensuite sshd.

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

— cokedude
source