Enjoy! Isolate Authentication Server in Open Source

    isolate

    The work of the team of system administrators comes when there are too many supported servers. Or maybe there are a lot of people, and again, security: if something went wrong, you need to delete keys from everywhere.

    We have 300 customers. For some, this is “only”, but for us it is almost 2000 servers for maintenance. To store, update and manage a database of 2000 passwords for 60 employees, to manage access to it and not to explain to the client each time that 60 people will know the passwords to its servers at the same time, we created an authentication server and named it Isolate. Under the cat, a description of the functions and a link to Github - we posted it in Open Source.

    We have separate authorization servers through which employees get to a specific supported server. We ourselves have long and successfully used this development, and now we decided to give it a name and share it with the community.

    So, Isolate is a set of uth server and ansible-playbook utilities for quickly deploying it. It allows us to log in using a hardware key (security above all!) And conveniently manage a huge number of projects / servers. Wherein:

    • employees do not know the root password (again, security);
    • in case of emergency, the employee’s hardware key is deactivated on the auth server, and it loses access to client servers (fortunately, we didn’t have such situations);
    • all SSH sessions are recorded - you can consider the time spent on the servers.

    Accepting the server for support, we create a sudo user on it and register the server auth key. Next, the employee logs in to the auth server using the hardware key (we use yubikey), the s (search) command finds the server (by name of the project, server, website, etc.) and connects to it using g (go) via SSH.

    Highlights of Isolate:

    • users do not have access to the private key;
    • all outgoing SSH sessions are logged;
    • only system access controls are used (SELinux support in the near future);
    • Login to Isolate is performed using a one-time password (2FA, OTP); You can use either hardware keys, or everyone’s favorite Google Authentificator;
    • SSH configuration manager with the ability to connect through an SSH proxy server; support for servers in a VPN through an external gate;
    • installs through Ansible, but requires intervention in system files (in manual mode);
    • CentOS 7, Ubuntu 16.04, Debian 9 are supported.

    What does it look like


    Example server list:

    [~]$ s .
    myproject
    ------
    10001   | 11.22.22.22   | aws-main-prod
    10002   | 11.33.33.33   | aws-dev
    10003   | 11.44.44.44   | vs-ci
    ------
    Total: 3
    [~]$

    the point s . in this case is as a universal pattern for searching all servers.

    An example of entering a server with a custom port and SSH-proxy:

    [~]$ g myproject aws-dev
    Warning: Permanently added 3.3.3.100 (RSA) to the list of known hosts.
    Warning: Permanently added 10.10.10.12 (RSA) to the list of known hosts.
    [root@dev ~]$

    An example of entering an arbitrary server (without a config in ISOLATE) with arbitrary parameters:

    [isolate ~]$ g 45.32.44.87 --user support --port 2232 --nosudo
    Warning: Permanently added 45.32.44.87 (RSA) to the list of known hosts.

    Principle of operation


    The installation is described in sufficient detail in README on Github , we’ll immediately talk about how it works.

    Access itself is delimited by system users of the OS. As an access layer, a sudo + ssh.py wrapper is used, the purpose of which is to prevent dangerous constructions from getting into sudo; ssh.py verifies the arguments and starts the SSH client, this is where its responsibilities end.

    For instance:

    $ sudo -l
        (auth) NOPASSWD: /opt/auth/wrappers/ssh.py
    $ sudo /opt/auth/wrappers/ssh.py -h
    usage: ssh-wrapper [-h] [--user USER] [--port PORT] [--nosudo]
                       [--config CONFIG] [--debug] [--proxy-host PROXY_HOST]
                       [--proxy-user PROXY_USER] [--proxy-port PROXY_PORT]
                       [--proxy-id PROXY_ID]
                       hostname
    positional arguments:
      hostname              server address (allowed FQDN,[a-z-],ip6,ip4)
    optional arguments:
      -h, --help            show this help message and exit
      --user USER           set target username
      --port PORT           set target port
      --nosudo              run connection without sudo terminating command
      --debug
      --proxy-host PROXY_HOST
      --proxy-user PROXY_USER
      --proxy-port PROXY_PORT
      --proxy-id PROXY_ID   just for pretty logs
    ------

    This script is also responsible for logging - it forms the names of the log files and their location, determines the name of the user who made sudo, creates directories for the log files. Next to each log is a * .meta file containing the object of the current connection in JSON.

    The helper.py script includes all the basic functions, isolation with ssh.py will allow even complex logic to be implemented without fear of an error with the definition of user rights or some other unsafe function.

    The functions used in shared / bootstrap.sh are wrapped in a script.

    For example, server search:

    s () {
        if [[ $# -eq 0 ]] ; then
            echo -e "\\n  Usage: s  \\n";
            return
        elif [[ $# -gt 0 ]] ; then
            "${ISOLATE_HELPER}" search "${@}";
        fi
    }

    You can work with proxies without installing additional packages. Enough SSH server and nc / netcat installed on it. You can also use the port forwarding function in modern SSHD / SSH, but this technique is not recommended, since there are still quite a lot of outdated SSHDs that do not support this function.

    When trying to connect with the / alias g function, helper.py is also called, which checks the arguments, classifies the address / IP / FQDN / project and starts ssh.py with the necessary arguments. If you try to log in via IP / FQDN without specifying project / group, the default config for SSH will be used.

    All settings for the server are available only with an exact indication, for example:

    $ g rogairoga nyc-prod-1

    Or, if the server is behind the corporate proxy after the project name, you can specify any FQDN / IP address.

    $ g rogairoga 192.168.1.1

    all usual additional arguments for g are also available:

    $ g rogairoga 192.168.22.22 --port 23 --user support --nosudo

    It is also possible to login by server ID.

    $ g 12345

    Instead of a conclusion


    The source code for Isolate is available on Github . We hope that our solution will help many DevOps teams to structure and simplify work with servers. We are waiting for comments, wishes and, of course, a pool of requests! Suggest ideas or ask questions in Telegram chat .

    Our future plans:

    • differentiation of access rights (user-project);
    • helper for transferring files through an auth server from / to a specific machine;
    • integration with Zabbix (Tech Preview already exists!).

    And next we want to open up our Telegram client - you can read about it here .

    Also popular now: