Как подавить ошибки псевдонимов в zsh?

Вот как мы справились с этим на предыдущем месте работы.

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

Администраторы будут входить на этот хост-бастион с учетными записями уровня пользователя -, а затем подключаться к целевым системам.

За исключением нескольких из нас, имеющих доступ к root на самом хосте-бастионе, ни один администратор не мог фактически получить доступ к ключам напрямую; вместо этого они использовали команду connect, запускаемую под sudo (как keymaster, а не root )для подключения. Эта команда connect устанавливает переменную среды REMOTE_ADMINв качестве имени подключающегося пользователя и подключается к целевой системе как root.

Затем удаленные системы были настроены на AcceptEnv=REMOTE_ADMINв sshd_configи файлы.bashrc для установки BASH_HISTORYв ~/.bash_history-$REMOTE_ADMIN.

При такой настройке разные .bash_historyфайлы не являются защищенными записями, но они, по крайней мере, различны для не -злонамеренного оглядывания того, что произошло. Запись безопасности находится на хосте-бастионе и показывает, кто и когда подключался. (Мы также использовали двухфакторную аутентификацию для команды sudo connect.)

Кроме того, за исключением подрыва хостов, нет необходимости беспокоиться о корневом доступе за пределами назначенной системы (, будь то злонамеренный или просто для «удобства» ). И хотя ключи можно удалить, нет необходимости делать это только потому, что чей-то уровень доступа изменился.

Вы можете использовать все это решение или его часть; просто иметь .bash_history-$SUDO_USERможет быть достаточно, в зависимости от того, чего вы действительно пытаетесь достичь.