SSH сервер

[sys_dev]

Вобщем задача простая: Настройка виртуальной гостевой системе VMware , которой поставил FreeBSD 8.2 release i386 настроить SSH-сервер. Для того чтобы заходить через Putty на основной хостовой системе, которая есть Windows 7 x64. Потому что через Putty мне удобней работать ))

Однако настройка доступа предполагает развитие навыков правильной, безопасной настройки SSH, чтобы в дальнейшем мог настроить реальный и боевой сервер!!! Так сказать сейчас в песочнице, а потом будет сложнее, поэтому нужны навыки.

Что не понимаю?
1) Что лучше DSA или RSA? Мне все таки импонирует первое, пока интуитивно понимаю, что это лучше
2) Стоит ли закрывать root? Если быдло-спец получил доступ к машине через юзера, то поднять локальные права зайдя на конкретную машину под юзером не так уж и сложно! Смысл закрывать root?
3) Если в sshd_config для опции AllowUsers задам только одного юзера, то будет ли закрыт доступ для всех других юзеров? Или нужно принудительно и явно прописывать всех юзеров в DenyUsers ?
4) Authorized_keys это опция для настройки клиента или сервера SSH ?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[hizel]

похоже вы прошли мимо
man ssh
man sshd
man sshd_config
:-(

[sys_dev]

2 hizel :
Иногда лучше жевать, чем чтото "ляпнуть". Может ты не заметил, но эта ветка для начаинающих, а не опытных!
Читай внимательно!!! Вот строчка "для начинающих", может для вида написано, так сказать фикция?

Прошу принять к сведению, что я внимательно читал мануал, иначе бы в моем посте не было бы: "sshd_config", "AllowUsers" и "DenyUsers". Вполне логично, что помере чтения и практики могут возникнуть вопросы, на которые никак не находятся ответы и вот именно для этого и нужен форум! А не для того чтобы трындеть "читай мануал"

[hizel]

вы невнимательно прочитали man sshd_config, читайте еще :-(

P.S. поражен вашей экспрессией в самое сердце, аж лапы затряслись :-)

[sys_dev]

>>вы невнимательно прочитали man sshd_config, читайте еще
Поверьте, если бы я нашел нужные мне строки, уверяю вас меня бы тут не было!!! Из вашего ответа делаю вывод, что вы и сами-то не вкурсе.
Конкретно и по делу, где конкретно те строки и абзацы?

возьму строки от сюда:

AuthorizedKeysFile
Файл с открытыми ключами которые могут быть использованы для аутентификации пользователей. Допустимо указание шаблонов, они преобразуются при настройке соединения: %% заменяется на символ '%', %h заменяется на домашний каталог идентифицируемого пользователя, %u - на имя пользователя. После преобразования AuthorizedKeysFile интерпретируется либо как абсолютный путь, либо как путь относительно домашнего каталога пользователя. Значение по умолчанию - ``.ssh/authorized_keys''

Англоязычный вариант не лучше! Эти строки ни капли не проясняют каких именно пользователй? Толи когда мы с этого сервера конектимся на другой сервак и тут надо публичный ключ? Толи тут нужен публичный ключ пользователя, который будет коннектиться сюда через Putty ? Какая именно это настройка серверная или клиентская?

смотрим другое:

AllowUsers
Список имён пользователей через пробел. Если параметр определён, регистрация в системе будет разрешена только пользователям, чьи имена соответствуют одному из шаблонов. Допустимы только имена пользователей; числовой идентификатор пользователя не распознаётся. По умолчанию разрешена регистрация в системе для всех пользователей. Если шаблон указывается в форме ПОЛЬЗОВАТЕЛЬ@ХОСТ, его две части проверяются отдельно, таким образом разрешая доступ только пользователям с указанными именами, подключающимся с указанных хостов. Разрешающие/запрещающие (allow/deny) директивы обрабатываются в следующем порядке: DenyUsers AllowUsers DenyGroups AllowGroups

если я задал в sshd_config:
AllowUsers sys_dev

то надо ли мне писать еще и :
DenyUsers root vasya_pupkin

или раз задали AllowUsers , то в DenyUsers можно не писать? Что надо то?

Что лучше RSA или DSA ? Нислова не сказано, что взяв N машин, взлом DSA займет столько-то вычислительных ресурсов, но учитывая багу или фичу... это можно ... значит лучше ... Нету аргументированного ответа, как это делает Брюс Шнайер в своих книгах!

[hizel]

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

очевидно, что аутентификация происходит на сервере

Если параметр определён, регистрация в системе будет разрешена только пользователям, чьи имена соответствуют одному из шаблонов.

у вас без шаблонов, очевидно, DenyUsers понадобится если вы к примеру открываете в AllowUsers весь @host и в Deny суете тех кого из этого домена низя vasya@host

[sys_dev]

2 hizel :
ну вот и пошел конструктив )

>>очевидно, что аутентификация происходит на сервере
Я правильно понимаю, что генерируя приватный и открытый ключ юзая ssh-keygen то:
1) в AuthorizedKeysFile я прописываю паблик,
2) а приватный ключ передаю на сторону где стоит putty.
3) Дальше юзая puttygen.exe приватный конвертирую в тот что понимает PAGEANT.EXE
4) Сконвертированный приватный предоставляю на вход PAGEANT.EXE

Если да, то это же не безопасно! Отдавать клиентской стороне приватный ключ!

[hizel]

1) очевидно, да
2) в putty вы генерируете пару закрытый\открытый :(
3) 4) без понятия как это делается в putty

не безопасно отдавать серваку свой открытый клиентский ключ :-|

[ADRE]

обилие восклицательных знаков порождает в моём продажном мозге целую череду зависимостей.
- возраст < 25 или пол Ж.
- в 1 ответе дяди был приведён полный список необходимых инструментов
- читать полезно в любое время.

[FiL]

2 hizel :
ну вот и пошел конструктив )

>>очевидно, что аутентификация происходит на сервере
Я правильно понимаю, что генерируя приватный и открытый ключ юзая ssh-keygen то:
1) в AuthorizedKeysFile я прописываю паблик,
2) а приватный ключ передаю на сторону где стоит putty.
3) Дальше юзая puttygen.exe приватный конвертирую в тот что понимает PAGEANT.EXE
4) Сконвертированный приватный предоставляю на вход PAGEANT.EXE

Если да, то это же не безопасно! Отдавать клиентской стороне приватный ключ!

С ключами обычно наоборот. Юзер генерит себе приватный и публичный ключи и потом публичный кладет в свой каталог на сервере. Это безопасно.
А что он делает со своим приватным ключом - это не серверу решать. Юзер себе и юзер. Пускай сам о своей безопасности заботится

[sys_dev]

Вобщем, поисследовав эту тему пришел к выводам:

1) Настраивать следует DSA, вместо RSA. Криптостойкость обоих алгоритмов, соглассно Брюсу Шнайеру, держутся на одной и той же проблеме из теории чисел. Однако в случае ECDSA первый будет круче. +к первому еще возможность задать меньше по битности ключ чем RSA-шный, и криптостойкость не ухудшится. Этот факт доказывает Шнайер со всеми математическими доказательствами в своей книге.

2) Использовать рекомендуется версию протокола номер 2. Но некоторые клиентские программы могут не поддерживать некоторые алгоритмы, к примеру может понадобиться поискать девелоперскую версию puttygen.exe.

3) На сервере должны хранится только публичные ключи, это связано с тем, по открытому информацию можно зашифровать, а вот расшифровать нет! Имея открытые ключи невозможно нанести какой-либо урон клиентским машинам, потому что инициатором соединения выступают исключительно клиенты(Putty к примеру).

4) Инициализация ssh-тунеля, подобна Handshake из TSL\SSL. Эта стадия на openssh.com хуже описана, но зато handshake красиво расписан в стандарте TSL\SSL и это лучшее чтения чтобы понять как это вообще происходит иниализация. Там в SSH также как и в SSL шифруется рандомная фраза, вобщем стоит почитать SSL !

ЗЫ:
Реализовать классическую атаку "чел по середке" не удалось, может у кого-то есть наработки в этом плане, буду рад!

[hizel]

и не удастся если нет пары приватный\публичный ключ

[sys_dev]

и не удастся если нет пары приватный\публичный ключ

На протяжении почти года в популярных реализациях SSL, была бага позволяющая эту атаку реализовать! Стала известна благодаря взлому Twitter, об этом можно почитать тут