| View previous topic :: View next topic |
| Author |
Message |
Spanik
l33t
Joined: 12 Dec 2003
Posts: 942
Location: Belgium
|
 Posted: Sat Oct 04, 2014 11:17 am Post subject: sshd wants to bring up interface eth0 (solved) |
 |
|
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:
| Code: | 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?
_________________
Expert in non-working solutions
Last edited by Spanik on Sat Oct 04, 2014 11:41 am; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Sat Oct 04, 2014 11:26 am Post subject: |
|
|
Spaniki
I have | Code: | # /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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Spanik
l33t
Joined: 12 Dec 2003
Posts: 942
Location: Belgium
|
| Posted: Sat Oct 04, 2014 11:35 am Post subject: |
|
|
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.
_________________
Expert in non-working solutions |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Sat Oct 04, 2014 12:28 pm Post subject: |
|
|
Spanik,
Post your /etc/conf.d/sshd file please, it should have been fixed.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21619
|
| Posted: Sat Oct 04, 2014 2:37 pm Post subject: Re: sshd wants to bring up interface eth0 (solved) |
|
|
| 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. |
|
| Back to top |
|
|
Spanik
l33t
Joined: 12 Dec 2003
Posts: 942
Location: Belgium
|
| Posted: Sat Oct 04, 2014 10:05 pm Post subject: |
|
|
| 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.
_________________
Expert in non-working solutions |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Sun Oct 05, 2014 1:26 am Post subject: |
|
|
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.
_________________
Beware the grue. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3134
|
| Posted: Sun Oct 05, 2014 7:42 am Post subject: |
|
|
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  |
|
| Back to top |
|
|
|
Networking & Security
