Время от времени я получаю странные просьбы об удаленной поддержке, устранении неполадок и / или настройке производительности в системах Linux.
В крупных компаниях часто уже есть хорошо отработанные процедуры по предоставлению удаленного доступа продавцам / поставщикам, и мне нужно только их соблюдать. (Лучше или хуже.)
С другой стороны, небольшие компании и частные лица неизменно обращаются ко мне, чтобы проинструктировать их о том, что им нужно сделать, чтобы создать меня. Обычно их серверы напрямую подключены к Интернету, и существующие меры безопасности состоят из значений по умолчанию для любого их дистрибутива Linux.
Почти всегда мне понадобится доступ на корневом уровне, и тот, кто будет настраивать доступ для меня, не является опытным системным администратором. Мне не нужен их пароль root, и я уверен мои действия не будет злонамеренным, но какие достаточно простые инструкции я должен дать:
(И да, я знаю и всегда предупреждаю этих клиентов, что, если у меня есть доступ администратора, скрытие любых вредоносных действий является тривиальным делом, но давайте предположим, что мне нечего скрывать, и я активно участвую в создании контрольного журнала.)
Что можно улучшить с помощью приведенных ниже шагов?
создать учетную запись и безопасно обмениваться учетными данными
Я предоставляю хэш пароля и прошу, чтобы моя учетная запись была настроена с этим зашифрованным паролем, поэтому нам не нужно будет передавать пароль в виде открытого текста, я буду единственным, кто знает пароль, и мы не начинаем с предсказуемый слабый пароль.
sudo useradd -p '$1$********' hbruijn
Я предоставляю открытый ключ SSH (конкретная пара ключей для каждого клиента) и прошу их настроить мою учетную запись с этим ключом:
sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys
настроить root (sudo) доступ
Я прошу клиента настроить для меня sudo с sudo sudoedit или с помощью своего любимого редактора и добавьте в /etc/sudoers:
hbruijn ALL=(ALL) ALL
ограничить доступ к моей учетной записи
Обычно клиент по-прежнему разрешает вход на основе пароля, и я прошу их добавить следующие две строки в /etc/ssh/sshd_config чтобы хотя бы ограничить мою учетную запись только ключами SSH:
Match user hbruijn
PasswordAuthentication no
В зависимости от клиента я маршрутизирую весь свой SSH-доступ через один бастионный хост, чтобы всегда предоставлять один статический IP-адрес (например, 192.168.1.2) и / или предоставлять диапазон IP-адресов, который использует мой интернет-провайдер (например, 10.80.1). 0,0 / 14). Клиенту может потребоваться добавить их в белый список брандмауэра, если доступ SSH ограничен (хотя чаще всего ssh не фильтруется).
Вы уже видели эти IP-адреса как from= ограничение в ~.ssh/authorized_keys файл, который ограничивает хосты, с которых мой ключ может быть использован для доступа к их системам.
предоставить контрольный журнал
До сих пор ни один клиент не просил меня об этом, и я не сделал ничего конкретного, кроме следующего, чтобы прикрыть свою задницу:
Я стараюсь постоянно использовать sudo с отдельными командами и постарайтесь предотвратить использование sudo -i или sudo su -. Я стараюсь не использовать sudo vim /path/to/file но используйте sudoedit вместо.
По умолчанию все привилегированные действия будут записываться в системный журнал (и /var/log/secure):
Sep 26 11:00:03 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml
Sep 26 11:00:34 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages
Я в основном отказываюсь от настройки моей рабочей среды, единственное, что я действительно делаю, это устанавливаю следующее в моем ~/.bash_profile увеличение истории bash и включение временных меток:
export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S '
shopt -s histappend
Единственное, что приходит в голову, это добавить --expiredate к adduser вызов.
При этом клиент знает, что ваш доступ автоматически истечет в установленную дату.
Ему по-прежнему нужно доверять вам, поскольку у вас есть root-доступ и вы все еще можете удалить флаг истечения срока действия.
Вы можете записывать свои сеансы с помощью сценарий (1) утилита.
$ script session.log
Script started, file is session.log
$ ls
file1 session.log
exit
Script done, file is session.log
затем все находится в session.log.
Поскольку вы уже входите в систему с открытым ключом SSH, это немного усложнит ситуацию, если вы не предоставите хэш пароля; вместо этого скажите им использовать adduser --disabled-password (эквивалентно, useradd -p '!', Я думаю), что фактически эквивалентно PasswordAuthentication no для этой учетной записи, плюс нет никаких шансов, что кто-то, отслеживающий вашу электронную почту, может подобрать хэш пароля и войти в систему как вы.
Зачем вообще указывать пароль, когда собираешься использовать публичные / приватные ключи.
Открытые ключи предназначены для совместного использования, поэтому это то, что вы должны использовать для безопасного обмена учетными данными, а не хешированные пароли.
sudo useradd --disabled-password hbruijn
При отправке открытого ключа проверьте отпечаток пальца по второму каналу, например по телефону, чтобы вы знали, что никто не изменил его по пути.
Поскольку теперь у вас не будет пароля для использования sudo, вам также необходимо изменить свою строку в файле sudoers на
hbruijn ALL=(ALL) NOPASSWD:ALL
Если вас не устраивает отсутствие пароля для sudo и вы действительно хотите пароль, вам все равно не нужно отправлять хешированный пароль, пусть учетная запись будет создана без пароля, установите свой открытый ключ, и как только ваша учетная запись будет настроить, вы можете войти в систему через ssh и запустить passwd чтобы установить свой собственный пароль.