Password not working after freebsd-update 12.2 p5 from memory

hulleyrob

hulleyrob

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.
 
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.
 
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.
 
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.
 
_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.
Click to expand...
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.
 
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.
Click to expand...
This account exists by default on FreeBSD, named toor. You just have to activate it by setting a password.
 
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.
 
_martin said:
Idea is to create user that is not known generally. But again, as I said, I don't use this approach.
Click to expand...
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.
 
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".
Click to expand...
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.
 
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 said:
Still not sure how I ended up without the package of bash which caused my problems.
Click to expand...
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>.
 
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.
 
hulleyrob said:
And I’m guessing as I explicitly installed bash it won’t happen again.
Click to expand...
Yes, that A flag is set to 0 if you install it yourself.

Code: 
     -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)
 
You must log in or register to reply here.
Back
Top