User:Sakaki/Sakaki's EFI Install Guide/Setting Up Networking and Connecting via ssh

Having successfully booted our target PC with the Gentoo minimal install image, our next task is to establish network connectivity for it.

Once that is done, we'll connect in remotely to the target, from the helper PC, via ssh. This will make subsequent installation steps (such as the copy/paste of lengthy commands) much easier.

This section shadows Chapter 3 of the Gentoo handbook.

Getting Networking Running

Decide whether you wish to perform the install using a wired Ethernet connection, or over WiFi (using WPA/WPA2), and follow the appropriate instructions below. In both cases, the presence of a DHCP server on the subnet will be assumed.

Note
If you need to use a fixed IP address, a proxy, IPv6, or an unencrypted WiFi connection, please see Chapter 3 of the Gentoo handbook for more details.

Connecting via Wired Ethernet

This is the easier option, if your machine physically supports it. To proceed, plug an ethernet cable into the target machine now, and hook it up to your network (into the back of your cable or ADSL router etc.). Wait for a minute or so (for DHCP to allocate you an address), then (at the keyboard of your target PC) enter:

livecd ~ #ifconfig

enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.106  netmask 255.255.255.0  broadcast 192.168.1.255
        ... etc ...

Hopefully, it will have autoconfigured an interface, as above. In the old days, you'd be looking for eth0 in the output of this command, but things have now changed (to ensure device naming stability across reboots), so your wired ethernet interface name will probably be something a bit stranger-sounding, such as enp0s25 (as is the case here). You are looking for the 'inet' (assuming IPv4) entry; in this case 192.168.1.106 (yours will almost certainly differ).

If that was successful, then try:

livecd ~ #ping -c 3 www.gentoo.org

If this works, it demonstrates that you have a functioning network connection, with working DNS name resolution.

When ready, click here to jump to the next section of the tutorial.

Connecting via WiFi (WPA/WPA2)

If your PC has no Ethernet port, you'll have to perform the installation over WiFi. First, check that your PC's adaptor has driver support in the minimal-install image. Issue:

livecd ~ #iwconfig

wlp2s0    IEEE 802.11abgn ESSID:off/any
          Mode:Managed  Access Point: Not-Associated Tx-Power=0 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management: on
          
lo        no wireless extensions.

Your results will differ from the above, but you're looking for a record starting with wl, as this is a wireless adaptor. In this example, the predictable network interface name of the WiFi adaptor is wlp2s0; take a note of the particular name reported in your case.

Note
If you see no records beginning with wl, then you will not be able to install the system wirelessly. Use a wired adaptor if your machine has one, or purchase a supported USB to Ethernet (or WiFi) adaptor, and use that.
Most machines do have driver support in the minimal install image, however.

Next, we'll need to create a configuration file, to allow the wpa_supplicant program to handle the encrypted network connection. You'll need to know your WiFi access point's ESSID (the name you'd see when connecting to it via your phone etc.) and its WPA (or WPA2) passphrase. Issue:

livecd ~ #wpa_passphrase "ESSID" > /etc/wpa.conf

<then type your WiFi access point passphrase (without quotes) and press Enter>

Note
Substitute the correct name for "ESSID" in the above ("MyWiFi", or whatever it happens to be in your case).

Lock down the file's access permissions (to root only) and check that its contents look sane. Issue:

livecd ~ #chmod -v 600 /etc/wpa.conf

livecd ~ #cat /etc/wpa.conf

Assuming that looks OK, we can connect. Issue:

livecd ~ #wpa_supplicant -Dnl80211,wext -iwlp2s0 -c/etc/wpa.conf -B

Successfully initialized wpa_supplicant

Note
Substitute the wireless network interface name you wrote down a minute ago for wlp2s0 in the above command.

In this command:

Option	Description
-D	Specifies the wireless driver name to use. wext is the 'catch all' and will work in most cases; nl80211 is the more modern version that will ultimately replace it. It's fine to specify multiple drivers here, so we do.
-i	Specifies the interface name (from iwconfig above).
-c	Specifies the configuration file path (as created by wpa_passphrase above).
-B	Instructs wpa_supplicant to run in the background.

Now wait a moment or two, then issue:

livecd ~ #ifconfig wlp2s0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.106  netmask 255.255.255.0  broadcast 192.168.1.255
        ... etc ...

Note
Substitute the wireless network interface name you wrote down a minute ago for wlp2s0 in the above command.

Hopefully, it will have connected successfully. You are looking for the 'inet' (assuming IPv4) entry; in this case 192.168.1.106 (yours will almost certainly differ).

If that was successful, then try:

livecd ~ #ping -c 3 www.gentoo.org

If this works, it demonstrates that you have a functioning network connection, with working DNS name resolution.

Connecting via ssh and Using screen

Our next step is to setup ssh so we can remotely connect and run the install from our helper PC. Still on the target machine console, enter:

livecd ~ #sed -i 's/^#PermitRootLogin.*$/PermitRootLogin yes/' /etc/ssh/sshd_config

livecd ~ #/etc/init.d/sshd start

Note
From release 7.0 of OpenSSH, the defaults have changed to prohibit password-based login as root, hence the reason we edit the /etc/ssh/sshd_config file above. (More recent versions of the minimal install image have fixed this issue, but it does not hurt to apply the edit even when using them.)

Now take note of the RSA and ED25519 fingerprints for the host (which one is used when you try to connect, will depend upon the settings and recency of the system in your helper PC):

livecd ~ #for K in /etc/ssh/ssh_host_*key.pub; do ssh-keygen -l -f "${K}"; done

Note
At the time of writing, sshd from the minimal install image does not set up ECDSA keys.

Note
By default, the above command will now display SHA-256 fingerprints in Base64 format (as used by more modern versions of the ssh client program); however, if your ssh client still uses MD5 fingerprints, you can display these using the following command instead:

livecd ~ #for K in /etc/ssh/ssh_host_*key.pub; do ssh-keygen -l -E "md5" -f "${K}"; done

Next, move back onto the second, helper PC (on the same subnet), and enter:

user@pc2 $sed -i '/^[^[:digit:]]*192.168.1.106[^[:digit:]]/d' ~/.ssh/known_hosts

user@pc2 $ssh root@192.168.1.106

(The sed command simply removes any record of fingerprints for previous connections to other sshd servers at that IP address, since ssh will refuse to connect if it finds a conflicting one.)

Note
Of course, substitute whatever IP address you got back from ifconfig for 192.168.1.106 in the above commands.

Tip
If you have a large number of existing keys in your ~/.ssh directory, you may get a Too many authentication failures error when attempting to connect. In this case (which will not affect most users), simply add the -o PubkeyAuthentication=no option to your ssh command.

Check the reported key fingerprint and then, if it matches one you noted earlier, continue as below:

... additional output suppressed ...
Are you sure you want to continue connecting (yes/no)? <type 'yes', then Enter>
... additional output suppressed ...
Password: <enter root password you just set>
... additional output suppressed ...

You should find that you can continue configuring remotely, which is much more convenient (as you will have a full windowing environment with graphical web browser, copy and paste, and so on).

Note
Assuming you are using DHCP, if you have to reboot your machine during the following process, bear in mind that it may not come back up with the same address (although with many DHCP setups, it will).

Now, still via this remote login ssh connection (i.e., at the helper PC's keyboard), issue:

livecd ~ #screen

to start a new screen session - this is useful as it allows you to multiplex several virtual consoles, disconnect while lengthy compiles are running and then reconnect later, and so on.

Note
With some (helper-PC-side) terminals, you may get an error issued when trying to run screen, of the form Cannot find terminfo entry for 'xxx'.
If this happens, simply try again with:

livecd ~ #TERM=xterm-color screen

Note
See this brief discussion of how to use screen. And here is an even briefer overview of some commands you may find useful to get you started: Ctrla is the escape character for screen, which you type and then follow up with the rest of the command if necessary; so for example Ctrla then ? to get help, Ctrla then d to detach the current session (disconnect from it from your ssh console, leaving any active commands to run in the background), Ctrla then c to create a new 'window', Ctrla then " (that's a double quote) to list the current windows, Ctrla then n to go to the next window and Ctrla then p to go to the previous window. If you disconnect, you can reconnect to your session from a console (either when logged in via ssh, or directly on the machine's console itself) using

root #screen -D -R

You can also use this command to reconnect to a screen session if e.g. your ssh connection gets dropped for some reason.

Next Steps

Next, we'll prepare the storage on the target machine. Click here to go to the next chapter, "Preparing the LUKS-LVM Filesystem and Boot USB Key".

Notes

< Previous

Home

Next >