SOLVED Server inaccessible over network and console root login not possible due to long password

[trionic]

Yes, there are many lessons :) I will not repeat this mistake in future :)

Well that does suck. That would require 2 yubikeys and 3 slots.... and now the chances of successfully entering 3 slots worth of string prior to the console refresh are definitely lower.

I do have another two USB-A YubiKeys here somewhere (I keep several backup keys around the place) and the NAS chassis does have enough USB-A sockets so I could split the 100-character password over three keys, but since I moved home three weeks ago I haven't yet found the other keys! For the move, I put them somewhere safe along with some external USB backup disks. They're in a box somewhere but I haven't yet come across them.

However, the version of the YubiKey Manager I have installed here does not allow for disabling the carriage return. Maybe worth searching for an earlier version if I could find one on Yubico's website (edit: here https://developers.yubico.com/yubikey-manager/Releases/ and see this https://www.reddit.com/r/yubikey/comments/iuzp4o/removing_the_carriage_return_on_a_static_otp/).

Can I safely force power-off this server?

 

[trionic]

Using the YubiKey Personalisation Tool, it is possible to disable the carriage return appended after the static password. It also looks as if the static password maximum length can be increased to 64 characters so with two keys, this trick might still work. I don't want to screw up my YubiKeys though, especially as I currently cannot find two of the backups (they're here but I just don't know where - another lesson!).

Edit: I have ordered two new YubiKeys, which will arrive tomorrow. On each key, I will expand the maximum static password length for slot 1 to 50 characters, disable the carriage return, program the password, insert each into the server and attempt to use those to gain access to the console. If that works, then hopefully I can figure out what networking changes I need to make to get the thing back online.

 

[Samuel Tai]

Can I safely force power-off this server?

As you've not any choice here, I say go for it. ZFS extremely good at recovering from forced shutdowns by replaying from the journal.

 

[trionic]

It verked!

I couldn't get the YubiKey to output anything on a long press (slot 2), so I could only configure short press output (slot 1). In addition, I could not set the maximum static password length to >34 characters so I split the 100 character root password across three Yubikeys, plugged in each one and also the keyboard. Entered the root username and then touched each YubiKey in sequence. Worked beautifully and unlocked the console.

Ironically, the first thing to appear upon entering cli --menu was my MOTD: "Don't screw it up" which comes from my experiments with FreeNAS about ten years' ago! More lessons...

Anyway, I deleted the bridge interface and the interface which had an IP registered against it, switched the network cable to a different port to force a new DHCP IP and we were back online.

I reset the root password to something much shorter and disabled password authentication for the local console.

I am hugely grateful to you all for helping me through this and achieving a great outcome with all risks minimised. No need to force power-off or re-install. My data is just where I left it, safe and sound.

 

[GBillR]

It verked!

I couldn't get the YubiKey to output anything on a long press (slot 2), so I could only configure short press output (slot 1). In addition, I could not set the maximum static password length to >34 characters so I split the 100 character root password across three Yubikeys, plugged in each one and also the keyboard. Entered the root username and then touched each YubiKey in sequence. Worked beautifully and unlocked the console.

Glad to hear that it worked out for you!

 

[trionic]

Just gotta figure out now why the server can't access update.freenas.org:443 for updates... but that's a different thread :)

"Cannot connect to host update.freenas.org:443 ssl:default [Name or service not known]: Automatic update check failed. Please check system network settings."

 

[HoneyBadger]

Just gotta figure out now why the server can't access update.freenas.org:443 for updates... but that's a different thread :)

"Cannot connect to host update.freenas.org:443 ssl:default [Name or service not known]: Automatic update check failed. Please check system network settings."

I tried looking for your other thread, but didn't see it - so I'll ask the standard questions here:

Have you set up DNS servers inside of TrueNAS?
Have you also set a default gateway/route for IPv4?

 

[trionic]

Sorry for the late reply; I have been away.

The DNS and DHCP IP addresses were incorrect. With the correct IP addresses, updates now work just fine.

Thank you for your help.

 

[trionic]

Not sure if this is the right place to continue the network part of this thread, but:

When I set-up a bridge interface in TrueNAS, in order to make SMB shares available to a virtuall machine, TrueNAS can no longer connect to the Internet. I followed the instructions in the documentation, but clearly I made a mistake - any ideas what it could be?

 

[Samuel Tai]

Why are you using a /16 mask with a 192.168 network instead of a /24? Also, did you remove the IP from the member interface?

 

[trionic]

Thank you for your reply. Good point - I have now changed that to /24.

The member interface has no IP:

 

[Samuel Tai]

If you reused the same IP from the member interface for the bridge interface, you'll need to clear the ARP cache on your default gateway so it can learn the new MAC for that IP. You should be able to access the Internet afterwards.

 

[trionic]

I did reuse the same IP indeed.

Just have to figure out how to purge the ARP cache on the Linksys WHW03 router that I have here. Probably one for the Linksys forums!

Or just change the IP...

Or maybe this is the prompt to do that pfSense project I have had on my mind for years.

Thanks again for your help.

 

[trionic]

I changed the IP from 192.168.0.200 to 192.168.0.210 on both the TrueNAS bridge interface and also the router's DHCP reservation. The TrueNAS server still cannot connect and a ping to google.com fails ("Name or service not known").

I can access the TrueNAS web GUI fine. A ping from my laptop to truenas.local also is fine. The VM using he bridge interface also seems to have normal network access.

I wasn't sure whether the MAC address for the DHCP reservation should be the bridge interface MAC or the member interface MAC, so I tried both but with no different in connectivity.

 

[Patrick M. Hausen]

Using static configuration is really recommended. I do not know how Linux handles the bridge interface MAC. In FreeBSD it is created dynamically and at least up to some version changed at every reboot. There's a sysctl in FreeBSD/CORE to have the bridge "inherit" the hardware MAC of the first member interface but you are on SCALE so ...

I'd do static configuration. I do on FreeBSD.

 

[Samuel Tai]

Try rebooting the router. Usually that gets rid of wedged ARP entries.

 

[trionic]

Using static configuration is really recommended. I do not know how Linux handles the bridge interface MAC. In FreeBSD it is created dynamically and at least up to some version changed at every reboot. There's a sysctl in FreeBSD/CORE to have the bridge "inherit" the hardware MAC of the first member interface but you are on SCALE so ...

I'd do static configuration. I do on FreeBSD.

By "static configuration", are you referring to statically assigned IP addresses instead of DHCP? I so, then most of the devices on the network have static IPs, iincluding the TrueNAS server.

I rebooted both the Linksys router and the TrueNAS server, to no difference.

 

[Patrick M. Hausen]

Yes, the TrueNAS server should have static configuration. That implies that you need to set default gateway and DNS server statically, too.

 

[trionic]

The DNS and Default Gateway was set statically on TrueNAS and not through DHCP, but your post caused me to look again at the router's configuration. The router itself was on 192.168.1.1 but all other devices on the network had IP addresses of 192.168.0.x, with the TrueNAS server's DNS and Default Gateway being set to 192.168.0.1, which was unreachable. My error, after fiddling with the router's config.

I changed the router's IP address to 192.168.0.1 and now TrueNAS can access the download server and app catalogues.

Thank you again for your help.