Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    User account - need permission to run scripts via SSH

    General pfSense Questions
    5
    15
    364
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • tkohhh
      tkohhh last edited by

      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!

      JKnott 1 Reply Last reply Reply Quote 0
      • JKnott
        JKnott @tkohhh last edited by

        @tkohhh

        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.

        1 Reply Last reply Reply Quote 0
        • tkohhh
          tkohhh last edited by

          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?

          JKnott 1 Reply Last reply Reply Quote 0
          • JKnott
            JKnott @tkohhh last edited by

            @tkohhh

            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.

            1 Reply Last reply Reply Quote 0
            • stephenw10
              stephenw10 Netgate Administrator last edited by

              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

              tkohhh 1 Reply Last reply Reply Quote 0
              • tkohhh
                tkohhh @stephenw10 last edited by

                @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?

                1 Reply Last reply Reply Quote 0
                • stephenw10
                  stephenw10 Netgate Administrator last edited by

                  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  amd64
                  

                  Steve

                  tkohhh 1 Reply Last reply Reply Quote 0
                  • Derelict
                    Derelict LAYER 8 Netgate last edited by Derelict

                    You need to install the sudo package and use the sudo command 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>
                    
                    1 Reply Last reply Reply Quote 0
                    • tkohhh
                      tkohhh @stephenw10 last edited by tkohhh

                      @stephenw10 Yes, I tried... am I missing something?
                      ssh.PNG

                      1 Reply Last reply Reply Quote 0
                      • Derelict
                        Derelict LAYER 8 Netgate last edited by

                        You are not telling ssh to run any commands. Look:

                        ssh root@192.168.223.1 cat /var/etc/ipsec/ipsec.conf

                        tkohhh 1 Reply Last reply Reply Quote 0
                        • tkohhh
                          tkohhh @Derelict last edited by

                          @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!!

                          1 Reply Last reply Reply Quote 0
                          • awebster
                            awebster last edited by

                            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 testuser for 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 testuser to 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: testuser with 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
                            tkohhh 1 Reply Last reply Reply Quote 1
                            • tkohhh
                              tkohhh @awebster last edited by

                              @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?

                              awebster JKnott 2 Replies Last reply Reply Quote 0
                              • awebster
                                awebster @tkohhh last edited by

                                @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 sudo list 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.

                                1 Reply Last reply Reply Quote 0
                                • JKnott
                                  JKnott @tkohhh last edited by

                                  @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.

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post

                                  Products

                                  • Platform Overview
                                  • TNSR
                                  • pfSense
                                  • Appliances

                                  Services

                                  • Training
                                  • Professional Services

                                  Support

                                  • Subscription Plans
                                  • Contact Support
                                  • Product Lifecycle
                                  • Documentation

                                  News

                                  • Media Coverage
                                  • Press
                                  • Events

                                  Resources

                                  • Blog
                                  • FAQ
                                  • Find a Partner
                                  • Resource Library
                                  • Security Information

                                  Company

                                  • About Us
                                  • Careers
                                  • Partners
                                  • Contact Us
                                  • Legal
                                  Our Mission

                                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                  Subscribe to our Newsletter

                                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                  © 2021 Rubicon Communications, LLC | Privacy Policy