Fehler beim Herstellen einer Verbindung zum Server über SSH - "Server hat die Zuweisung von pty abgelehnt"

Ich habe einen STRATO V-PowerServer, der mit Ubuntu 10.10 für meine Sachen läuft, habe aber in letzter Zeit Probleme mit der Verbindung zum Server über ssh.

Grundsätzlich habe ich nur SSH-Zugriff auf den Server und kann bei Bedarf in einen Wiederherstellungsmodus booten, in dem sich alle meine Daten befinden / reparieren, damit ich alle Korrekturen am System vornehmen kann.

Das Problem ist, dass beim Versuch, über ssh eine Verbindung zum Server herzustellen, folgende Fehlermeldung angezeigt wird:

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

Die Shell öffnet sich also nicht und ich kann keine Befehle eingeben. Ich habe bereits versucht, nach "Server hat sich geweigert, pty zuzuweisen" zu googeln, konnte aber nichts finden, was geholfen hat, obwohl das Problem bereits anderen Personen passiert ist. Außerdem wird manchmal sogar ein anderer Fehler angezeigt: "Pty-Zuweisungsanforderung auf Kanal 0 fehlgeschlagen" anstelle des anderen Fehlers. Für dieses Problem konnte ich nur Folgendes finden:

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

Aber leider hat es nicht geholfen ...

Hat jemand eine Idee, warum dieser Fehler verursacht wird und was ich versuchen könnte, ihn zu beheben?

Wäre toll, wenn du mir Tipps geben könntest. Ich kenne einige grundlegende Dinge und weiß, wie man mit meinem Server arbeitet, aber wenn es so tief in die Problemlösung geht, bin ich an meinen Grenzen ... ;-) Danke!

Zusatz 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

Haben Sie versucht, Pty- und Tty-Geräte neu zu erstellen?

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

Es scheint ein bekanntes Problem auf virtuellen Servern zu sein ...

Wenn Sie keinen Zugriff auf eine Shell haben, können Sie versuchen, den Befehl über ssh zu senden:

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

Bearbeitet, um Ihren Kommentar wiederzugeben:

Wenn Sie eine Chroot verwenden, müssen Sie auch / proc, / dev und / sys bereitstellen:

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

Es sollte jetzt funktionieren.

Wenn Sie Konsolenzugriff haben

mount devpts /dev/pts -t devpts

Als ich auf diesen Fehler gestoßen bin, habe ich ihn behoben, um zu bestätigen, dass das udev-Paket installiert war und ausgeführt wurde. Udev kümmert sich darum, Geräteknoten zu erstellen, wenn sie benötigt werden, wie z. B. das PTS / x, das von ssh benötigt wird. Versuche es.

Versuche dies:

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

Ich musste eine Kombination aus dem machen, was hier gepostet wird. Meine Berechtigungen waren falsch und /dev/ptswurden bereits bereitgestellt.

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

Verwenden Sie diese Option, um zu überprüfen, ob Ihre Berechtigungen korrekt sind.

grep devpts /proc/mounts

Überprüfen Sie auch /dev/pts. Es sollte 755 sein und im Besitz von root sein.

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

Überprüfen Sie die Datei sshd_config. PermitTTY sollte nicht auf no gesetzt werden. Wenn dies der Fall ist, kommentieren Sie es aus oder setzen Sie es auf Ja. Starten Sie dann sshd neu.

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