Раз у раз я отримую дивний запит на надання віддаленої підтримки, усунення несправностей та / або налаштування продуктивності в системах Linux.

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

З іншого боку, маленькі компанії та приватні особи незмінно звертаються до мене, щоб проінструктувати їх, що їм потрібно зробити, щоб створити мене. Зазвичай їхні сервери підключені безпосередньо до Інтернету, і існуючі заходи безпеки складаються із стандартних параметрів, незалежно від їх розподілу Linux.

Майже завжди мені знадобиться доступ до кореневого рівня, і той, хто буде налаштовувати доступ для мене, не є експертом-систематиком. Я не хочу їх кореневого пароля, і я також впевнений, що мої дії не будуть зловмисними, але які досить прості інструкції слід дати:

• налаштувати рахунок та надійно обмінятись обліковими записами
• встановити 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 через єдиний хост бастіону, щоб завжди надавати єдину статичну 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збільшенні історії башів та включити часові позначки:

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дзвінка.
При цьому замовник знає, що ваш доступ автоматично закінчується на встановлену дату.

Він все ще повинен вам довіряти, оскільки у вас є кореневий доступ і все-таки він може видалити прапор, що закінчується.

Ви можете записувати свої сеанси за допомогою утиліти script (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щоб встановити свій власний пароль.