Find the answer to your Linux question:
Results 1 to 6 of 6
Hi All Can you help me on this thing, here is my scenario.. we had a linux system(server), 1) where had created ssh users in order to access the linux ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2011
    Posts
    3

    How to provide SSH Linux Users less privileiges ?


    Hi All

    Can you help me on this thing, here is my scenario..

    we had a linux system(server),
    1) where had created ssh users in order to access the linux system.
    2) we had edited the sudoers file such that that SSH users will get same privileges as the user gets.
    3) now the problem descriptions is how can we provide less restrictions to the SSH users created , so that the dont get root privileges, how can we configure linux system in order to provide less restricitions


    Regards
    Rakesh

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,356
    Not enough background information.
    1) Can you describe, what kind of work the users do on the machine?
    2) Why do they need sudo at all?
    3) Can you maybe post the relevant sudo config snippet? (in CODE tags, please)
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    Nov 2011
    Posts
    3
    Hi Irithori

    thank you ver much for replying to my question,

    i can provide you the information that you had requested.

    1) For example we had init.d processes say apachehttpd,tomcat etc the user will be deploying his web applications and starting/stopping the init.d processes and he will be having access to /home/ folder in the linux operating system , where as he will be not having access to OS level files like(/bin/,/sbin/ , /etc/ ) .
    2) i order to provide root privileges to ssh users we will be editing sudoers file (please find the sudoers code snippet we are using)
    ## Allow root to run any commands anywhere
    root ALL=(ALL) ALL
    msf ALL=NOPASSWD:ALL


    can you please help us on this.

    Regards
    Rakesh

  4. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,356
    From the sudo config I can see, that you have one user "msf", and that user can execute anything via sudo and even without giving a password.
    Is it correct to assume, that all members of your team use the same login?
    Or did you forget the "%", and msf is a group?

    Anyway, on this machine you have given up control and I would suggest a reimplementation.
    At my workplace there is a strict separation of development systems vs production systems.
    No dev will have root on a prod system, and on the other hand they can rely on a consistent, managed environment from us (operations team).

    There are multiple options:
    1) Reconfigure sudo, so that *only* the two init scripts are allowed.

    2) Provide multiple instances of apache and tomcat on one physical host.
    By tweaking the config files (mostly port numbers > 1024, log and lock locations, datadirs) it is possible, that
    each member can run his own environment via his/her login.
    This will require a rather beefy machine in terms of CPU,RAM,IO
    and some thoughts on how to deploy such a prepared home directory.

    The benefits are, that the user does not need root and still can do what they want.

    3) Every member gets his own dev environment.
    A Virtual Machine solution comes to mind.
    Todays workstation hardware is quite capable of running even multiple VMs.
    A consequence would be, that you have to provide a pxe boot infrastructur, system and configuration setup (via e.g. puppet) and documentation,
    so that the members can quickly deploy new VMs as they see fit.

    The quick solution is 1)
    Personally I like 3), because
    - it distributes load
    - gives freedom to the devs to do whatever they want
    - it creates redundancy, as such a setup is no longer uniq.
    - you can reuse the very same deployment for production use. In fact, you should.
    The danger on 3) is, that the dev VMs "drift away" from the master.
    ie: people install various additional tools, and development work then depends on them.
    Make it very clear, that the VM you manage and maintain is the master and the one to test against.
    You must always face the curtain with a bow.

  5. #5
    Just Joined!
    Join Date
    Nov 2011
    Posts
    3
    Hi Irithori


    thank you very much for responding back,

    for your question , here are the answers from us.

    1) we are using only one ssh suer called msf which is shared by all developers and administrators.

    2) we are using same system/environment for both testing/admin/development and later on which will moved to production.

    3) so that's why we need a mechanism such a way that there can be different users in same system, but they will be having different roles assigned to them.

    based on you points like what you mentioned like creating multiple instance of each processes , we had multiple instance of tomcat which we use for load balancing.

    4) 1) Reconfigure sudo, so that *only* the two init scripts are allowed.

    what is meant by reconfigure sudo , ca you please help me on this.

    regards
    Rakesh

  6. #6
    Just Joined!
    Join Date
    Dec 2011
    Posts
    1
    If everyone is running as the same user and has "all" privledges, you kind of defeated the purpose of using sudo.

    Sudo has two good purposes to it (and if anyone sees that I am wrong please correct me). 1) Giving users restricted access but more than a normal user and 2) accountability. You know who ran what command and what time (as long as your logs are being backed up).

    I worked in a place before where everyone ran as root. I was the new guy and decided to take some Red Hat classes, in my class I learned the importance of sudoers. Despite my protests, the team decided not to use sudo. 2 years later, there was an event that caused a catastrophic application failure. Now because everyone was running as root no one could no for sure who was at fault. In addition our audit logs were not being backed up so we couldn't even see what commands were ran to cause the failure. Well since I was the new guy, I was blamed and fired (despite having no evidence that I was the one at fault). If I had pushed to use sudoers a little more, I might still have that job.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •