ssh: Витягуємо для себе чужий порт через NAT


Що робить ssh -R © erik, unix.stackexchange.com

Підключитися до сервісу за NAT, маючи поруч з сервісом, збройного ssh, і білий ip у .

Опція -R
У ssh є режим, в якому він відкриває порт на сервері і, через тунель від сервер клієнта, перенаправляє з'єднання зазначений адреса в мережі клієнта.

Тобто нам потрібно підняти sshd, попросити людину виконати

$ ssh -N -R server_port:target:target_port sshd_server
І у нас на машині з sshd відкриється порт server_port, який буде туннелироваться в target:target_port в мережі цього людини.

Як в sshd_config обмежити права
ForceCommand echo "no shell access is given".
Якщо задати цю опцію, то вказана команда буде виконуватися замість будь переданої клієнтом (зазвичай клієнт запускає шелл).
Так як scp працює через [вбудовану] команду sftp, то копіювання файлів теж буде закрита.

Тунелювання (форвардінг) при цьому все ще працює.

AllowTcpForwarding remote
Дозволяє режими тунелювання tcp:

  • local (опція -L у ssh) — відкрити порт на клієнті і перенаправити підключення на поставлене клієнтом адресу в мережі сервера
  • remote (опція -R) — відкрити порт на сервері і тунелювати підключення на поставлене клієнтом адресу в мережі
  • all або yes — дозволяє і local, і remote
  • no — забороняє tcp тунелі
Match
Як звичайно, вищезазначені опції можна покласти у секцію, наприклад, Match User tunnel, і вони будуть дійсні тільки для з'єднань, аутентифицирующихся під ім'ям цього користувача. (ssh… tunnel@sshd_server)

Покласти в кінець sshd_config і не забути створити користувача tunnelMatch User tunnel
ForceCommand echo "no shell access is given"
AllowTcpForwarding remote
# на випадок, якщо у нас глобально встановлено інакше:
X11Forwarding no
PermitTunnel no
Ще було б добре обмежити порти, які клієнт може займати на сервері, але без патчів до sshd цього  зробити.

Зручніше і без root-а
Хочеться вирішувати завдання в дусі netcat: не чіпати системний sshd, не створювати нових користувачів і не запускати демонів.

sshd можна запустити без рута, якщо зробити окремий конфіг і відключити кілька опцій. (При цьому він не зможе брати користувачів відмінних від того, з яким він був запущений). Також потрібно вказати окремий HostKey і окремий PidFile.

Залишиться проблема аутентифікації. Так як ділитися власним системним паролем (а ми не збираємося створювати окремого користувача) з клієнтами неправильно, треба залишити тільки аутентифікацію по ключам і вказати окремий файлик з ними.

Крім цього, одержаний sshd зручно запускати без демонізації і з логом в консоль, щоб стежити, як створюються тунелі.

Готовий скрипт: запускалка користувальницького sshd, обмеженого створенням тунелів.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.