# sshd wants to bring up interface eth0 (solved)

## Spanik

I want to have remote loging to the pc so I want to start sshd. It is installed and seems to run but I cannot make a connection. Now when I want to restart it I get the following:

```
mini ~ # /etc/init.d/sshd restart

 * Bringing up interface eth0

 *   ERROR: interface eth0 does not exist

 *   Ensure that you have loaded the correct kernel module for your hardware

 * ERROR: net.eth0 failed to start

 * ERROR: cannot start sshd as net.eth0 would not start

mini ~ # ifconfig -a

enp1s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.2.7  netmask 255.255.255.0  broadcast 192.168.2.255

        inet6 fe80::203:2dff:fe0e:9e5a  prefixlen 64  scopeid 0x20<link>

        inet6 fe80::144a:42a6:3ed:268  prefixlen 64  scopeid 0x20<link>

        ether 00:03:2d:0e:9e:5a  txqueuelen 1000  (Ethernet)

        RX packets 1207  bytes 673628 (657.8 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1244  bytes 275864 (269.3 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 0  (Local Loopback)

        RX packets 48  bytes 3072 (3.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 48  bytes 3072 (3.0 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480

        sit  txqueuelen 0  (IPv6-in-IPv4)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

```

So it is reasonably clear why it doesn't work. It wants to start interface eth0 that does not exist, it is called enp1s8. Enp1s8 does work fine, I'm doing this post through it.

How do I tell sshd to use enp1s8?

As a side-question: why did they change eth0 which is very readable and comprehensible to something like enp1s8?

----------

## NeddySeagoon

Spaniki

I have 

```
# /etc/conf.d/sshd: config file for /etc/init.d/sshd

# bring up the network we will listen to  to your /etc/conf.d/sshd

rc_need="net.br1"
```

You will need to change the last line there.

Also be sure to disable root logins over ssh and add your normal user to the wheel group, so you can get root if needed.

Key based ssh logins only are even better.

----------

## Spanik

Thanks, did'n know if I had to search for the ssh, sshd or net config files to solve this.

Root is disabled and remote user is part of wheel group, that was already taken care of.

EDIT: ok now, got to rename /etc/init.d/net.eth0 as well because it still wanted to start net.eth0.

----------

## NeddySeagoon

Spanik,

Post your /etc/conf.d/sshd file please, it should have been fixed.

----------

## Hu

 *Spanik wrote:*   

> As a side-question: why did they change eth0 which is very readable and comprehensible to something like enp1s8?

 There are many threads, most of them highly opinionated, discussing this change.  The official name from the udev project for the new behavior is "Predictable Network Interface Names" though many of the critics argue that the term "predictable" is properly applied to the kernel-assigned eth* names, rather than to the complicated names that udev generates to replace the kernel-assigned eth* names.  If you dislike the new names, add net.ifnames=0 to your kernel command line (as described in Gentoo news item Upgrade to >=sys-fs/udev-210) and reboot.  If you do this, then any places you have changed to use enp1s8 will then need to be changed back to eth0.

----------

## Spanik

 *NeddySeagoon wrote:*   

> Spanik,
> 
> Post your /etc/conf.d/sshd file please, it should have been fixed.

 

Oh, it was fixed. I added the line you mentioned to the /etc/conf.d/sshd file. But then it wanted to start net.eth0 (which failed) and net.enp1s8 which didn't exist. 

Problem was I had a /etc/init.d/net.eth0 file but no interface named such and the /etc/conf.d/sshd file specified enp1s8. So I copied and renamed it to to /etc/init.d/net.enp1s8. Then it wanted to start /etc/init.d/net.eth0 (which failed again) and /etc/init.d/net.enp1s8 which did start. So I removed /etc/init.d/net.eth0 and all was well.

My fault was when I installed not to rename /etc/init.d/net.eth0 to /etc/init.d/net.enp1s8. No idea why the interface did start and worked.

 *Hu wrote:*   

> There are many threads, most of them highly opinionated, discussing this change. The official name from the udev project for the new behavior is "Predictable Network Interface Names" though many of the critics argue that the term "predictable" is properly applied to the kernel-assigned eth* names, rather than to the complicated names that udev generates to replace the kernel-assigned eth* names. If you dislike the new names, add net.ifnames=0 to your kernel command line (as described in Gentoo news item Upgrade to >=sys-fs/udev-210) and reboot. If you do this, then any places you have changed to use enp1s8 will then need to be changed back to eth0.

 

I side with the critics here. Same with how it gives names to SDcards... Instead of some /dev/sdx it becomes something that would do a military inventry system justice. 

I agree that the udev names they are predictable in the sense that they are identical every time you start and incomprehensible to the point of having to copy-paste them. It isn't an advancement in userfriendlyness.

----------

## Aiken

From what I can work out rc_need in /etc/conf.d/sshd only seems to be needed if sshd is being told to bind to a particular address. In that case a person would want the interface up before sshd is started. I have it set on 2 machines where I want sshd to bind to a particular ip and I do not have that line on the computers where sshd binds to all address.

 *Spanik wrote:*   

> 
> 
> I agree that the udev names they are predictable in the sense that they are identical every time you start and incomprehensible to the point of having to copy-paste them.

 

From some of the threads on the forum you are not guaranteed the same name between reboots. People have made changes which triggered a slot renumber which promptly broke networking due to udev generating a new name. Any kind of removable network card (pci, usb) is also a pig with the renaming.

----------

## szatox

Really old names used to be predictable, because they were easy to guess. If you stuffed several deviced into your PCI slots they woudl be named in the same order as slots they occupied. Unfortunately, race condition was introduced later (so the order is no longer deterministic, even though result tends to be repeteable for a single system), and udev atempts to fix this with it's own renaming rules.... unfortunately this is not persisted either as different versions might (and do) use different algorithms.

And yes, pluggin USB adapter to different port renames that one too.

Oh, and with new naming conventions network devices are no longer easily replecable because..... the name would change. Unless you actually roll your own rules  :Smile: 

----------

