I tried this in the users forum but couldn’t make any progress. Whenever I reboot Vyos, I cannot ssh into the system. In order to do so, I need to connect through the console and make a configuration change that causes the the SSHD service to restart. Once that happens, I can get in and everything is good.
Typically, I’ll log in through the console, add another listen-address to the SSH configuration and commit. This causes SSHD to restart and that allows me to connect.
Here’s my ssh config:
The configuration is saved and after I reboot, I see everything intact when I log into the console. Apparently the SSHD program either doesn’t start on reboot or doesn’t correctly read its configuration. Any ideas anyone?
I don’t think it will work properly to bind ssh service to a dhcp address. I don’t really understand your config. your NAT rule doesn’t make any sense to me either (doesn’t mean it is wrong, but I don’t get it).
Why would you have an interface that is an internal one grabbing a DHCP address? Why would you not statically assign that interface an address?
OpenSSH daemon will happily bind to anything that exists if you explicitly configure listen addresses, bu the catch is the IPs must exist & configured on an interface. In the absence of a listen-address directive, openssh (and any other daemon that is configured to listen on all IPs) will bind to INADDR_ANY which survives IPs coming and going.
To the OP, you will always have a race condition when booting up and having daemons expecting to bind to an explicit IP, but that IP doesn’t yet exist on an interface. Systemd handles this kind of stuff quite gracefully (compared to init scripts that frequently have random sleeps to work around these kind of behaviours).
For VyOS specifically, the easiest way to deal with this is probably to add some logic to /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script which will survive image upgrades & is invoked from /etc/rc.rclocal. You may need to background a script that sleeps a bit longer and then starts sshd explicitly.
Looks like you’re trying to run ssh listening on a vrrp vip. I would remove the listen-address portion of the ssh configuration for starters to see if it works. Then I would listen on one of the local IP addresses on an internal interface. I see no reason to make sshd listen on a vrrp virtual address.
What is probably happening is ssh tries to start before vrrp brings up the virtual interface IP and ssh failed because the IP it’s trying to bind to doesn’t exist yet. After the machine has been up long enough for vrrp to come up, then the IPs are present, so a restart of ssh works and listens properly. if you must listen on a vip for some reason look at sysctl kernel tweak net.ipv4.ip_nonlocal_bind=1
and copy the host keys from this node to it’s vrrp partner.
I just had the same issue on a test machine; a Supermicro box. I had the management interface still set to DHCP, and SSH would work when I configured it, but after a reboot the service was no longer available even though the configuration changes were still there.