Bjoern A. Zeeb wrote:
> On 18 Mar 2020, at 15:50, Victor Sudakov wrote:
> 
> > > If sshd in the host is configured to listen on all available
> > > interfaces and
> > > addresses (the default) then it will catch your jails IP too.
> > 
> > Why is it not catching the 192.168.4.204 address then?
> > 
> > > You must configure sshd in the host to listen only on hosts IP and
> > > then you
> > > will connect to the jails sshd.
> > 
> > OK, I've stopped the sshd on the host entirely, and restarted the jails.
> > Why am I still not seeing the jailed sshd listening on tcp6?
> 
> Can you check the logfile inside the jail and see if it complains?

It turns out it does:

Mar 19 08:52:35 test4 sshd[27210]: error: Bind to port 22 on :: failed: Can't 
assign requested address.

> 
> Can you then do a jexec test4 and run service sshd restart and see if it
> starts working?  

It turns out it does:

root@test4:/ # sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   28249 3  tcp4   192.168.4.204:25      *:*
root     sshd       28246 3  tcp6   2001:470:ecba:3::4:22 *:*
root     sshd       28246 4  tcp4   192.168.4.204:22      *:*
root     syslogd    28181 5  udp4   192.168.4.204:514     *:*
root     syslogd    28181 6  dgram  /var/run/log
root     syslogd    28181 7  dgram  /var/run/logpriv

same with other daemons:

root@test4:/ # service syslogd restart
Stopping syslogd.
Waiting for PIDS: 28181.
Starting syslogd.
root@test4:/ # sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     syslogd    28678 5  udp6   2001:470:ecba:3::4:514 *:*
root     syslogd    28678 6  udp4   192.168.4.204:514     *:*
root     syslogd    28678 7  dgram  /var/run/log
root     syslogd    28678 8  dgram  /var/run/logpriv


> If it does, can you add a
> 
>       exec.start += "sleep  2 ";
> 
> to your config 

OK, I've added it to the configs of 3 experimental jails.

> and see if your problem goes away?  

It goes away partially (only for sshd in 2 of the 3 available jails), and
not for syslogd in any of the 3 available jails. Restarting the daemons
from within the jail fixes the problem. An example from a problem jail:

root@vas:~ # jexec test5
root@test5:/ # sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   29495 3  tcp4   192.168.4.205:25      *:*
root     sshd       29492 3  tcp4   192.168.4.205:22      *:*
root     syslogd    29427 5  udp4   192.168.4.205:514     *:*
root     syslogd    29427 6  dgram  /var/run/log
root     syslogd    29427 7  dgram  /var/run/logpriv
root@test5:/ # service sshd restart
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 29492, 29492.
Performing sanity check on sshd configuration.
Starting sshd.
root@test5:/ # sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sshd       29838 3  tcp6   2001:470:ecba:3::5:22 *:*
root     sshd       29838 4  tcp4   192.168.4.205:22      *:*
root     sendmail   29495 3  tcp4   192.168.4.205:25      *:*
root     syslogd    29427 5  udp4   192.168.4.205:514     *:*
root     syslogd    29427 6  dgram  /var/run/log
root     syslogd    29427 7  dgram  /var/run/logpriv
root@test5:/ # service syslogd restart
Stopping syslogd.
Waiting for PIDS: 29427.
Starting syslogd.
root@test5:/ # sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     syslogd    29858 5  udp6   2001:470:ecba:3::5:514 *:*
root     syslogd    29858 6  udp4   192.168.4.205:514     *:*
root     syslogd    29858 7  dgram  /var/run/log
root     syslogd    29858 8  dgram  /var/run/logpriv
root     sshd       29838 3  tcp6   2001:470:ecba:3::5:22 *:*
root     sshd       29838 4  tcp4   192.168.4.205:22      *:*
root     cron       29502 5  dgram  (not connected)
smmsp    sendmail   29498 3  dgram  (not connected)
root     sendmail   29495 3  tcp4   192.168.4.205:25      *:*
root     sendmail   29495 4  dgram  (not connected)
root@test5:/ #


> If it does, the reason is
> that you configure an IPv6 address to an interface and DUD has not yet
> completed by the time sshd or other daemons start.  Giving it the 2 seconds
> avoids this problem and the address is usable at that time.

There is obviously a race somewhere, but the 2 second sleep does not
eliminate it entirely.

Thank you for the hint in the right direction, what would you suggest
further?


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

Attachment: signature.asc
Description: PGP signature

Reply via email to