Tutorial/ Configure Linux Lite 3.0 Ad Hoc Wifi/ SSH From Other Linux Computer
Setting Up Our Ad Hoc Wifi Connection In Linux Lite 3.0 For SSH Server Access/ SFTP
At the outset it is sensible to remember the Windows idea of a “hosted network” when considering Linux ad hoc wifi. What I mean by this is that the new ad hoc wifi network must be set up on the same Linux computer where the SSH server resides. The SSH client side of ad hoc wifi is only to make a secure connection to the SSH (hosted network connection) of the wifi network created on the SSH server side. It’s nature (no DHCP) makes it technically difficult to test with ping so we won’t. Certain things done in a correct order can ease the creation of such an ad hoc connection in Linux Lite 3.0 as network manager in Xenial (Linux Lite 3.0 version) is now predisposed to often correctly configuring an ad hoc wifi network (except for WPA) and generating a private IPv4 address during setup. To avoid IP conflicts, and allow shared Internet provider connections via ethernet cable, Linux network manager generally defaults to the address range 10.0.0.0 to 10.255.255.255 for ad hoc wifi, reserving the 192.168 range connections for DHCP router host/client assigning.
The first thing we need to do is download and install SSH server on our Linux Lite computer. Make sure you are connected to the Internet and click >Menu>System>Install/Remove Software to open Synaptic in Linux Lite. Type in your password when prompted and click the >Authenticate button. Make sure the left pane is set to >All and in the search box type ssh. Scroll through the package list and find the package: openssh server – 1:7.2p2-4ubuntu2.1. Left click on it, and select mark for installation. Agree to the dependencies and download and install it to your Linux Lite 3.0 computer.
If you’re a new Linux user or nervous about the terminal and/or the nano editor, open a terminal and enter the following command: sudo cp /etc/ssh/sshd_config{,.bak} This will back up the default sshd configuration file in case you mess up.
Now type the command: sudo nano /etc/ssh/sshd_config and the configuration file of your newly installed ssh server will appear. It will run as is, with the defaults enabled from Ubuntu, but to simplify things for setting up our ad hoc wifi connection we are going to edit the file. Use the down arrow on your keyboard to navigate through the file. In the first few lines find: # What ports, Ips and protocols we listen for. The next line should read: Port 22. The next line should read: # Use these options to restrict which interfaces/protocols sshd will bind to. At the first: #ListenAddress line navigate to the end of the line with keyboard arrows and backspace out the existing entry and type 10.42.0.1. At the second #ListenAddress line repeat the navigation and backspace out the entry and type: 0.0.0.0 if it’s not already there.
Next navigate through the file to the line PermitRootLogin and check to see that it reads prohibit-password. The line below: StrictModes should read- yes. Navigate further down with the arrow key until you find the line: x11Forwarding and backspace out the no replacing it with yes. Navigate down to the SFTP subsystem files and make sure the last line UsePAM is set to yes. Now hit control+x and then enter shift+y at the prompt, and then hit >enter at the file selection prompt. You new sshd configuration file is saved.
Now if you a using a wifi Internet connection you will have to disconnect from the Internet so copy this tutorial to a Libreoffice file first, and save it.
Disconnect from the Internet and open a terminal and type the command: sudo systemctl restart ssh. Your ssh server will now start. Click on the tray wifi icon (exclamation point when disconnected) and open the window dialogue from the menu >Create new wifi network. Leave Connection set to new. In the box next to name enter any name you like for your network. For wifi security choose WEP 128bit passphrase. Check the show key box, and then click on the key box and enter a password of thirteen mixed characters. Click the >create button. Because SSH server is running, and we have already bound it to a lower scale IP addressed interface, network manager will create an ad hoc wifi network with the IPv4 address we bound SSH server to which will connect immediately after prompting for and confirming the password. If it connects, disconnect it and click the >wifi tray icon again, clicking >edit connections, and select it from the list to uncheck the >automatically connect to this network box, and uncheck the >automatically connect to vpn box, and check the >All users may connect this connection box.
If your new network connected immediately you are done and have working Linux ad hoc wifi so now click >Save. If it did not connect Click the >Wifi Security tab and check the box >show password and verify you have entered the correct password, also verify that the security box reads >WEP 128bit passphrase. Also click the >Wifi tab and verify that mode is set to >ad hoc. Finally click on the >IPv4 tab and verify that the method is >Shared to other computers. Click the >Save button and close the remaining >Network Connections window. Find the network again by clicking on the tray icon, and selecting >Connect to hidden network. Click the drop down menu reading >new, and find and select your network from the list. Click the button >connect, and it should now connect.
Once connected click >Menu>Settings>Settings Manager and navigate to and click on >Firewall Configuration. Enter your password when prompted and click >Authenticate. When Firewall opens, because we are running one off server instances, and running on ad hoc wifi, we are not going to go through the process of adding firewall rules, but rather simply set the incoming setting to >allow and close the firewall dialogue. Of course the Firewall in Linux Lite can be configured to special rules, but that is another tutorial, and really not particularly necessary for ad hoc wifi without DHCP with a server bound interface, and a range no farther than sixty feet. At this point it’s good praxis to log out and reboot your computer, so do it. After you log back in, open a terminal and type the command: sudo systemctl start ssh and then connect to your new hosted ad hoc wifi network.
The laptop I’m using to connect to my Linux Lite 3.0 desktop SSH server is running the newest version of Solydx. I am not going to go through all the steps concerning its configuration other than to say that network manager has subtle, but not particularly difficult to sort out differences between distros. Firewalls have the same kind of subtle distro quirks as well. For the most part, network managers, and firewalls on Debian based systems, and Ubuntu based systems work essentially the same, and are capable of the same things in closely matched versions. Things vary of course with RHEL, Mint, and free BSD bases. All we are going to do with the laptop is set the firewall like our Linux Lite desktop is set, and make sure we can connect to its hosted wifi network. If it does not immediately connect, and in this case by default it used the wrong WEP setting we will just manually change what needs to be changed. The client side of ad hoc wifi connections can be manually IPv4 addressed, which is also the case for this laptop, and we entered 10.42.0.2 then 255.255.255.0 and 0.0.0.0 and connected quite nicely after the first attempt hung because of the wrong WEP setting. We simply right clicked on the tray icon, and selected edit connections, found it, and edited it.
Once connected we opened Thunar on the Solydx laptop, backspaced out the URI address bar and typed - - sftp://10.42.0.1/home/Linux Lite user name/ and hit >enter, and I was prompted for user name and password, and entered my Linux Lite user name and password and the files on my Linux Lite 3.0 desktop computer loaded immediately to my Solydx laptop. When the two computers are close enough together the transfer speeds can be dazzling, not to me so much as I have business class broadband, but if you are suddenly running at 72mb/s after trudging along at 7 to 12 on your normal wifi connection you will appreciate another advantage of ad hoc wifi connections.
Good Luck All. Our next project will be a remote desktop on Linux to Linux ad hoc wifi
TC
*Read This Note - (As I noted in the last tutorial on Windows ad hoc wifi, after using the hostednetwork, you will have to re-enable DHCP for your Internet provider broadband wifi connection, something that can be done easily with the Windows network troubleshooter. I have been asked/criticized to elaborate a little bit as to why this must be a condition for Windows, and how it is essentially a part of the network and sharing troubleshooter software, and though it can be be reassigned, most ordinary windows users should not attempt to tamper with this unless they are very sure of what they are doing, because it will disable the auto-configure DHCP functionality in Windows network manager, and render the Windows network troubleshooter ineffective.
Windows uses the APIPA (Automatic Private IP Addressing) Windows reserved range of IPv4 addresses (169.254.0.1 to 169.254.255.254) for its basic network manager auto-configure DHCP functionality. Basically these addresses are simply client fall back IP addresses included in Windows ARP to allow IP addresses to be assigned for connectivity when DHCP fails on a remote server, or for some reason on a Windows client. They are part of the Windows network troubleshooter, and are automatically assigned in instances of server DHCP failure to allow client side DHCP to continue to run and periodically check for returned DHCP functionality. This process is also one those manually invoked with the Windows network troubleshooter. So in essence we are waylaying the Windows network troubleshooter and putting it to work for us to allow private ad hoc wifi when we use these APIPA addresses.
This particular method of auto-configuring recognition instances of DHCP in the Windows network manager is why we must use APIPA addresses to obtain ad hoc wifi in Windows in the first place. It is falsely recorded by some pseudo-technical advisories that using these addresses for private networking should not be done. As we are essentially only temporarily disabling DHCP auto-configure, and restoring it after use, it is just plain stupid to argue that IP addressing conflicts can arise. In fact IP addressing conflicts cannot occur when auto-configure DHCP is not running in Windows because connectivity to public addressing via DHCP is impossible in Windows under that condition, and if it wasn’t that way APIPA would not serve its intended redundant functions in Windows.
We Linux users may wonder what in the world is the point of this redundant APIPA + ARP convention and auto-configure DHCP fall back protocol, unless of course we consider the Windows network troubleshooter and all the Windows GUI clicker friendly so called repair and fix tools, and the millions of users brought up on such devices, often experiencing their first computing in such environments. Certainly we Linux users can set up ad hoc wifi, and bind specific interfaces to our servers, virtual servers, and clients, and key and password them all, and run several kinds of packet encryption effectively. Finally we downloaded LinSSID in our last tutorial simply to provide a simple GUI radio signal scanner to correctly verify our Windows hostednetwork ad hoc wifi broadcast signal because Windows hostednetwork ad hoc wifi cannot be simply pinged, generally returning null replies.)
