PDA

View Full Version : FC13: sshd not loading



Luis
7th June 2010, 05:42 PM
Hi,
Every time I upgrade my system I run a post install script. This script made some harm to the network start that prevents sshd from starting, but I was unable to detect the problem.

In my boot.log I found this:

[...]
Starting NetworkManager daemon: [ OK ]
Starting Avahi daemon... Jun 2 14:58:48 Antares kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready [ OK ]
Starting RPC idmapd: Jun 2 14:58:48 Antares kernel: RPC: Registered udp transport module.
Jun 2 14:58:48 Antares kernel: RPC: Registered tcp transport module.
Jun 2 14:58:48 Antares kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
[ OK ]
Retrigger failed udev events [ OK ]
Starting PC/SC smart card daemon (pcscd): [ OK ]
Jun 2 14:58:50 Antares sshd[1179]: error: Bind to port 22 on NNN.NNN.NNN.NNN failed: Cannot assign requested address.
Jun 2 14:58:50 Antares sshd[1179]: fatal: Cannot bind any address.
Starting xinetd: [ OK ]
ntpdate: Synchronizing with time server: Jun 2 14:58:50 Antares kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Cont>>> rol: RX/TX
Jun 2 14:58:50 Antares kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ OK ]
Starting ntpd: [ OK ]
Starting sendmail: [ OK ]
[...]

So there is a "bind to port 22 failed" probably caused by "eth0: link is not ready", but after the sshd init script fails the eth0 is ready... Any idea what could be causing this?

Thanks!
Cheers,
L.

Luis
8th June 2010, 10:36 PM
Not a clue??

:(

smr54
9th June 2010, 12:45 AM
You could play with the numbering in /etc/rc3.d and rc5.d to check the Sxx (with xx being numbers) and make sure that sshd starts after networkmanager.

Luis
9th June 2010, 01:23 AM
You could play with the numbering in /etc/rc3.d and rc5.d to check the Sxx (with xx being numbers) and make sure that sshd starts after networkmanager.

It does...

By some reason the card link becomes ready 10 or 20 seconds after NM starts. I read the NM script, and it has these lines:

[ -z "${LINKDELAY}" ] && LINKDELAY=10
nm-online -q --timeout=$LINKDELAY || nm-online -q -x --timeout=30

Perhaps it has something to do with this?

Thanks!
L.

jpollard
9th June 2010, 02:14 AM
Make sure you have sshd enabled in the "trusted ports".

There is a security utility program (portreserve) that locks ports that it believes should
not be used - If it is told the port is to be enabled, then it will grant sshd the port
when sshd starts.

Luis
9th June 2010, 02:39 PM
Make sure you have sshd enabled in the "trusted ports".

There is a security utility program (portreserve) that locks ports that it believes should
not be used - If it is told the port is to be enabled, then it will grant sshd the port
when sshd starts.

No, it is not that. After 3 or 4 seconds after the 'ADDRCONF(NETDEV_UP): eth0: link is not ready' message, I get a 'ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready', and then a 'service sshd start' works just fine. The problem is that the sshd service is started between the two ADDRCONF(NETDEV_UP) messages, that is, when eth0 is not ready. The point is why eth0 is not ready and 4 seconds later it is?

Thanks!
L.

jpollard
9th June 2010, 03:52 PM
No, it is not that. After 3 or 4 seconds after the 'ADDRCONF(NETDEV_UP): eth0: link is not ready' message, I get a 'ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready', and then a 'service sshd start' works just fine. The problem is that the sshd service is started between the two ADDRCONF(NETDEV_UP) messages, that is, when eth0 is not ready. The point is why eth0 is not ready and 4 seconds later it is?

Thanks!
L.
That almost sounds like a cable negotiation issue, but I could be wrong.
It can take a couple of seconds if the cable is a crossover when it should
be a normal cable. As I recall, this occurs when both sides attempt to
re-negotiate the connections - as long as one of them takes longer than
the other, it works - but takes a couple of seconds. You should see link
lights flicker during this (depending on the interface and what it is
connected to.)

Another thing you could try is to check the sshd configuration - if it is
only listening to one address, change it to accept connections from
any address - this would allow ssh to localhost... but would allow sshd
to start listening even if it is only for the local host. On my system all
restrictions are defaulted (port 22, addressFamily any, ListenAddress 0.0.0.0
and :: for IPv6). Once sshd is running, other interfaces can up or down,
and connections are accepted as long as the interface is up.

Luis
9th June 2010, 06:55 PM
That almost sounds like a cable negotiation issue, but I could be wrong.
It can take a couple of seconds if the cable is a crossover when it should
be a normal cable. As I recall, this occurs when both sides attempt to
re-negotiate the connections - as long as one of them takes longer than
the other, it works - but takes a couple of seconds. You should see link
lights flicker during this (depending on the interface and what it is
connected to.)

Another thing you could try is to check the sshd configuration - if it is
only listening to one address, change it to accept connections from
any address - this would allow ssh to localhost... but would allow sshd
to start listening even if it is only for the local host. On my system all
restrictions are defaulted (port 22, addressFamily any, ListenAddress 0.0.0.0
and :: for IPv6). Once sshd is running, other interfaces can up or down,
and connections are accepted as long as the interface is up.

Indeed, removing the ListenAddress option solved the issue. I read the sshd_config man page, and it seems that there is no negative impact removing this option. Am I correct?

Thanks!!!!!!
L.

jpollard
9th June 2010, 11:52 PM
Indeed, removing the ListenAddress option solved the issue. I read the sshd_config man page, and it seems that there is no negative impact removing this option. Am I correct?

Thanks!!!!!!
L.
Correct. The only time it can make a difference is when you specifically
want it to listen on something like an internal network - say, for
administrative use only.

commenting it out takes the default - which is to listen on any address.

Luis
10th June 2010, 03:10 AM
Correct. The only time it can make a difference is when you specifically
want it to listen on something like an internal network - say, for
administrative use only.

commenting it out takes the default - which is to listen on any address.

Great then. Thanks a lot for your help!!

Cheers,
L.