11

I have a STRATO V-PowerServer running with Ubuntu 10.10 for my stuff but lately have problems connection to the server via ssh.

Basically all I have is ssh-access to the server and if necessary I can boot into a recovery-mode where all my stuff is in /repair so that I can do any fixes on the system.

The problem is, that when I try to connect to the server via ssh I get this error:

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

So the shell doesn't open and I can't enter any commands. I've already tried to google for "Server refused to allocate pty" but couldn't find anything that helped, though the problem has happened to other people before. Additionally, I sometimes even get a different error: "pty allocation request failed on channel 0" instead of the other error. For this problem all I could find was this:

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

But unfortunately it didn't help...

Does anybody have an idea why this error is caused and what I could try to fix it?

Would be great if you could give me tips. I know some basic things and know how to work with my server but if it goes this deep into problem-solving I am at my limits... ;-) Thanks!

Addition 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
Improve this question
2
  • 1
    Don't get sidetracked by the pty error, you should verify that your . files in you user's home directory aren't broken. Create another user and compare what the default files are in the new users directory to the files for florian.
    – Patrick R
    Feb 10, 2011 at 17:23
  • Thank you... I've added another user but the files in there are the same. .bash_rc has a slight difference but since my shell is set to zsh it shouldn't even try to use this one, right? @Fussy: I've added the last lines of my auth.log and my daemon.log to the question. This drweb stuff seems to be some leftover from the original installation, which had Plesk on it (it was still on 8.04 which I upgraded a while ago)
    – florianbaethge
    Feb 10, 2011 at 18:18

5 Answers 5

Reset to default
3

Did you tried to re-create pty and tty devices ? 

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

It seems to be a known issue on virtual servers...

If you don't have access to any shell, you could try sending the command via ssh : 

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

Edited to reflect your comment :

If you use a chroot, you also have to mount /proc, /dev and /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

It should work now.

Improve this answer
2
  • Yes I have access when I use the recovery mode (and chroot to /repair): root@h1696522:/home# /sbin/MAKEDEV tty /sbin/MAKEDEV: warning: can't read /proc/devices root@h1696522:/home# /sbin/MAKEDEV pty /sbin/MAKEDEV: warning: can't read /proc/devices /sbin/MAKEDEV: warning: can't read /proc/devices
    – florianbaethge
    Feb 10, 2011 at 20:02
  • This worked for me!!! Thank you very much for your help!
    – florianbaethge
    Feb 11, 2011 at 12:37
7

If you have console access

mount devpts /dev/pts -t devpts
Improve this answer
2
  • 1
    If you can SSH as root (and sometimes systems are configured to allow it) you can use this method above via SSH. In fact, I just did. ssh root@host "mount devpts /dev/pts -t devpts" was exactly what the doctor ordered.
    – Emmaly
    Nov 26, 2014 at 6:50
  • This worked for me, but I need to do it on every reboot now. How do I automate this?
    – Andrew Savinykh
    Mar 28, 2018 at 22:44
3

The times I have encoutered this error I fixed it certifying that the udev package was installed and running. Udev takes care of creating device nodes when they are needed, like the PTS/x that are needed by ssh. Give it a try.

Improve this answer
1

Try this:

ssh root@host "mount -o remount /dev/pts"
Improve this answer
0

I had to do a combination of what is posted here. My permissions were wrong and /dev/pts was already mounted. 

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

Use this to verify that your permissions are correct. 

grep devpts /proc/mounts

Also check /dev/pts. It should be 755 and owned by root.

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

Check sshd_config file. PermitTTY should not be set to no. If it is either comment it out or set it to yes. Then restart sshd. 

vi /etc/ssh/sshd_config
service sshd restart
systemctl restart sshd
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .