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".
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

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:

http://blog.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
florianbaethge
  • 225
  • 1
  • 3
  • 8
  • 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 '11 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 '11 at 18:18

5 Answers5

7

If you have console access

mount devpts /dev/pts -t devpts
Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Andre
  • 71
  • 1
  • 1
  • 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 '14 at 06:50
  • This worked for me, but I need to do it on every reboot now. How do I automate this? – Andrew Savinykh Mar 28 '18 at 22:44
3

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

root@mydomain.de:~# /sbin/MAKEDEV tty
root@mydomain.de:~# /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 root@mydomain.de "/sbin/MAKEDEV tty"
florian@localmachine:~$ ssh root@mydomain.de "/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.

petrus
  • 5,287
  • 25
  • 42
  • 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 '11 at 20:02
  • This worked for me!!! Thank you very much for your help! – florianbaethge Feb 11 '11 at 12:37
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.

coredump
  • 12,573
  • 2
  • 34
  • 53
1

Try this:

ssh root@host "mount -o remount /dev/pts"
Giacomo1968
  • 3,522
  • 25
  • 38
Evgeniy
  • 111
  • 2
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
cokedude
  • 121
  • 2