Разрешить обычным пользователям SSH использовать закрытый ключ, который они не могут прочитать

Допустим, у меня есть набор машин (называемых здесь машинами клиентов), в которые только небольшому списку людей (называемый вспомогательный персонал) разрешен доступ по SSH с использованием только одной учетной записи на машине (учетная запись для доступа в службу поддержки).

Предполагается, что сотрудники службы поддержки могут входить в систему клиентов только с помощью ключей. Кроме того, вспомогательный персонал может развиваться, поэтому тому, кто покидает вспомогательный персонал, не разрешается входить на любой клиентский компьютер. Поэтому сотрудникам запрещено читать закрытые ключи, используемые для входа в машины клиентов. Также запрещено изменять authorized_keysфайл на компьютерах клиентов.

Чтобы реализовать эту конфигурацию, у меня была идея использовать SSH-прокси, в который будет входить персонал службы поддержки (с аутентификацией LDAP, но это еще одна проблема), и который содержит закрытые ключи.

Вопрос в том, как разрешить персоналу службы поддержки использовать закрытый ключ SSH, не читая его?

Я считаю, что мне нужно создать демон, работающий от имени пользователя root на прокси-машине, который примет запрос пользователя и откроет для него сеанс SSH, но я понятия не имею, как это сделать. Любые идеи?

Я бы предложил пару вариантов.

1. Защитите ключ ssh и потребуйте использования команды sudoподдержки. Вы можете сделать это прозрачно с помощью обертки. Вызовите оболочку, скажем, /usr/local/bin/ssh-supportи пусть она будет содержать что-то вроде этого (не проверено):

   #!/bin/bash
   export PATH=/usr/local/bin:/usr/bin:/bin
   export IFS=$' \t\n'
   export SUSER=ssupport
   
   # Restart if not running under sudo
   test "X$1" != 'X-S' && exec sudo -u "$SUSER" /usr/local/bin/ssh-support -S "$@"
   shift
   export SHOME="$(getent passwd "$SUSER" | cut -d: -f6)"
   
   # Extract single argument as hostname LABEL and validate that we have
   # an RSA private key for it. The target username, real hostname, port,
   # etc. can be defined in ~/.ssh/config for the user $SUSER (ssupport)
   label="$1"
   idfile="$SUSER/.ssh/id_rsa_for_$label"
   cgfile="$SUSER/.ssh/config"
   
   ok=true
   [[ "$label" =~ '/' ]] && { echo "Invalid label: $label" >&2; ok=; }
   [[ ! -s "$idfile" ]] && { echo "Missing identity file: $idfile" >&2; ok=; }
   [[ ! -s "$cgfile" ]] && { echo "Missing configuration file: $cgfile" >&2; ok=; }
   
   if test -n "$ok"
   then
       logger -t ssh-support "$SUDO_USER requested ssh to $label"
       exec ssh -i "$idfile" -F "$cgfile" "$label"
   fi
   exit 1

   Это потребует записи в sudoersфайле, которая позволит пользователям в supportгруппе использовать инструмент. Эта команда позволяет им запускать ssh-supportинструмент от имени ssupportпользователя, который вы должны создать. Это не дает никаких привилегий root.

   %support ALL = (ssupport) /usr/local/bin/ssh-support

   Если вы удовлетворены тем, что пользователям службы поддержки не нужно предоставлять свой собственный пароль для запуска инструмента (в соответствии с запросом, вызванным самим sudoсценарием), вы можете изменить sudoersопределение следующим образом:

   %support ALL = (ssupport) NOPASSWD: /usr/local/bin/ssh-support

   Предполагая, что вы PATHсодержали, /usr/local/bin/вы бы назвали это с ssh-support clientname. Также предположим, что вы создали ssupportпользователя так же, как /home/ssupportвы создали бы /home/ssupport/.ssh/id_rsa_clientnameи /home/ssupport/.ssh/id_rsa_clientname.pubкак пару сертификатов, и у вас есть запись хоста /home/ssupport/.ssh/configдля clientnameэтого, определяющая пользователя, хост, порт и т. Д. Для целевой машины. Возможно, вы явно отключите пересылку X11, переадресацию портов и т. Д. Как обычно, /home/ssupport/.sshкаталог должен быть защищен разрешениями 0700.

2. Предоставьте каждому участнику поддержки свою собственную учетную запись локального пользователя, и пусть каждый человек использует свой собственный закрытый ключ ssh для доступа к серверам клиента. Когда человек покидает группу поддержки, вы удаляете его ключ ssh с серверов клиента. Это означает, что вам больше не нужно беспокоиться о том, чтобы ваши сотрудники не знали секретный ключ ssh.

Что вы действительно хотите сделать, так это использовать SSH CA и подписывать ключи, используемые каждым специалистом службы поддержки (у них должны быть свои собственные ssh-ключи, например, паспорта), и настраивать серверы ваших клиентов для использования TrustedUserCAKeys /etc/ssh/users_ca.pubв / etc / ssh / sshd_config. Таким образом, сервер примет любой ключ, подписанный ключом CA (к которому у вас есть доступ), и вы сможете отозвать ключи людей, которые больше не поддерживают, даже не касаясь авторизованных ключей.

Быстрый поиск «ssh ca» указал на этот учебник: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with -ubuntu (прокрутите вниз до раздела «Как настроить пользовательские ключи») - хотя в руководстве упоминается Ubuntu, он не зависит от распространения, но вам нужна свежая версия OpenSSH, которая поддерживает SSH CA

Еще одна хорошая запись в блоге на эту тему - https://ef.gy/hardening-ssh (прокрутите вниз до «Сертификаты SSH»).

Обратите особое внимание на то, что вы можете подписать ключ, чтобы он действовал в течение ограниченного времени, чтобы он автоматически истек!

Существует несколько различных ответов, включающих скрипт-обертку для ssh, вызываемый через sudo или setuid-исполняемый файл (для какой-то специальной учетной записи без полномочий root ). Как говорит nkms , прохождение всех аргументов через ssh позволяет пользователю выполнять произвольные действия с ключами ssh, которые мы пытаемся защитить. Другая крайность, которую некоторые придумали, - разрешить только имя хоста.

ОП говорит, что администраторы должны иметь возможность загружать вещи.

У вас может быть две разные оболочки fixed-args-to-ssh. Один для входа в систему, другой для scp. Нет пользовательских аргументов, кроме имени хоста (и имени файла для загрузки).

Или скрипт-обертка, который использует getoptсам себя для разбора очень ограниченных опций и включения вещей в в основном фиксированную команду ssh. Игнорирование (или ошибка) для нераспознанных опций - это путь.

Не пытайтесь отфильтровать «опасные» параметры ssh, просто напишите обертку, которая может делать две вещи: интерактивный вход в систему или загрузку файла (локальные и удаленные имена файлов). Я думаю, тебе все еще нужно провести там дезинфекцию.

На самом деле, все еще легко ошибиться. Вы должны найти способ запретить пользователю давать файл, содержащий ключи ssh, как локальный файл. Таким образом, вы все еще пытаетесь думать обо всем, что нужно запретить, вместо того, чтобы начинать с того, чтобы ничего не позволять. Было бы неплохо убедиться, что имена файлов не содержат ни одного, @ни :.

Если вы настроили прокси-сервер SSH, вы можете договориться, что оболочка (in /etc/passwd) ваших сотрудников не настроена на оболочку, такую ​​как bash, а вместо этого представляет собой простой скрипт, который не разрешает доступ к оболочке. Вместо этого он запросил бы целевое имя хоста ( read target), затем exec ssh "support@$target".

Обратите внимание, что использование такого прокси-сервера может затруднить использование таких инструментов, как scpпередача файлов на клиентские компьютеры или с них. Это может быть проблемой или преимуществом!

Сотрудники службы поддержки всегда подключаются через этот прокси-сервер и только с него, поэтому клиенты могут просто аутентифицировать прокси-компьютер с помощью HostbasedAuthentication .

Допустим, прокси-машина supporters.pcи вы оказываете поддержкуcustomer.pc

customer.pc будет HostbasedAuthentication да в /etc/ssh/ssd_config, supporters.pc перечисленных в /etc/ssh/shosts.equivи его открытый ключ /etc/ssh/ssh_known_hosts.

Когда ваш персонал службы поддержки ssh customer.pcвойдет в support@supporters.pc и выполнит его, он вызовет ssh-keysign (8) (который должен быть настроен), который будет обрабатывать подпись ключей с помощью файла, который вы не можете прочитать, и предоставить доказательство supporters.pc, что соединение действительно происходит с supporters.pc . Поскольку customer.pc доверяет supporters.pc , ваш сотрудник входит в систему поддержки .

Используйте бинарный файл-обертку

Для этого конкретного случая использования (см. Важное примечание ниже), одна возможность состоит в том, чтобы создать пользователя (скажем support-ssh) специально для этих исходящих соединений SSH, а затем установить небольшой двоичный файл-обертку, который исполняется /usr/bin/ssh.

• Не копируйте + chmod сам sshбинарный файл, потому что вы не забудете повторять его каждый раз, когда применяете обновления безопасности.
• И не используйте rootв качестве более привилегированного пользователя, по причинам, которым я доверяю, это очевидно.

Это функционально эквивалентная альтернатива использованию sudoдля повышения привилегий support-sshучетной записи со следующими компромиссами:

• Это меньше и меньше sudo, так что меньше риск появления ошибки конфигурации, чем вы предполагали.
• Вы несете ответственность за правильное кодирование - делайте это только в том случае, если вы очень осторожны и (в идеале) имеете опыт кодирования, критичного для безопасности.
• Его можно sudoнастроить более конкретно, чем (но чем больше кода вы пишете, тем больше вам нужно проводить аудит для обеспечения безопасности).

Двоичный файл оболочки должен указывать HOMEна support-sshдомашний каталог пользователя, чтобы sshподобрать соответствующий ssh_configи закрытый ключ. Но вызывающему пользователю не должно быть разрешено читать ~support-ssh/.ssh/или его содержимое.

Обертка может быть такой простой, как:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    setenv("HOME", "/home/support-ssh", 1);
    /* allow only a single, non-option argument */
    if (argc!=2 || *argv[1]=='-') {
        fprintf(stderr, "Usage: %s <hostname>", argv[0]);
        exit(EXIT_FAILURE);
    }
    execv("/usr/bin/ssh", argv);
    return EXIT_FAILURE;
}

Вы можете захотеть быть более строгим и проверить, что аргумент argv[1]находится в наборе разрешенных имен хостов. Или менее строгие, и позволяют (подмножество) аргументов опции. Возможно, вы захотите полностью заменить переменные окружения (но оставьте важные, такие как TERM, LC_*и т. Д.); обратите внимание, что LD_LIBRARY_PATHи LD_PRELOADособенно опасно.

Аналогичная программа-обертка может быть предоставлена ​​для scpпри необходимости.

Примечание о применимости

В этом ответе рассматриваются конкретные обстоятельства вопроса, когда пользователи по контракту обязаны соблюдать процедуры, и существуют санкции (например, увольнение) за их нарушение. Предполагается, что вы хотите не допустить, чтобы сотрудники случайно копировали личные ключи, вместо того, чтобы помешать определенному злоумышленнику получить несанкционированный доступ.

Я придерживаюсь мнения, что безопасность достигается как с помощью технических, так и нетехнических средств защиты, и что баланс, достигнутый здесь, или с помощью использования sudo, соответствует представленной ситуации.