"Press any key for logon" prompt, for serial and console

Feature Requests
1

Now and then, there are posts where people don't realize you have
to hit a key, to get the logon prompt, when using serial access or
console.

2

And don't forget to set option ttylogin to 1 ie:
uci set system.@system[0].ttylogin='1'
and
uci commit system afterwards.

This makes username/password necessary after pressing the "Any" key :smiley:
Of course it can be bypassed by doing a reset to defaults, unless you hard wire it into a custom image.

3

if an intruder can access your serial you have more problem than securing your serial...

3 Likes
4

yes it may be a good idea to put in the wiki with char size 70 that you need to press something... also would be interesting to document the eth packet way to trigger failsafe.

1 Like
5

Well for intruders, yes it would be very worrying to be visited by some. What would they want? Probably steal stuff. Or maybe quickly install some clandestine software.... Having a password will slow them down. Rack mounted devices usually have a serial connector on the front panel...
But I'm more concerned about the IT support staff connecting to the wrong device in the company server room and accidentally messing things up (I have had this happen in a rack of x86 servers - one being OpenWrt with captive portal for public areas).

6

What's really going on here is that the prompt gets buried in a flurry of other messages of the OS still setting things up in the background. I don't know if this is a DSA thing, I haven't tested anything non-DSA recently.

The prompt does show up, but it's not the end of what's printed on screen or over serial. That's where people get confused. Most (if not all) of those reports are from people who do not watch the output scroll by, I reckon. They go sip some coffee, come back when they reckon it's booted, don't see the prompt anymore...

2 Likes
7

That might be the case, I haven't seen it myself, while I've watched the boot sequence scroll
by, but I guess it also depends on how fast the device boots, and the speed of the serial port.

And if the boot is successful, why scoll back ?

But if it's there, perhaps a sleep before the actual output happens is in place, to get a delay ?

1 Like
8

Kernel- and netifd will continue logging to tty1, regardless of how long you're willing to wait (and adding delays will just add new breakage potential). Ports going up/ down, IPv6 connectivity coming and going (regardless of DSA or swconfig), it's just a question of log levels (and you don't want to raise them to the level where you'd miss real problems).

1 Like
9

There is a wiki about this: