Вопрос: Linux: настройка для удаленного sysadmin


Время от времени я получаю нечетный запрос на предоставление удаленной поддержки, устранение неполадок и / или настройку производительности в системах Linux.

Более крупные компании часто уже имеют хорошо установленные процедуры для обеспечения удаленного доступа к поставщикам / поставщикам, и мне нужно только их соблюдать. (Лучше или хуже.)

С другой стороны, небольшие компании и люди неизменно обращаются ко мне, чтобы дать им указание, что им нужно сделать, чтобы настроить меня. Обычно их серверы напрямую подключены к Интернету, а существующие меры безопасности состоят из значений по умолчанию для любого их дистрибутива Linux.

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

  • настроить учетную запись и безопасно обменять учетные данные
  • настроить доступ root (sudo)
  • ограничить доступ к моей учетной записи
  • предоставлять контрольный журнал

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

Что можно улучшить на следующих шагах?


Мой текущий набор инструкций:

настроить учетную запись и безопасно обменять учетные данные

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

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-доступ через один хост bastion, чтобы всегда предоставлять один статический IP-адрес (например, 192.168.1.2) и / или предоставлять диапазон IP-адресов, используемый моим интернет-провайдером (например, 10.80. 0.0 / 14). Клиенту может потребоваться добавить его в белый список брандмауэра, если доступ к SSH ограничен (чаще всего ssh не фильтруется).

Вы уже видели эти ip-адреса как from= ограничение в ~.ssh/authorized_keys файл, который ограничивает хосты, из которых мой ключ может использоваться для доступа к их системам.

предоставлять контрольный журнал

До сих пор ни один клиент не спросил меня об этом, и я не сделал ничего конкретного, кроме следующего, чтобы покрыть мою задницу:

Я стараюсь последовательно использовать sudo с отдельными командами и попытаться предотвратить использование sudo -i или sudo su -, Я стараюсь не использовать sudo vim /path/to/file  но использовать sudoedit вместо.

По умолчанию все привилегированные действия будут регистрироваться в syslog (и /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

49
2017-09-26 11:54


Источник


Вы можете регистрировать (легко изменить после факта) и даже обмениваться сеансами в screen, поэтому в крайнем случае ваш клиент может смотреть вживую, что вы делаете. - Sven♦
Если вы хотите добавить лучший контрольный журнал, вы должны проинструктировать их о включении удаленного ведения журнала, если у них есть возможность - Fredi


Ответы:


Единственное, что приходит на ум, это добавить --expiredate к adduser вызов.
При этом клиент знает, что ваш доступ автоматически истечет с фиксированной датой.

Ему все еще нужно доверять вам, поскольку у вас есть доступ к корню и все еще можно удалить флаг expire.


23
2017-09-26 12:34





Вы можете записывать свои сеансы с помощью скрипт (1) утилита.

$ script session.log
Script started, file is session.log
$ ls
file1  session.log
exit
Script done, file is session.log

тогда все находится в session.log.


14
2017-09-26 16:29



Вы порекомендовали бы запустить это на своем собственном хосте, прежде чем запускать сеанс ssh в удаленной системе или включить его как часть моего профиля в удаленной системе? - HBruijn♦
Думаю, вы могли бы это сделать - я использовал его только тогда, когда в основном людям все равно. - Iain


Поскольку вы уже входите в систему с открытым ключом SSH, это немного затянет все, если вы не предоставите хэш пароля; вместо этого попросите их использовать adduser --disabled-password (То же самое, useradd -p '!', Я думаю), что фактически эквивалентно PasswordAuthentication no для этой учетной записи, плюс нет никаких шансов, что кто-то, следящий за вашей электронной почтой, может грубо заставить хеш-пароль и войти в систему, как вы.


7
2017-09-26 15:51



Добавление Match user hbruijn \n PasswordAuthentication no to sshd_config должен запрещать кому-либо удаленно регистрироваться с моим дешифрованным паролем (потенциально локальные пользователи могли бы использовать его с su - hbruijn), но насколько я знаю, мне все еще нужно иметь действующий пароль для sudo цели. Может быть, мне нужно просто сбросить пароль после входа? - HBruijn♦
О, хорошая точка в судо. Я не уверен, была ли учетная запись в --disabled-password состоянию может быть задан пароль, запустив passwd с этой учетной записи. - zwol
Также, что останавливает любого, кто слушает на хеше пароля, который вы предоставляете? Эта часть является слабым звеном, которое подрывает использование ключей ssh, где не имеет значения, если ваш открытый ключ перехвачен. - JamesRyan
Может ли эта слабая связь быть разрешена, если клиент также добавит строку в файл sudoers, например hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn? - Dezza


Зачем вводить пароль вообще, когда вы собираетесь использовать общедоступные / закрытые ключи.

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

sudo useradd --disabled-password hbruijn

При отправке открытого ключа проверьте отпечаток пальца по второму каналу, например, по телефону, так что вы знаете, что никто не изменил его на своем пути.

Поскольку теперь у вас не будет пароля для использования sudo, вам также необходимо изменить свою строку в файле sudoers, чтобы

hbruijn ALL=(ALL) NOPASSWD:ALL

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


2
2017-09-30 09:12