User account - need permission to run scripts via SSH
-
Hi all,
I am trying to follow this guide (https://community.home-assistant.io/t/ip-blocking-at-pfsense-instead-of-in-hass/115063) to allow a program (fail2ban) to add IPs to an alias in pfSense. In essence, fail2ban will SSH into pfSense and run a script. The script works when I run it locally, and it works when I SSH using the admin account. However, the admin account goes to the menu rather than the shell, so automating the script isn't going to work.
In order to get around this, I created a new account in pfSense with shell access. This takes me directly to the shell, but when I try to execute the script I get a notification in pfSense stating: Unable to open /cf/conf/config.xml for writing in write_config()
I tried adding the "WebCfg - Firewall: Alias: Edit" privilege, but I'm still getting the same error. Finally, I tried adding the new user to the admins group, but alas I am still getting the same error.
Is there a way to grant this user a privilege that will eliminate the "unable to open" error? Short of that, is there a way to turn off the admin menu so that an SSH session goes directly to the shell?
Thanks for your help!
-
Have you tried using the su command to become root and then run the script? You'll have to add the admin user to the wheel group.
-
You'll have to forgive me, as I'm not very familiar with linux... what is the su command? And what is the "wheel group"?
Do I infer from your response that I won't be able to run this script with a user other than root/admin?
-
Actually, it's FreeBSD, not Linux. The su command is used to switch users, so you could log in a a mere mortal and then become root, to do things that require that privilege. You'll have do some research on this sort of thing, if you're going to write & run scripts. Please note, there are some differences between Linux and FreeBSD, so make sure you're learning from the right source.
-
Did you try just connecting as root? In pfSense root and admin are effectively the same account but root is required for sftp for example.
Steve
-
@stephenw10 I did try connecting as root, and I'm able to do what I want manually, but the problem is the menu appears when connect as root, and therefore I can't just SSH in and run a single command. I have to get past that menu first.
@JKnott Thank you for the correction, and sorry for my ignorance. I'm of course happy to do whatever research I need in order to figure this out. I guess the main question I have is this: is there a privilege I can give to a user account that will get me passed the "Unable to open /cf/conf/config.xml for writing in write_config()" error? Or is that simply not possible?
-
But did you actually try it? There is a difference between those usernames:
steve@steve-MMLP7AP-00 ~ $ ssh admin@8860.stevew.lan "uname -a" FreeBSD steve@steve-MMLP7AP-00 ~ $ ssh root@8860.stevew.lan "uname -a" FreeBSD 8860.stevew.lan 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 8bad71faaf5(factory-RELENG_2_5) pfSense amd64Steve
-
You need to install the sudo package and use the
sudocommand to run shell commands as root.But like @stevew demonstrated you should be able to run single commands using the root account.
$ ssh root@192.168.223.1 cat /var/etc/ipsec/ipsec.conf Password for root@fw-223: # This file is automatically generated. Do not edit config setup uniqueids = yes <snip> -
@stephenw10 Yes, I tried... am I missing something?
-
You are not telling ssh to run any commands. Look:
ssh root@192.168.223.1cat /var/etc/ipsec/ipsec.conf -
@Derelict Ahhh, ok! I didn't understand that it would behave differently if I included a command along with the SSH connection. It's working now with root as the user. Thank you everyone for your efforts in helping me understand this!!
-
Logging on as root is generally not recommended / insecure. A better way would be to create a dedicated user that will use public key for logging on and and authorize exactly what commands they can run using sudo.
- Install sudo package
- Add a new user: System / User Manager -> Add (let's call this user
testuserfor this example) - Set a very complicated password (we won't be using it)
- >>Paste your public key that you will be using to connect with.<<
- Save the user
- Go back and edit
testuserto expose the permissions part of the GUI that doesn't appear initially (bug?) - Grant the user User - System: Shell account access
- Save the user
- Edit the sudo config (System / sudo)
- Add User:
testuserwith Run As User: root, Check No Password, preferably, enter the allowed command list, or ALL
To test:
- ssh
testuser@pfSense - you should not be prompted for a password since you will be using public key login
[2.4.4-RELEASE][testuser@pfsense.local]/home/testuser:- id - you'll see the default user ID
(uid=2000(testuser) gid=65534(nobody) groups=65534(nobody)- sudo id - now root user ID
uid=0(root) gid=0(wheel) groups=0(wheel),2(kmem),3(sys),4(tty),5(operator),20(staff),31(guest),1999(admins)- sudo your-script -your script will run as root
To run your script from remote:
- ssh
testuser@pfSense sudo your-script
-
@awebster for the sake of education, why is logging on as root considered insecure? What are the advantages of creating a dedicated user if that user can just sudo and do everything that root can do anyway?
-
@tkohhh In general, logging on as root should be restricted to the local console only. There are considerable arguments in favor of this "best practice", and of course there are some dissenting opinions, neither of which I will get into here.
You are correct in saying, if you use ALL in the
sudolist allowed commands, the net effect is that you can do anything root can, which is why it is preferable to limit what commands are allowed. For instance to only allow your specific script(s) to run would be good security practice, as it would prevent someone from simply doing 'sudo sh' and end up in a root shell. -
@tkohhh said in User account - need permission to run scripts via SSH:
why is logging on as root considered insecure?
Root has absolute power and can do a lot of damage. Mere mortals cannot damage anything out of their own area. If you only have local access and no one else can log in with the root ID, then you're okay. One common practice is to require those with root access to log in with their own ID, then su to root. This creates a log entry to show who assumed root access. Of course, never allow root login via anywhere beyond the local LAN. If I want to connect remotely, then I have to fist connect to my main system and then connect to my firewall from there. You can also enable passwordless connections, which use a public/private key pair, to ensure connections only from that one computer.
