Brak połączenia z serwerem przez SSH - „Serwer odmówił przydzielenia pty”

10

Mam STRATO V-PowerServer z Ubuntu 10.10 dla moich rzeczy, ale ostatnio mam problemy z połączeniem z serwerem przez ssh.

Zasadniczo wszystko, co mam, to dostęp ssh do serwera i, jeśli to konieczne, mogę uruchomić system w trybie odzyskiwania, w którym wszystkie moje rzeczy są w / naprawione, dzięki czemu mogę dokonać wszelkich poprawek w systemie.

Problem polega na tym, że kiedy próbuję połączyć się z serwerem przez ssh, pojawia się ten błąd:

Using username "florian".
[email protected]'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

Więc powłoka się nie otwiera i nie mogę wprowadzać żadnych poleceń. Próbowałem już wyszukać w Google „Serwer odmówił przydzielenia pty”, ale nie mogłem znaleźć niczego, co pomogłoby, chociaż problem ten zdarzał się wcześniej innym osobom. Dodatkowo czasami czasami pojawia się inny błąd: „Żądanie alokacji pty nie powiodło się na kanale 0” zamiast innego błędu. W przypadku tego problemu mogłem znaleźć tylko:

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

Ale niestety nie pomogło ...

Czy ktoś ma pojęcie, dlaczego ten błąd jest spowodowany i co mogę spróbować naprawić?

Byłoby świetnie, gdybyś mógł dać mi wskazówki. Znam kilka podstawowych rzeczy i wiem, jak pracować z moim serwerem, ale jeśli zajdzie tak głęboko w rozwiązywaniu problemów, jestem na granicy ... ;-) Dzięki!

Dodatek 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
źródło
1
Nie daj się zwieść błędowi pty, powinieneś to sprawdzić. pliki w katalogu domowym użytkownika nie są uszkodzone. Utwórz innego użytkownika i porównaj pliki domyślne w nowym katalogu użytkowników z plikami dla florian.
Patrick R
Dziękuję ... Dodałem innego użytkownika, ale pliki w nim są takie same. .bash_rc ma niewielką różnicę, ale ponieważ moja powłoka jest ustawiona na zsh, nie powinna nawet próbować jej używać, prawda? @Fussy: Do pytania dodałem ostatnie wiersze mojego auth.log i mojego daemon.log. Wygląda na to, że drweb to pozostałość po oryginalnej instalacji, w której był Plesk (wciąż był 8.04, którą zaktualizowałem jakiś czas temu)
florianbaethge

Odpowiedzi:

3

Czy próbowałeś odtworzyć urządzenia pty i tty?

[email protected]:~# /sbin/MAKEDEV tty
[email protected]:~# /sbin/MAKEDEV pty

Wydaje się, że jest to znany problem na serwerach wirtualnych ...

Jeśli nie masz dostępu do żadnej powłoki, możesz spróbować wysłać polecenie przez ssh:

florian@localmachine:~$ ssh [email protected] "/sbin/MAKEDEV tty"
florian@localmachine:~$ ssh [email protected] "/sbin/MAKEDEV pty"

Edytowane w celu odzwierciedlenia Twojego komentarza:

Jeśli używasz chroota, musisz także zamontować / proc, / dev i / 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

Powinno już działać.

petrus
źródło
Tak, mam dostęp, gdy korzystam z trybu odzyskiwania (i chroot do / naprawy): root @ h1696522: / home # / sbin / MAKEDEV tty / sbin / MAKEDEV: ostrzeżenie: nie można odczytać / proc / devices root @ h1696522: / home # / sbin / MAKEDEV pty / sbin / MAKEDEV: ostrzeżenie: nie można odczytać / proc / devices / sbin / MAKEDEV: ostrzeżenie: nie można odczytać / proc / urządzenia
florianbaethge
To działało dla mnie !!! Bardzo ci dziękuje za pomoc!
florianbaethge
7

Jeśli masz dostęp do konsoli

mount devpts /dev/pts -t devpts
Andre
źródło
1
Jeśli możesz SSH jako root (a czasem systemy są skonfigurowane, aby na to zezwalać), możesz użyć tej metody powyżej za pośrednictwem SSH. W rzeczywistości właśnie to zrobiłem. ssh root@host "mount devpts /dev/pts -t devpts"było dokładnie tym, co zalecił lekarz.
Emmaly Wilson
To działało dla mnie, ale muszę to teraz robić przy każdym ponownym uruchomieniu. Jak to zautomatyzować?
Andrew Savinykh
3

Kiedy napotkałem ten błąd, naprawiłem go, potwierdzając, że pakiet udev został zainstalowany i działa. Udev zajmuje się tworzeniem węzłów urządzeń, gdy są potrzebne, takich jak PTS / x, które są potrzebne ssh. Spróbuj.

rdzeń rdzeniowy
źródło
1

Spróbuj tego:

ssh root@host "mount -o remount /dev/pts"
Evgeniy
źródło
0

Musiałem zrobić kombinację tego, co tu zamieszczono. Moje uprawnienia były błędne i /dev/ptszostały już zamontowane.

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

Użyj tego, aby sprawdzić, czy twoje uprawnienia są prawidłowe.

grep devpts /proc/mounts

Sprawdź również /dev/pts. Powinien to być 755 i należy do roota.

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

Sprawdź plik sshd_config. Parametr PermitTTY nie powinien być ustawiony na no. Jeśli jest albo komentować, albo ustawić na „tak”. Następnie uruchom ponownie sshd.

vi /etc/ssh/sshd_config
service sshd restart
systemctl restart sshd
Cokedude
źródło