Can't start sshd at boot time on a specific address

X

Xosted

Hi,

I'm simply trying to set sshd to listen to a specific IP address on the box, but this is what I get.
Code: 
sshd_enable="YES"

no issue with this line in /etc/rc.conf. The system boots and sshd starts.
If I add to /etc/ssh/sshd_config this:
Code: 
ListenAddress 192.168.0.197
Then sshd fails at boot time because
Code: 
error: Bind to port 22 on 192.168.0.197 failed: Can't assign requested address.
fatal: Cannot bind any address.

But if at that stage, after login, I just:
[CMD=""]/etc/rc.d/sshd start[/CMD]

then sshd starts, without changing anything.

How can I fix that so sshd will accept to start with a specific IP address to listen to?

Thank you
 
I'm having the same problem and SYNCDHCP didn't fix it. (9.1-RELEASE) My /etc/rc.conf:
Code: 
hostname="jetway.mydomain"
ifconfig_em0="SYNCDHCP"
sshd_enable="YES"
sshd_flags="-o ListenAddress=`ifconfig em0 | grep inet | cut -d ' ' -f 2`"
When the system boots, sshd is not started. I see
Code: 
jetway root: /etc/rc: WARNING: failed to start sshd
in /var/log/messages.

But if I do # service sshd start from the console after the system boots, sshd starts with the appropriate ListenAddress IP address.

The shell commands after ListenAddress get the IP address assigned by DHCP.

I tried adding
Code: 
early_late_divider="NETWORKING"
to /etc/rc.conf, but that didn't change anything.

Thank you.
 
Read the rc.conf(5) man page sections for netwait_*. Specifically the netwait_enable, netwait_ip sections. Add those to your /etc/rc.conf file and everything should work. The boot process will stop until a successful ping of netwait_ip occurs, meaning the network is up and configured.
 
Thanks @phoenix. Unfortunately that didn't work either. Didn't seem to have any effect, no new/fewer errors. I tried using the gateway and OpenDNS IP's for the netwait_ip, nothing seemed to have any effect.

FYI - when the PC boots, the sshd_flags hack I described above doesn't work. It seems the ifconfig command doesn't work yet or doesn't have an "inet" line yet. But service commands executed after boot work fine - they re-read rc.conf and the shell script works as hoped.

I'm able to work around the issue by putting the following line in root's crontab:
Code: 
@reboot sleep 5; service syslog start; service sshd start;
 
Last edited by a moderator:
Now, maybe I'm seeing things too simplistic here but if you're using DHCP then I somewhat doubt that the server is using multiple network interfaces. So why insist on having sshd listen on that one single yet-to-be-determined IP address instead of letting it use everything available? So simply not configuring any listen address so that it will use all addresses?

And even if you are using multiple network interfaces where you don't want to provide SSH access then that should be solvable using a firewall.

As said; maybe there are specific reasons for this which I'm simply not recognizing, but I think this approach could solve some issues.
 
Thanks for your feedback. The specific reason I'm reconfiguring daemons to only listen on one IP address is to run jails. From jail(8):
Since jail is implemented using IP aliases, one of the first things to do is to disable IP services on the host system that listen on all local IP addresses for a service. If a network service is present in the host environment that binds all available IP addresses rather than specific IP addresses, it may service requests sent to jail IP addresses if the jail did not bind the port.
Click to expand...
 
I apologize for bringing back this old topic, but I have been running into this exact problem and found an alternate way to solve it.

The reason why syncdhcp or netwait_* do not work is because rc loads rc.conf once before starting all the services and it is never loaded again after that. Examining the code of rc though, I found that it will re-load rc.conf if it receives an ALRM signal. According to the comment accompanying that snippet, this feature is there to allow services to alter rc.conf as they are being loaded.

I have tried making use of this by sending an ALRM signal from /etc/dhclient-exit-hooks using pkill, but for some reason I couldn't get that to work.

For now, I just settled with adding a file called /usr/local/etc/rc.d/alarm with the following content:

Code: 
#!/bin/sh
#
# PROVIDE: alarm
# KEYWORD: nojail
# BEFORE:


. /etc/rc.subr

name="alarm"
rcvar="alarm_enable"
start_cmd="do_alarm"
stop_cmd=":"

do_alarm()
{
   kill -ALRM $$
}

load_rc_config $name
run_rc_command "$1"
(Note: set BEFORE to list whatever local services need to use the address obtained via dhcp)

And then adding
Code: 
alarm_enable="YES"
to /etc/rc.conf


If anyone manages to get this working from /etc/dhclient-exit-hooks instead, I'd be happy to know. :)
 
You must log in or register to reply here.
Back
Top