I did the unthinkable the other day. I attempted to upgrade my Debian home
sherver) from Debian 10 to 11. In doing so, I fat fingered something
/etc/apt/sources.list. I then proceeded to run the usual update and upgrade
commands, not paying any attention to any output. Then I rebooted the box.
Upon rebooting the box, a short stack Intel NUC, I was greeting with an
error about my private key not being valid or accepted. Adding in
more of the same.
I was locked out.
At this point, I jumped to the conclusion that I had borked something during the upgrade and that caused the lock out. I figured the worst case scenario would be that the system would need to be rebooted with a rescue disk and sorted out that say.
Since it did appear that everything was running correctly on it, I waited a few days before digging out a keyboard and hooking the machine up to a monitor.
Fast forward a few days later, I plugged in an HDMI cable and keyboard, and attempted to log in.
Logging in with my user account didn’t work. A message flashed on the screen and
it a prompt was presented again. I was able to log into the
root account couldn’t be utilized over SSH as I keep
PermitRootLogin set to
no on my entire server fleet.
Cool, so I’m logged into the machine now. When attempting to switch to my normal
user account, I was able to see the error in all it’s glory. Something about
zsh being missing.
Fantastic, let’s just reinstall that and we should be good to go!
Not quite, turns out during the upgrade process, there was a mismatch between a
required lib and the
zsh version which resulted in
zsh being removed. After
a bit of troubleshooting, I tracked down where I had an error, got that sorted
and was able to complete the upgrade and get
Now I know what you’re thinking, “hey Josh, when are you going to tell me how to SSH into a server with a broken or missing shell?”
Simply put, you cannot.
I did some digging after the fact, and there’s no way to pass in a different
shell to run in this scenario. If there were, things like
would be rendered useless, wouldn’t they?
So that’s the hard truth of it, in a scenario where your shell is missing or
broken or set to something like
nologin that’s it, you can’t log in.
Fortunately for me, I had physical access to the server in question, but that’s not always the case with remote servers and cloud computing.
In those scenarios, you need to make sure you’re being more mindful of what
you’re doing. Keeping an active
root shell logged in while you’re running
upgrades is a good start.
With an active session going, you can finish your upgrade and then attempt to
log in with your normal user. If things are borked, no big deal, just switch
back to your
root session and attempt to sort things out!