# Password not working after freebsd-update 12.2 p5 from memory



## hulleyrob (Mar 28, 2021)

Don't suppose anyone else had this after the update?

Strange thing is trying to log in via ssh it now returns "Remote Password:" which it never used to and the saved password I had doesn't work.

I'm thinking I'm going to have to connect up a monitor and go into single user mode to reset it but this is the first time an update to the server has done this.


----------



## hulleyrob (Mar 28, 2021)

ok so connecting to the console and trying to login it would seem the problem is
"login: /usr/local/bin/bash: No such file or directory"
Any ideas on the easiest way to fix this?

After the update I did do pkg update and an auto remove but they have never cause this before.


----------



## hulleyrob (Mar 28, 2021)

Ok getting connected was a bit of a faff, but my root password worked find installed bash using pkg and everything is working now. Phew.

Hope this helps someone else that was really weird.


----------



## _martin (Mar 28, 2021)

You should not change the root's shell to something outside of the base for this exact reason. 

Now I don't stick to this rule either but I'm aware of the consequences. You could install bash-static and copy it to /usr/bin to lower the risk of this happening. But then you need to pay attention to this when bash is being updated. 
I've seen people creating "shadow root" account (basically uid 0 user with different name with /bin/csh). Personally I don't like it but it is an option.


----------



## hulleyrob (Mar 28, 2021)

_martin said:


> You should not change the root's shell to something outside of the base for this exact reason. Now I don't stick to this rule either but I'm aware of the consequences. You could install bash-static and copy it to /usr/bin to lower the risk of this happening. But then you need to pay attention to this when bash is being updated. I've seen people creating "shadow root" account (basically uid 0 user with different name with /bin/csh). Personally I don't like it but it is an option.


Root shell wasn't the problem its still /bin/csh and as I don't allow remote login with Root that didn't matter.

The problem was the actual user I logged in as used Bash and that was removed for some reason so I couldn't log in remotely.


----------



## zirias@ (Mar 28, 2021)

As I understood the problem, it wasn't about root. But then:


_martin said:


> I've seen people creating "shadow root" account (basically uid 0 user with different name with /bin/csh). Personally I don't like it but it is an option.


This account exists by default on FreeBSD, named `toor`. You just have to activate it by setting a password.


----------



## _martin (Mar 28, 2021)

Zirias said:


> This account exists by default on FreeBSD, named `toor`. You just have to activate it by setting a password.


Idea is to create user that is not known generally. But again, as I said, I don't use this approach.


----------



## hulleyrob (Mar 28, 2021)

Toor is set up and uses /bin/sh but as I don't allow that user to remotely login it wasn't much use to me either as when I attached a monitor I could log in as root from the console, reinstalled bash and then my remote user started working.


----------



## zirias@ (Mar 28, 2021)

_martin said:


> Idea is to create user that is not known generally. But again, as I said, I don't use this approach.


No, that isn't "the idea", that's a _different_ idea, and I don't really get it, as you'd need to rename `root` as well to get that kind of "security by obscurity".

The idea is to just use `toor`, that's the reason it is there. And if you look at gecos fields, it's clear `toor` is meant to be the superuser with a non-base shell. Although it doesn't really matter, works just as well vice versa, but you should have _one_ superuser accont with a shell from base.


----------



## _martin (Mar 28, 2021)

Zirias said:


> No, that isn't "the idea", that's a _different_ idea, and I don't really get it, as you'd need to rename `root` as well to get that kind of "security by obscurity".


And how does that differ from being an "idea" in the first place?
The idea I shared about that I know of people using it. You don't need to get it nor use it. It's what some people do use.

You don't need to rename root, you'd create different user with the uid 0. Again, I personally don't like this approach because it can create problems in other areas too.

Problem OP has is still a problem if all users have bash. I actually cut myself like this 15 years ago or so. I did an upgrade, had remote root disabled (without-password was not an option before) and all my users had bash. Upgrade messed up the lib dependencies making it impossible to login as normal user. It was an subentry-level board without ILO so I had to make a trip to DC.


----------



## SirDice (Mar 28, 2021)

hulleyrob said:


> After the update I did do pkg update and an auto remove


pkg-update(8) only updates the locally cached database of the repository. You need to run pkg-upgrade(8).


----------



## George (Mar 28, 2021)

I did `pkg autoremove` yesterday on my laptop, and it definitely removed shells/bash.


----------



## zirias@ (Mar 28, 2021)

Which means you didn't install it explicitly but it was drawn as a dependency of something else, which is now either removed or had its dependencies changed. But how is this related here?


----------



## hulleyrob (Mar 28, 2021)

SirDice said:


> pkg-update(8) only updates the locally cached database of the repository. You need to run pkg-upgrade(8).


yeah sorry I did update then upgrade then autoremove. Still not sure how I ended up without the package of bash which caused my problems.


----------



## SirDice (Mar 28, 2021)

hulleyrob said:


> Still not sure how I ended up without the package of bash which caused my problems.


Zirias already explained it. It was removed because it was initially installed as a dependency, as nothing depends on it any more it will get removed with pkg-autoremove(8). There's also a reason why it prints a list of packages it's about to remove and you have to acknowledge that, so you haven't been paying attention and blindly entered "Y". Moral of the story, actually look at what it's about to do, think before you enter "Y". 

If there's a package that's about to get removed by pkg-autoremove(8) but you want to keep it, mark it as non-automatic using `pkg set -A0 <packagename>`.


----------



## hulleyrob (Mar 28, 2021)

Yeah I did scan the list of packages but must have missed it. Nevermind all fixed now. And I’m guessing as I explicitly installed bash it won’t happen again.


----------



## SirDice (Mar 28, 2021)

hulleyrob said:


> And I’m guessing as I explicitly installed bash it won’t happen again.


Yes, that `A` flag is set to 0 if you install it yourself.


```
-A 01, --automatic 01
                Set automatic flag for the package: 0 is not automatic, 1 is
                automatic.  This affects the operation of pkg-autoremove(8).
```
pkg-set(8)


----------

