# [SOLVED] sshd not starting at boot

## AndrewAmmerlaan

Hello,

I'm having a small problem with starting sshd at boot. I have added the service to default, and yesterday it worked just fine.

But today I arrived at work, only to find out that it didn't let me in, when I got home again I found this in the logs:

```
Jan 30 09:20:40 andrew-gentoo-pc /etc/init.d/sshd[3689]: WARNING: sshd will start when NetworkManager has started

Jan 30 09:21:40 andrew-gentoo-pc sshd[4088]: error: Bind to port <port> on <ip_address> failed: Cannot assign requested address.

Jan 30 09:21:40 andrew-gentoo-pc sshd[4088]: fatal: Cannot bind any address.

Jan 30 09:21:41 andrew-gentoo-pc /etc/init.d/sshd[4086]: start-stop-daemon: did not create a valid pid in `/run/sshd.pid'

Jan 30 09:21:41 andrew-gentoo-pc /etc/init.d/sshd[4012]: ERROR: sshd failed to start
```

I also found this:

```

Jan 29 20:20:39 andrew-gentoo-pc openrc[23611]: You are binding an interface in ListenAddress statement in your sshd_config!

Jan 29 20:20:39 andrew-gentoo-pc openrc[23612]: You must add rc_need="net.FOO" to your /etc/conf.d/sshd
```

Now I think I am missing something obvious here. I understand that in order for sshd to start the network should be active on the network card that has the ip address specified in 'ListenAddress'.

But, I don't quite understand how I get it to do that. I tried adding 'rc_need="net.enp3s0" as suggested by the warning, but that just gives me:

```

ERROR: sshd needs service(s) net.enp3s0
```

When I look in /etc/init.d/ I find that the service 'net.enp3s0' indeed does not exist, so I'm a bit confused about the "You must add rc_need="net.FOO"" message.

What should I do to get the sshd init service to wait starting sshd until network is available on enp3s0? (preferably without delaying the whole boot process until the network is available)

----------

## fturco

I'm not sure, but /etc/init.d/net.enp3s0 should probably be a symlink to /etc/init.d/net.lo.

----------

## AndrewAmmerlaan

 *fturco wrote:*   

> I'm not sure, but /etc/init.d/net.enp3s0 should probably be a symlink to /etc/init.d/net.lo.

 

Thank you, that at least makes it stop complaining about the missing 'net.enp3s0'  :Smile: 

I did some more digging and it seems that these symlinks should indeed exist (according to this wiki page: https://wiki.gentoo.org/wiki/Netifrc).

However, I also found this on the NetworkManager wiki page:

 *Quote:*   

> 
> 
> NetworkManager and other network management services typically do not work together. That includes a standalone instances of dhcpcd and Gentoo's default netifrc scripts. Be sure only one network management service is running at a time. Adding more than one network management service will lead to unpredictable results!
> 
> 

 

Doesn't that mean I should have 'rc_need="NetworkManager"' instead?

But doesn't this warning imply that sshd is already waiting on NetworkManager: "WARNING: sshd will start when NetworkManager has started "?

The problem with this, I think, is that it is not guaranteed that internet is available if NetworkManager has started. I sometimes have issues with internet not being available right after boot. Sometimes it takes NetworkManager several tries to successfully connect to the router, and sometimes it just works. (no idea why, it started when we replaced the router and put a switch between my computer and the router. Anyway the router is not mine, it is my landlord's, so that makes it difficult to fix that.) Therefore, sometimes NetworkManager is started but internet is not yet available. Also, what would happen if sshd is started and listening to <ip address> on enp3s0, and enp3s0 loses connection? Would sshd stop/crash? 

Maybe I should just get rid of "ListenAddress" in sshd_config. Is it really worth the trouble? I read that it is 'more secure', but I don't quite understand why to be honest. It's not like someone is going to plug in a malicious network adapter to my computer.

----------

## mike155

 *Quote:*   

> Maybe I should just get rid of "ListenAddress" in sshd_config.

 

Don't be afraid to get rid of ListenAddress. Or set it to [::], [::1], 0.0.0.0 or 127.0.0.1. See last paragraph of https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.

 *Quote:*   

> If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only. These pseudo-addresses are unconditionally available. If you always bind to these addresses you will have code that doesn't have to react to network changes, as all you listen on is catch-all and private addresses.

 

----------

## NeddySeagoon

AndrewAmmerlaan,

ListenAddress is only useful on systems with several interfaces but you want to allow ssh connections for some subset of interfaces.

Consider a firewall/router. Its a very bad thing to allow ssh from the internet or even wifi, so you use  ListenAddress so that ssh only binds to the trusted network.

ssh listens on all interfaces by default.

Choose at most one network interface management tool. They are all uniformed of the existence of each other and usually fight when you use two or more.

Is easy to test. Disable all the installed network interface management tools from starting and then reboot.

No network interfaces should start. Now pick one.

----------

## AndrewAmmerlaan

 *mike155 wrote:*   

>  *Quote:*   Maybe I should just get rid of "ListenAddress" in sshd_config. 
> 
> Don't be afraid to get rid of ListenAddress. Or set it to [::], [::1], 0.0.0.0 or 127.0.0.1. See last paragraph of https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.
> 
>  *Quote:*   If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only. These pseudo-addresses are unconditionally available. If you always bind to these addresses you will have code that doesn't have to react to network changes, as all you listen on is catch-all and private addresses. 

 

I tried adding 127.0.0.1 to ListenAddress as well as enp3s0's ip address, that makes it start correctly at boot. But if internet is not available then it will only allow ssh access from localhost, even if internet becomes available later through the other ip address  :Sad: 

 *NeddySeagoon wrote:*   

> 
> 
> ListenAddress is only useful on systems with several interfaces but you want to allow ssh connections for some subset of interfaces.
> 
> Consider a firewall/router. Its a very bad thing to allow ssh from the internet or even wifi, so you use ListenAddress so that ssh only binds to the trusted network. 

 

On my PC I have enp3s0 and wlp4s0, initially the idea of adding ListenAddress was to only allow ssh access through enp3s0 and not through the wireless adapter. However, because of the problems with starting sshd at boot, I think I will just remove the ListenAddress setting from sshd_config and disable the wireless adapter. I don't really use it often anyway, mostly I use the wireless network as a backup for when the wired network is not working for some reason (which sometimes happens, but I suppose I can just enable it again in that case).

 *NeddySeagoon wrote:*   

> 
> 
> Choose at most one network interface management tool. They are all uniformed of the existence of each other and usually fight when you use two or more.
> 
> Is easy to test. Disable all the installed network interface management tools from starting and then reboot.
> ...

 

At the moment I have only NetworkManager active. The link that mike155 shared very nicely describes the problem with the NetworkManager init service. When NetworkManager "is started" it is not guaranteed to also be connected to the internet  :Sad: 

I suppose I could use the net.enp3s0 script instead, that might solve the problem as well. However, I kinda like NetworkManager because it makes it easy to configure the wireless networks through the KDE nm-applet (which I do use, every now and then).

Anyway, sshd seems to start just fine now that I have removed the ListenAddress setting, so I'm marking this as solved.

Thank you for your help and advice  :Smile: 

----------

## Hu

Although technically suboptimal, one solution would be to let sshd bind the wildcard address (which will always work), then use iptables / ip6tables to prevent unwanted access based on the interface that receives the connection request.

----------

