Comments 63
Поддерживаю, FreeIPA + Linux-виртуалка с одим мастер-ключем ко всему.
Через правила sudo можно разрешить запуск определенных команд и только с конкретными аргументами, если есть такая необходимость.
Например: пользователь vasya может запускать sudo ssh только с аргументом server1, server2 и switchB
Так же настроить sudoreplay для логирования, после чего каждая ssh сессия будет сохранена и сможет быть проиграна в интерактивном режиме.
Как бонус отсутствие необходимости устанавливать ipa-client на каждом сервере и общий сервер аутентификации с LDAP и удобной web-мордой — что тоже безусловно большой плюс.
Этот вариант уже был и он работал. Далее наша действительность развивалась от него.
Это мои сладкие сны когда у меня будет проект без legacy и я смогу выбрать все технологии и даже ОС на сервере :)
ssh hostname "bash --noprofile --norc"От этого не забыли закрыть? — В статье не вижу.
artem:~ artem$ssh root@149.154.64.101
Last failed login: Mon Mar 19 08:31:53 EDT 2018 from 58.242.83.24 on ssh:notty
There were 23 failed login attempts since the last successful login.
Last login: Mon Mar 19 08:31:04 2018 from 188.120.252.193
bashrc Connection DENY
Connection to 149.154.64.101 closed.
artem:~ artem$ssh root@149.154.64.101 «bash --noprofile --norc»
bashrc Connection DENY
А так? ssh hostname -T /bin/sh
Почему bashrc? Такие вещи лучше делать через pam
Я делал примерно так
https://github.com/dmitriy-myz/pam_alerter
В идеале, ключ вообще не должен храниться на сервере, куда пускают сотрудников.
Можно попробовать использовать ssh-agent на отдельном сервере, который логинится на гейт с пробросом агента. Пользователям задавать переменную SSH_AUTH_SOCK.
как защититься от возможности потери ключа пользователемИспользовать сертификаты и отзывать сертификаты при подозрении на потерю сертификата или при увольнении сотрудника.
FreeIPA ещё выше предлагают.
Подход сертификатов прекрасен если все сервера в личном ведении и ты их сам раскатываешь ансибло-чефом.
И вот такую github.com/vaniacer/sshto создает меню на основе файла ~/.ssh/config
Автоматизирует ответ 'yes' при первом подключении к очередному серверу
echo "alias ssh='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'" >> ~/.bash_profile; source ~/.bash_profileОпция UserKnownHostsFile=/dev/null — на ваш вкус.
И тем не менее, это не повод упускать прекрасный инструмент конфигурации через конфиг. До банального:
- если использовать кроме ssh еще инструменты типо sshfs и scp — конфигурация через ~/.ssh/config позволяет использовать host во всех этих командах; а в случае alias'ов нужен алиас на каждую.
- Если нужно добавить/поменять какой-то дефолтный параметр — нужно либо разворачивать alias и делать руками, либо писать команду полностью заново. А ssh_config позволяет использовать всё как и раньше, просто передав необходимый ключ.
И многое другое :)
И крону можно задачи назначать.
Все подходы которые решают задачу возможны.
Соответственно, любой, кто должен получить доступ куда-либо, должен просто-напросто получить временную подпись на свой ключ со стороны ключа CA. Сам ключ CA при этом может располагаться на каком-либо HSM. Согласитесь, это решение гораздо лучше, чем колхоз со «всемогущим ключом» и сервером-прокси для SSH.
А может поставит что-то типа vault-а и отказаться от единого всемогущего ключа?
Или я что-то не понял?
Мы знаем какой сотрудник сколько времени провел на каком сервере. На случае внештатных ситуаций знаем что сотрудник там вводил и что ему отвечало, так как копируется весь ввод и вывод ssh-сессии.
Подскажите, чем вы это делаете?
Last login: Tue Mar 20 21:01:55 2018 from 188.120.252.193
[user@login ~]$ cat /etc/host
cat: /etc/host: No such file or directory
[user@login ~]$ logout
Connection to 149.154.64.101 closed.
artem:~ artem$cat session_log
Last login: Tue Mar 20 21:01:55 2018 from 188.120.252.193
[user@login ~]$ cat /etc/host
cat: /etc/host: No such file or directory
[user@login ~]$ logout
В файле session_log будут все что происходило по ssh, из минусов это когда mc или другая ncurses программа, в файле будут все перерисовки экрана. Дальше или забираем файл или вместо файла сразу пишем в сокет, все на ваше усмотрение.
Я как-то организовывал доступ к клиентам по ssh для большого количества людей разом. Ситуацию упрощало, что ходить они могли с одного бокса. Т.е. сначал шли на некий ssh_box, а потом оттуда к клиенту.
Идея была в том, чтоб у сотрудника не было возможности прочитать приватный ключ, а значит и законнектится с другого хоста (authorized на целевых хостах строго мониторился). Для этого использовался SshAgent поднятый под левым пользователем (скажем master). Приватные ключи принадлежали этому пользователю, а конечный пользователь, скажем vasya использует socket от ssh agent для коннекта.
Разумеется в такой структуре были разные уровни доступа. Например на root у клиентов могли пойти только три человека (два админа и тех.дир), а на пользователя приложения человек 15. Достигалось это запусков нескольких ssh agent, сокеты, которых был доступны разным unix группам.
Единственное, что для такого варианта пришлось пачить ssh agent. Он по дефолту не позволяет коннектится к себе другому пользователю. Вторая засада была в том, что для того, чтоб явно сказать с каким приватным ключом коннектится к хосту надо сформировать список пар host:public_key и положить его в config. На тот момент это было тайное знание, которое я прояснял у разработчиков.
Последним бастионом проверки на каждом сервере выступает .bashrc файл, при инициализации shell по ssh стартует bash, и он проверяет источник подключения
Этот мусор можно сразу убрать. Чтобы обойти эту «защиту» достаточно передать команду по ssh в неинтерактивном сеансе.
А вдруг обнаружится уязвимость в ssh, а тут как раз и логины есть и айпишники есть и даже адрес главного сервера с главным ключом в публичном интернете?
Еще очень советую "ключи на бумаге" хранить с помощью схемы разделения секретов Шамира.
ssh -vvv -i everebody root@149.154.64.101Ловим что-нибудь типа «debug2: shell request accepted on channel 0» и посылаем в этот момент «Ctrl+c»:
Last failed login: Tue Mar 20 02:41:12 EDT 2018 from 58.242.83.24 on ssh:notty
There were 23 failed login attempts since the last successful login.
Last login: Tue Mar 20 02:40:14 2018 from 95.154.75.23
^C-bash-4.2# cat /root/README
Привет всемогущий инжинер. Пароль.
"Другой жизни не будет"Можно автоматизировать с помощью expect или правкой ssh клиента. Вручную тоже очень быстро ловится нужный момент.
Пример для expect:
spawn ssh -vv -i everebody root@149.154.64.101
expect "debug2: shell request accepted on channel 0" { send "\x03" }
interact
К чему такие сложности.
ssh root@149.154.64.101 /bin/sh
SSH у людей не достаточно безопасен.
Вообще заголовок не раскрыт.
Как я понял из статьи, все риски сводятся к тому, что кто-то может иметь ключ без пароля и потерять его.
Чуть не забыл, ещё один момент в защите через башрц:
ssh -L 2222:22.22.22.22:22 -N root@host &
ssh localhost -p 2222
Позволит зайти на удалённый 22.22.22.22 с айпишником "защищённого".
Так как при -N вообще не запускается шелл.
То есть важно проброс портов выключать
SSH у людей не достаточно безопасен. Как я борюсь с паранойей