I am using Leap 42.3 with KDE desktop and trying to tighten security on a remote device which I presently can access using public key authentication. In other words all is OK from my Leap 42.3 machine at present.
I now wish to make the remote device (RaspberryPi) more secure using ufw.
I have installed ufw on the remote machine and opened port 22 and allowed tcp/udp protocols but I now can no longer access from Leap 42.3.
Displaying my ignorance once again but having read many threads I still do not know what rules I have to create on the remote machine to get this to work. If anybody has time and patience to give me assistance it would be greatly appreciated. Once I have the basics working I want to limit access either to individual machines or one subnet but first I need to get simple connection going once more.
Budge.
On Sun 01 Apr 2018 05:46:01 PM CDT, Budgie2 wrote:
I am using Leap 42.3 with KDE desktop and trying to tighten security on
a remote device which I presently can access using public key
authentication. In other words all is OK from my Leap 42.3 machine at
present.
I now wish to make the remote device (RaspberryPi) more secure using
ufw.
I have installed ufw on the remote machine and opened port 22 and
allowed tcp/udp protocols but I now can no longer access from Leap 42.3.
Displaying my ignorance once again but having read many threads I still
do not know what rules I have to create on the remote machine to get
this to work. If anybody has time and patience to give me assistance it
would be greatly appreciated. Once I have the basics working I want to
limit access either to individual machines or one subnet but first I
need to get simple connection going once more.
Budge.
Hi
To start off with change it away from the standard port… How is ufw
different from using SuSEfirewall… it’s just a frontend to iptables?
Maybe the rules you implemented where not (re)loaded?
You could even setup a cronjob to swap around the ssh ports at different
times…
I would suggest looking at multi-factor authentication for ssh
instead…
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.3|GNOME 3.20.2|4.4.120-45-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
There many ways to authenticate to a firewall, but I’ve never heard of using any kind of key authentication. At best, I know how to do this indirectly by setting up network authentication like LDAP and then associating keys with that network User Account.
You say you set up ufw as your LAN firewall?
What guide did you use to set up your firewall and its authentication methods?
Perhaps if you can post that info, the next step can be taken to understand what is required client-side.
If you’re talking about using SSH using key authentication, that’s another story… and well known since in that case the Firewall simply forwards packets and the authentication is exclusively done on the SSH client and server as though the firewall isn’t there.
Hi Malcolm,
Sorry I didn’t make it clear, my Leap42.3 installation has standard firewall and it is set up normally and is not an issue here. This machine and the remote RPi device are both on the same lan subnet and sit behind a firewall.
It is the local firewall on the remote device I am trying to set up. I use SSH login using key authentication as mentioned by Tsu and it is this that no longer works when ufw is running on RPi.
I have no knowledge of multi-factor authentication and hopefully will be able to go into the techniques you raise but first I would like to get the basics working between my Leap 42.3 machine and the RPi.
Many thanks once more for your reply,
Budge
Hi Tsu, many thanks. Sorry I didn’t make my problem clear. What I am trying to do is set up firewall on remote device so key authentication from my main machine will work. The way you put it it would appear what I must do is set up firewall to forward the necessary packets so the ssh process works. Grateful for help on this please to move me forward.
Once I have all this mastered I need to progress to hardening RPi to enable me to expose it to the wan but one step at a time and only after present setup is working!!!
Budge
The RPi is in a remote location behind a firewall.
The RPi is running ufw on itself.
The firewall “device” is unknown (You haven’t described what it is)
You are trying to connect through the firewall to your RPi.
Hi Tsu,
The RPi is on the subnet with no intervening device but is running ufw on itself. There is no separate firewall device other than at the wan connection router which has the dhcp server and controls the subnet.
Leap 42.3 with “yast” firewall >lan subnet>RPi with ufw.
The Leap42.3 machine is my main machine and used to access devices on the lan subnet. I have ssh working with key authentication to RPi when ufw is not active. I want to set up RPi ufw and still be able to access it from may main machine using ssh.
Hi Tsu,
Actually it is OSMC which is I believe an abbreviated version of Raspbian intended for multimedia use and all based on Debian.
I am inclined to believe that this should not be critical but do not understand why my first attempt at setting a rule to open port 22 does not work. Here is what I get:-
Just like in openSUSE, the available User tools to do things like manage the firewall are different for each distro.
And, like in openSUSE it may be advisable to use “normal procedures” like using any available User tool before you start editing the iptables files directly.
When troubleshooting any kind of network service on a device,
There are 2 main possible points of failure you need to address first… only after verifying both are not a problem can you get into the weeds.
The Network Service is blocked (typically by a Personal Firewall)
If you’re setting up in a protected LAN (advisable), it’s probably a good idea to drop your firewall entirely and configure this only <after> the following
The Network Service must be running.
Should make sense and is often overlooked when people focus on the firewall.
Probably the most common way to verify the Network Service is available is to probe the port using telnet, but there are many other more complex tools. Telnet is popular because it’s simple and works for everything if you only want to know whether there is an active service on the other side of that port.