Создание пользователя полностью без прав для SSH proxy через putty

вместо шелла /bin/false

в .ssh/authorized_keys можно прописать доп. ограничения типа no-pty no-X11-forwarding и ограничить доступ с конкретного ip

нельзя писать в место шелла /bin/false, после авторизации сразу выкидывает и сессия закрывается. так уже пробовала, не получается.

ограничения по IP делать нельзя, у нас динамические IP.

Так это же для этого и надо. Только тоннель должен работать.

по ограничениям authorized_keys написано в справке sshd.

Если указать шелл: /bin/false то соединение СРАЗУ после авторизации закрывается, тоннель тоже закрывается, putty закрывается, всё закрывается. Соединение должно висеть и не закрывать. Тут нужно что-то другое... как вариант указать в качестве sella файл: /home/anastasia/bash

а содержимое этого файла:

#!/bin/bash

echo connect OK!

/bin/sleep infinity

но мне не нравиться это решение, как то это через одно место :-(

о соединение СРАЗУ после авторизации закрывается

В настройках клиента надо указать что бы шелл не запускал.

У консольного это -N Do not execute a remote command. This is useful for just forwarding ports.

у Putty: Connection => SSH => Dont start shell or command at all

Анонимус дурной - не слушай. Шелл /bin/false - по факту запрет входа в систему, например, такие аккаунты используются для запуска демонов.

1) Всех юзеров можно лепить как nobody/nogroup - этого более чем достаточно в 99,99% случаев и вполне секурно.

2) Если хочется прям совсем изолировать, то всех юзеров в чрут. Команды запускать нельзя (если их не подсовывать в каждую хомдир), про сам сшелл не очень помню поведение, но для туннелей самое оно.

Кусок конфига OpenSSH сервера:

Match Group nogroup
    ChrootDirectory %h
    X11Forwarding no

-N Do not execute a remote command. This is useful for just forwarding ports.

Проблема интерпретации того что написано. Что бы это все сделать на машине нужен рабочий сшелл. `-N` просто дает возможность запустить SSH-клиент в не интерактивном режиме.

У меня так:

Match User proxy
    ForceCommand read a; exit

Кстати, уже была такая тема, советую посмотреть тред: ssh tunnel (авторизация без шелл)

Подведя итог получаем: - при создании пользователя уменьшаем ему права указав другую группу за место «user» указываем «nogroup», также указываем другой shell за место «/bin/bash» указываем «/bin/false», полная команда:

# useradd -m -s /bin/false -g nogroup -G nogroup anastasia

в файле /home/anastasia/.ssh/authorized_keys дописываем строки, чтобы запретить все что только можно: no-X11-forwarding,no-user-rc,no-agent-forwarding,no-pty

должно быть как-то так (это все в одну строку, ключ вырезан):

no-X11-forwarding,no-user-rc,no-agent-forwarding,no-pty ssh-rsa AAAA...aQ== anastasia@FiveVPS

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

вот команды для firewall, в примере порт для SSH 54787-й:

iptables -I INPUT 1 -p icmp --icmp-type echo-reply -j ACCEPT 
iptables -A INPUT   -p icmp -j DROP
iptables -A INPUT   -p TCP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT   -p UDP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p TCP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p UDP -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  
iptables -A INPUT -i lo -j ACCEPT


# --------------------------------------------------------------------------------------
# Блокирование bruteforce-атак (подбор пароля вслепую) на SSH и аналогичные сервисы:
# Создаем цепочку для проверки попыток соединений на защищаемый порт:
iptables -N ssh_brute_check
# Если за последние 20 минут (1200 секунд) с одного адреса было 3 или более новых соединений — блокируем этот адрес:
iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 3600 --hitcount 3 -j DROP
# В противном случае — разрешаем, и при этом заносим в список
iptables -A ssh_brute_check -m recent --set -j ACCEPT
# Все попытки открыть новое соединение по SSH направляем на проверку
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 54787 -j ssh_brute_check
# ---------------------------------------------------------------------------------------

# политика по умолчанию все запретить:
iptables -P INPUT DROP
iptables -P FORWARD DROP 
ip6tables -A INPUT -j DROP
ip6tables -A FORWARD -j DROP

# Сохраняем правила файрвола:
iptables-save > /etc/iptables.rules 
ip6tables-save > /etc/ip6tables.rules

При подключении через putty используя ключи дополнительно ставим галочку Connection => SSH => Dont start shell or command at all.

а при подключении через ssh в linux, команда выглядит так:

ssh -i ~/.ssh/FiveVPS_priv_SSH_key_file -D 127.0.0.1:8034 -N -l anastasia -p 54787 10.20.30.40

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

Посмотрите на настройки, я ничего не упустила, может что-то забыла или сделала не так?

https://shadowsocks.org/en/index.html
лучше это использовать
или полноценныйй впн

указываем другой shell за место «/bin/bash» указываем «/bin/false»

отключаем учетную запись root

Т. е. отключаем возможность войти в shell от имени пользователя и потом применить команду sudo (которую тоже надо настроить, если это не ubuntu desktop, где sudo настроена по умолчанию) и одновременно отключаем возможность логина для root'а?

А если что починить или перенастроить надо будет, как входить?

Я бы запись рута не отключал и не прописывал для неё никаких /bin/false и иже с ними, а просто защитил бы надёжным паролем и не давал этот пароль тем, кому оно не нужно.

разрешаем подключаться к SSH только используя ключи.

А если в результате какого-то сбоя ключ потеряется? Я бы оставил возможность входа и по паролю, и по ключу. Только пароли надёжные надо делать (более 12 символов и не состоящие из одного слова, пусть даже редкого).

за место «/bin/bash» указываем «/bin/false»

И, как здесь говорили, /bin/false может просто выкинуть. Я бы воспользовался советами по ссылке ssh tunnel (авторизация без шелл) , там абсолютно такая же проблема успешно решена. А лучшее - враг хорошего. Хотя можно попробовать и /bin/false, а потом в случае чего перенастроить. Только рута и шелл для него ни в коем случае отключать не надо!

Возможно не правильно выразилась, root пользователь есть, но ему отключаем доступ к SSH т.е. ему нельзя залогинеться через SSH. А если нужно настроить что-то на сервере то подключение будет через другого пользователя который не предназначен для работы с туннелем. это отдельный пользователь имеет права root (id=0) но у него другое имя: adminvps. И разумеется для этого пользователя shell нормальный: /bin/bash

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

по поводу shella в другой ветке использовали за место «/bin/false» другой «/usr/sbin/nologin» есть ли принципиальная разница в том что указать? при условии что в настройка при подключении указывается «Don't start shell» шел не используется и пользователей не выкидывает, в кажется все нормально.

также в файл sshd_config прописывали настройки сразу а я их прописываю в /home/anastasia/.ssh/authorized_keys, думаю разницы нет или есть?

«/bin/false» другой «/usr/sbin/nologin» есть ли принципиальная разница

Это одно и то же. Только false есть везде (на любых системах), а путь к nologin может различаться.

Ты ведь так и не указала,на какой системе работаешь. Поэтому универсальный вариант и подсказал.

это отдельный пользователь имеет права root (id=0) но у него другое имя

Тогда всё Ok. Тем более, что

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

в другой ветке использовали за место «/bin/false» другой «/usr/sbin/nologin» есть ли принципиальная разница в том что указать?

Да, сейчас посмотрел внимательнее. Разницы нет. Разве что nologin вежливо посылает, говоря «This account is currently not available», а false делает то же самое молча. :-)

также в файл sshd_config прописывали настройки сразу а я их прописываю в /home/anastasia/.ssh/authorized_keys, думаю разницы нет или есть?

Мне кажется, что authorized_keys предназначен исключительно для хранения ключей, в то время как /etc/ssh/sshd_config - для общих настроек. И, кстати, в этом же sshd_config нужно прописать ещё и настройки для ключей. См., например, https://www.opennet.ru/base/sec/ssh_pubkey_auth.txt.html :

# Should we allow Identity (SSH version 1) authentication?
RSAAuthentication yes
  
# Should we allow Pubkey (SSH version 2) authentication?
PubkeyAuthentication yes
 
# Where do we look for authorized public keys?
# If it doesn't start with a slash, then it is
# relative to the user's home directory
AuthorizedKeysFile    .ssh/authorized_keys

Всем спасибо за подсказки, кажется все настроено полностью, и на вид все работает как запланировано. Через putty ничего нельзя ввести и нельзя смотреть содержимое файлов на VPS.

в файле /etc/ssh/sshd_config все настройки прописаны, только есть маленькие отличия, у меня вот так записана последняя строка (добавлено «%h»):

AuthorizedKeysFile    %h/.ssh/authorized_keys

Теперь блокировка сайтов провайдером обходится без проблем :-)

Теперь блокировка сайтов провайдером обходится без проблем :-)

Радоваться пока рано. Уже принят в первом чтении закон о возможности блокировать tor и vpn. Так что, думаю, до 3-его чтения и до его реального применения времени осталось не так много. Конечно, всё это тоже будет обходиться, но, возможно, придётся дополнительно повозиться. Впрочем, поживём - увидим. А пока я бы советовал не расслабляться и держать руку на пульсе событий и изучить самые свежие способы блокировок и их обхода.

На VPS в

 /etc/passwd

/bin/false

/bin/bash

plink.exe

plink.exe login@ip.ip.ip.ip -N -C -v -D 127.0.0.1:8081 -pw passwd

127.0.0.1:8081