I think I broke the installation of ncurses on my Arch Linux VPS. Now I can't login with SSH, I get this error:

$ ssh me@xyz.com
Last login: Mon Oct 26 08:56:59 2015 from
-bash: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory
Connection to xyz.com closed.

I'm not really sure what to do now. I have a tmux session running on the server. Is there maybe some way I can attach to it from my local machine by forwarding ports or something?

  • 1
    I don't think so. SSH runs every command in bash so if this one is broken, I don't see any solution. – Jakuje Oct 26 '15 at 13:29
  • 1
    You can use sftp to re-upload the necessary libraries... – Jan Oct 26 '15 at 13:46
  • @Jan stfp is not working, Filezilla says "unexpected EOF" and my sftp program simply says "connection closed" when trying to log in – nanny Oct 26 '15 at 14:37
  • @nanny Then you are almost dead (uh, looks like ssh uses the shell to open up sftp)… Unless by chance you found another SSH session still on. – Arthur2e5 Oct 26 '15 at 14:54
  • Are there any other users on that system who have a shell other than bash? – Mark Plotnick Oct 26 '15 at 16:01

Thanks to my VPS hosting provider (DigitalOcean), I was able to boot into an Arch ISO, mount my system's partition, and perform a system upgrade with pacman like this:

$ mount /dev/vda1 /mnt/arch
$ pacman --root /mnt/arch --cachedir /mnt/arch/var/cache/pacman/pkg --config /mnt/arch/etc/pacman.conf -Syyu

which fixed the problem.

Moral of the story: don't do partial upgrades on Arch Linux.


If your login shell won't even start then you cannot log in. The client sends a string to the server and it's up to the user's login shell on the server to interpret the string. The client has no way to tell the server “run some other command instead”.

This is a security mechanism: if a user's shell is restricted in what it can do, then the user can't do anything that it doesn't permit.

If you've blocked access to all the accounts on the system, then you'll have to use some method that bypasses normal logins, such as physical access or a recovery console.

Some tips:

  • When doing maintenance, always keep a root shell open and don't close it until you've tested that everything works.
  • Install a statically-linked shell on an account with sudoer rights. I don't see any prepackaged by Arch. Debian has a few; you could just copy the executable and add it to /etc/shells.
  • Make sure that you have a way to get root even if some things are broken; either set root's shell to bash-static or sash something similar, or set up a toor account (alternate way for root to log in). Keep in mind that sudo could break too; you may want to have an emergency password on the toor account that's randomly generated (unique and not memorized) and written down on a piece of paper that you keep in a safe.

Did you try:

ssh -t username@hostname /bin/sh

Also you can try copy by scp missing libncursesw.so.5 to your remote.

  • 4
    ssh runs commands via the shell, so your line would end up being run as something like bash -c /bin/sh, so that won't work. – nanny Oct 26 '15 at 14:06
  • Also scp is throwing the same error. – nanny Oct 26 '15 at 14:38
  • Hm.. what with sshfs ? Also doesn't work? – Mariusz Oct 26 '15 at 14:41
  • @nanny Oh if really everything goes through bash then I see no solution whatsoever. – phk Oct 26 '15 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.