After scp-ing a shellshock-patched bash binary to an openSUSE 12.2 Linux VM and replacing the login shell with it, no user can log in via ssh or the console. As it turned out, the executable bit got lost during transfer, despite using the -p switch.

I tried to repair this by mounting the filesystem on the Linux Xen host and doing chmod +x /mnt/usr/local/bin/bash, but the situation did not improve. Will rebooting the guest VM help?

This is what I see on console:

xxx login: root
Last login: xxx
Have a lot of fun...
 -- root: no shell: permission denied

This appears in /mnt/var/log/messages

on ssh login:

sshd: User root not allowed because shell /bin/bash is not executable
sshd: input_userauth_request: invalid user root [preauth]
sshd: Postponed keyboard-interactive for invalid user root from x.x.x.x port xxxxx ssh2 [preauth]

on console login:

systemd-logind: New session x of user root.
login: ROOT LOGIN ON xvc0
console-kit-daemon: WARNING: Unable to spawn /etc/ConsoleKit/run-session.d/dbus_at_console.ck: Failed to execute child process "/etc/ConsoleKit/run-session.d/dbus_at_console.ck" (Permission denied)
systemd-logind: Removed session x.

And this is how I caused the problem:

# my /bin/bash has been a symlink to /usr/local/bin/bash since the first shellshock patch
scp -p buildhost:/tmp/bash /tmp/bash
# then I forgot to do chmod +x /tmp/bash
# then I forgot to do chsh -s /usr/bin/zsh, logout and login
mv /tmp/bash /usr/local/bin/bash && \
mv /bin/bash /var/tmp/bash-unpatched && \
chmod -x /var/tmp/bash-unpatched && \
ln -s /usr/local/bin/bash /bin/bash

Replacing the /bin/bash symlink by a real binary did not help either.

  • 1
    What if you mount the filesystem in Xen again, but edit /etc/passwd and change your shell to /bin/dash (or another installed shell)? Then you can login and fix the bash issue. (if this works I'll make it an answer) – Jim G. Sep 29 '14 at 21:41
  • I tried that several times before. No change. – Christian Pietsch Sep 29 '14 at 21:45
  • 3
    Is this an extX filesystem? You can't mount those more than once. You'll need to shut down the guest, then make the change. – EEAA Sep 29 '14 at 22:19
  • 1
    Yes it is. Luckily, I found a user who was still logged into the guest VM. In his terminal, I found out that the guest filesystem modifications I had made from the Xen host had not taken effect. So I did sudo chmod +x /usr/local/bin/bash from that terminal again, and this time it worked. Thanks for the great advice! I should have mentioned that I am a Xen newbie, but you probably realized. – Christian Pietsch Sep 30 '14 at 7:20

You will have to reboot. File permission changes done from the hypervisor to a file system in use by a guest won't be detected by the guest.

In the future when doing this type of 'update' have a separate shell session open to the server you're updating, just in case things go south.


It looks like you have some access to the server. There are various approaches you can try.

You should have a working ssh client, try using ssh to either fix the permissions, or login with a different shell.

ssh root@host chmod +x /bin/bash
ssh root@host /bin/dash

If you can connect to a non-root user, try sudo.

sudo chmod +x /bin/dash
sudo /bin/bash 

Or just use su from the non-root user

su -c 'chmod +x /bin/bash'
su -c '/bin/dash'

You should be able to find the available shells in /etc/shells.

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.