I’d like to configure a spare ethernet port on a router as a (serial) console port. Is this possible? If not what would be the best way to configure this port as an out-of-band management interface?
A serial port is not an ethernet port or vice versa just because both can use the same connector.
They are electrically and logically different.
The simplest way is to just create an interface with a static IP and bind ssh to that IP only or use firewall rules to only allow ssh in from that port. If that is not isolated enough you can put that interface into a separate VRF and run SSH in that VRF to fully isolate it.
The serial port uses RS232 so that wont work through a regular networking RJ45.
The RJ45 you see on like Arista and others is a RJ45 connector connected straight to the RS232 lines.
What you might be able to do is to get a USB to female RJ45 (RS232) serial adapter such as:
@Nicolas is closer to what I want.
I would like to configure a spare eth port to act like a serial port, not be an actual serial port. It would still be ethernet. RS232 is so 1998.
One issue I’m seeing is that if I support both this as an out-of-band interface but also have an in-band interface via SSH that supports public key auth then you can not bypass the public key auth on the out-of-band interface. I’d like this interface to be a break glass in case of emergency type of access, IE: like a serial console port. If there isn’t a way to do this on a spare eth port, then maybe this is more of a feature request.
So a regular MGMT-interface then, why didnt you say so? 
Yeah, what @Nicolas described is the way to deal with that.
Select whatever physical interface you want to use as MGMT-interface (normally the first or last unless you already got one that sit on the side compared to the others), give it a static IP, description (normally “MGMT” or so) and put it in its own VRF (normally vrf:MGMT or such). While at it make a dedicated VLAN (which you, you guessed it, calls “MGMT”) which you put as untagged on this MGMT-interface. This way you can later choose to have inband access to this MGMT-vlan through other interfaces if needed/wanted.
Dont forget to also “lockdown” any services (such as SSH and whatelse) you will be using so it only listens at the MGMT-ip and not 0.0.0.0 which most services often (unfortunately) defaults to.
Note that VRF in VyOS is the Linux edition and not the NOS edition.
The NOS edition also includes network namespaces (netns) to have “true” separation of the interface which VyOS currently (as I know) doesnt support through its CLI (but if you really want to you can do that manually in bash-mode).
VRF the Linux edition is “just” separate routing tables.
Arista for example (I like to compare to “how others does this”) when you create a VRF in their CLI this will create an actual NETNS in the backend (they are also Linux based and have a bash-mode) along with a VRF for the routingtable.
Thanks to both you and @Nicolas for the input.
I’d still like this interface to not have to deal with the auth keys, but it’s a small concession.