Root password not working after 10.3 to 11.0 upgrade


Ryan Root

I've used extended characters such as "Alt-240" in passwords. I had/have one in my root password on a system. If your not aware of what I'm talking about in saying extended characters (maybe not the correct technical term?) open notepad and hold down Alt while typing "2" then "4" then "0" on the 10 key to see what I'm talking about. Old school DOS users created cool directories such as "Alt-255" "." "Alt-255" to confuse many at times. After upgrading from 10.3 to 11.0 unless I am confused about something else, the password no longer works. Suggestions?
Select the single user mode at the boot menu. It will bring you to a console without password. The file systems are mounted read-only. Then re-mount the root partition read-writeable. mount -a should do it if the root partition is listed in /etc/fstab which should be the case. Finally you can use vipw to change the password.
EDIT: Or wait for ther advise of SirDice. I typed too slow...
Ok, that's good. If you did a source upgrade a common mistake people make with mergemaster(8) is to fail merging /etc/passwd correctly. But we can rule it out as a possible cause.
I liked the additional layer of physical machine access security added by having a root password having an extended character because it didn't seem possible to login via sshd for example if a password had an extended character. I'm kind of interested in what changed and not just how to change my password to not have an extended character that would then potentially allow remote access that maybe wasn't possible before.
because it didn't seem possible to login via sshd for example if a password had an extended character.
This is not allowed anyway. The default sshd(8) configuration doesn't allow root logins (PermitRootLogin is set to no by default).
This is not allowed anyway.
It is allowed. It's just a setting and depending on the environment is used by many, perhaps sometimes it shouldn't be, perhaps other times when people know what they are doing it's OK. Do you know what changed if anything?
I have no idea why it doesn't work anymore. Nothing major changed in that part of the OS between 10.3 and 11.0. So I see no reason why it wouldn't work on 11.0 if it worked on 10.3 before.
Maybe I'll look at reproducing it. I am pretty sure that before with a character like I was talking about it wasn't even possible to login to an account via ssh clients when a character like that was used which was a nifty trick. Personally I'll probably keep my main servers on 10.3 for now. I don't like using these forums too much as if you give out security info regarding how one does things it's always risky. It's kind of like those stupid retarded PCI compliance crap for credit cards where databases exists so anyone who has access to it can figure out exactly what they need to hack any particular customer. Kind of a malicious users dream to have a bunch of idiots giving away information about how they run their networks and systems and storing that data in databases.
I am pretty sure that before with a character like I was talking about it wasn't even possible to login to an account via ssh clients when a character like that was used which was a nifty trick.
But a pretty useless one because FreeBSD has you covered already. For example what SirDice said above about SSH not allowing root logons by default, but you can go even deeper if you want. Look into login.access(5) for starters. That will allow you to severely limit the amount of TTY's which can be used to logon as root (or any other account). Also see /etc/login.access.

Another thing which could be interesting is /etc/ttys (see also ttys(5)). This will also allow you to secure your single user mode so that it'll ask for a password. I'd be careful with that though, also don't rely on this too heavily because physical access is by definition insecure anyway. I can always grab a bootdisk for example.

But yeah, I'd advice relying on the system instead of a cheapish hack which might or might not work.
There are probably really good places to talk about security and I know I opened the door on this forum a little to talking about that because it's clear some of you don't follow the actual rules and insult others in sneaky ways using terms like "newb." However, no one has answered my question regarding what changed.
Let's not pretend that groups like this don't have their own arrogant insults.
Not sure how to tag here and I have other things to do but SirDice said, "I have no idea why it doesn't work anymore" immediately after I asked, "Do you know what changed if anything?" I think what that means is that SirDice does not know why the password I had which had an extended character in it wasn't working anymore. I was hoping maybe someone else could confirm this but maybe I'll install a 10.3 OS, use an extended character, try the upgrade to 11.0, and see if the same symptoms happen.
The only thing I can come up with, but I doubt that this has influence, is the changed system console driver. On 10.x this used to be syscons(4) but is now vt(4) by default. However, as mentioned, I doubt that this can have influence in the authentication methods, but I also can't rule it out (for whatever that's worth).

But even so, as mentioned above... Having a difficult or arcane password for the root user is obviously a good idea. But relying on special characters merely for the sake of "physically" blocking remote root logons might be stretching it. Also because you can disallow such logins on other system levels.

I suppose the best way to verify this is to reset the password and see if that actually solved anything.
Last edited:
One temporary workaround is to cut/paste. I run into a similar problem sometimes because I'm using a tenkeyles.
IDK, I used the option discussed to boot single user and reset the password then finished the upgrade using the suggested method on the FreeBSD site and then afterwards added what I was calling an "extended" character back in some of my passwords including the root one and that was fine. Maybe something happened in the upgrade. I personally like the idea of setting up security on systems so that physical access is necessary because if my business grows that might just mean I have to hire an expert that has to see my face from time to time and can't just do their job remotely.