Конфигурация сервера и клиента Open SSH (некоторые уточнения)

[koluna]

Кстати, кто-нибудь может сказать, какие конкретно программы входят в пакет openssh-client, а какие в openssh-server?
У себя что-то не могу найти таких пакетов... нет их в кеше.
На оф. сайте - сырцы...

[ArcFi]

http://packages.ubuntu.com/natty/amd64/openssh-client/filelist
http://packages.ubuntu.com/natty/amd64/openssh-server/filelist

[koluna]

http://packages.ubuntu.com

Замечательная вещь, спасибо!
Пользователь решил продолжить мысль 03 Октября 2011, 22:39:49:Еще вопрос.
При неактивности со стороны клиента некоторое время сервер разрывает соединение.
Какая опция за это врямя отвечает?
ClientAliveCountMax + ClientAliveInterval?
TCPKeepAlive?

koluna@lampa:~$ Connection to lampa closed by remote host.
Connection to lampa closed.

[fisher74]

Мне кажется это клиент должен пакеты KeepAlive слать, дабы зомби не возникало

[koluna]

Мне кажется это клиент должен пакеты KeepAlive слать, дабы зомби не возникало

Как я понимаю, опцию TCPKeepAlive использовать не рекомендуют (подвержен спуффингу). Она отпадает.

Вместо нее рекомендуют связку опций ClientAliveCountMax + ClientAliveInterval.
Но они используются только на стороне сервера...
Т. е., сервер отключает клиента, если тот не активен ( ClientAliveCountMax * ClientAliveInterval ) секунд?
Тогда что понимается под термином "активность"? Если клиент не "давит на клаву", то он не активен?
Чего-то я не понимаю... ведь если связь есть, то клиент в любом случае получит сообщения сервера и должен будет ответить на них - это и будет свидетельствовать об активности или нет?

[koluna]

Оцените конфиги, пожалуйста.

ssh_config

(Нажмите, чтобы показать/скрыть)

# Конфигурация ниже - для всех хостов.
Host *

# Указывает, разрешена ли аутентификация на основе публичного ключа.
# Протоколы: SSH2
# Значение по умолчанию: “yes”
PubkeyAuthentication yes

# Указывает, разрешена ли аутентификация с использованием пароля.
# Протоколы: SSH1, SSH2
# Значение по умолчанию: “yes”
PasswordAuthentication no

# Указывает, разрешить ли аутентификацию вида вопрос-ответ (challenge-
# response authentication). Поддерживаются все виды аутентификации из
# login.conf.
# Значение по умолчанию: “yes”
ChallengeResponseAuthentication no

# Указывает, будет ли клиент доверять полученным от серверов ключам.
# Возможные значения:
# "yes" - ключи никогда автоматически не помещаются в known_hosts;
# "ask" - ключ может быть помещен в known_hosts только после подтверждения
# пользователя;
# "no" - все ключи автоматически помещаются в known_hosts (небезопасно).
# Протоколы: ?
# Значение по умолчанию: “ask”
StrictHostKeyChecking yes

# Файл с идентификационными данными RSA или DSA. Допустимо указание нескольких
# файлов с идентификационными данными в файлах конфигурации; все они будут
# пробоваться по очереди. В имени файла может присутствовать тильда для
# указания каталога пользователя, а также следующие последовательности:
# "%d" - домашний каталог локального пользователя);
# "%u" - имя локального пользователя);
# "%l" - имя локального хоста);
# "%h" - имя удалённого хоста);
# "%r" - имя удалённого пользователя).
# Протоколы: SSH1, SSH2
# Значение по умолчанию:
# ~/.ssh/identity для протокола версии 1,
# ~/.ssh/id_rsa и ~/.ssh/id_dsa для протокола версии 2.
IdentityFile ~/.ssh/id_rsa

# Используемый порт.
# Протоколы: SSH1, SSH2
# Значение по умолчанию: 22
Port 1111

# Указывает, какой протокол должен использовать sshd.
# Возможные значения:
# "1" - SSH1;
# "2" - SSH2.
# Возможна одновременная запись, при которой значения следует разделять
# запятыми.     
# Значение по умолчанию: “2,1”
Protocol 2

# Передать переменные окружения
# Протоколы: SSH2
# Значение по умолчанию: пользовательские переменные окружения не принимаются
SendEnv LANG LC_*

# Указывает, хешировать ли имена хостов в файле known_hosts.
# Протоколы: ?
# Значение по умолчанию: ?
HashKnownHosts yes

sshd_config

(Нажмите, чтобы показать/скрыть)

# Ключевые слова и аргументы чувствительны к регистру!

# Используемый порт.
# Протоколы: SSH1, SSH2
# Значение по умолчанию: 22
Port 1111

# Указывает, какой протокол должен использовать sshd.
# Возможные значения:
# "1" - SSH1,
# "2" - SSH2.
# Возможна одновременная запись, тогда значения следует разделять запятыми.     
# Значение по умолчанию: “2,1”
Protocol 2

# ?
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Указывает, должен ли sshd разделять привилегии. Если "yes", то сначала будет
# создан непривилегированный дочерний процесс для входящего сетевого трафика.
# После успешной авторизации будет создан другой процесс с привилегиями
# вошедшего пользователя. Основная цель разделения привилегий - предотвращение
# превышения прав доступа.
# Протоколы: ?
# Значение по умолчанию: "yes"
UsePrivilegeSeparation yes

# Задает код объекта журнала для записи сообщений в системный журнал от sshd.
# Возможные значения:
# DAEMON
# USER
# AUTH
# LOCAL0
# LOCAL1
# LOCAL2
# LOCAL3
# LOCAL4
# LOCAL5
# LOCAL6
# LOCAL7
# Протоколы: ?
# Значение по умолчанию: "AUTH"
SyslogFacility AUTH

# Задает уровень детальности журнала sshd.
# Возможные варианты:
# SILENT
# QUIET
# FATAL
# ERROR
# INFO
# VERBOSE
# DEBUG
# DEBUG1
# DEBUG2
# DEBUG3
# DEBUG и DEBUG1 эквивалентны друг другу. DEBUG2 и DEBUG3 задают самые высокие
# уровни отладочного вывода. Запись логов с уровнем DEBUG угрожает приватности
# пользователей и не рекомендована.
# Протоколы: ?
# Значение по умолчанию: "INFO"
LogLevel INFO

# Время, по прошествии которого сервер отключает пользователя, если тот не
# смог удовлетворительно залогиниться. Значение "0" - разрешает пользователю
# логиниться бесконечно.
# Значение по умолчанию: "120"
LoginGraceTime 60

# Указывает, возможен ли ssh-вход под суперпользователем.
# Возможные значения:
# “yes” - суперпользователь может зайти. Применяется текущая глобальная схема
# аутентификации.
# “without-password” - суперпользователь может зайти. Парольная аутентификация
# для него будет отключена.
# “forced-commands-only” - суперпользователь сможет зайти, пользуясь
# аутентификацией на основе публичного ключа и только если передаст
# необходимую к исполнению комнаду. Это удобно для осуществления резервного
# копирования, даже в том случае, когда нормальный (т. е. не через ssh) вход
# суперпользователя запрещен. Все остальные методы аутентификации для
# суперпользователя будут заблокированы.
# “no” - суперпользователь не может использовать ssh для входа в систему.
# Значение по умолчанию: "yes"
PermitRootLogin no

# Указывает должен ли sshd проверить режимы доступа и владения пользовательских
# папок и файлов перед тем, как дать пользователю войти. Обычно это объясняется
# тем, что новички часто делают свои файлы доступными для записи всем подряд.
# Значение по умолчанию: "yes"
StrictModes yes

# Указывает, разрешена ли аутентификация на основе публичного ключа.
# Протоколы: SSH2
# Значение по умолчанию: “yes”
PubkeyAuthentication yes

# Указывает файл, в котором содержатся публичные ключи, используемые для
# аутентификации пользователей. Директива может содержать маркеры вида %М,
# которые подставляются в процессе установки соединения.
# Определены следующие маркеры:
# %% - заменяется литералом '%',
# %h - заменяется домашней директорией аутентифицируещегося пользователя,
# %u - заменяется именем аутентифицируещегося пользователя.
# Таким образом, файл с ключами может быть задан как абсолютным путем
# (т. е. один общий файл с ключами), так и динамически - в зависимости от
# пользователя (т. е. по файлу на каждого пользователя).
# Значение по умолчанию: “.ssh/authorized_keys”.
# Протоколы: ?
AuthorizedKeysFile   %h/.ssh/authorized_keys

# Запрещает использование файлов .rhosts и .shosts в процессе аутентификации,
# основанной на проверке хоста (RhostsRSAAuthentication или
# HostbasedAuthentication). Файлы /etc/hosts.equiv и /etc/ssh/shosts.equiv все
# еще используются.
# Значение по умолчанию: “yes”
IgnoreRhosts yes

# Указывает, разрешена ли аутентификация, основанная на проверке хоста.
# Проверяется rhosts или /etc/hosts.equiv, и в случае успеха, совместного с
# успешной проверкой публичного ключа, доступ разрешается. Данная директива
# одинакова с директивой RhostsRSAAuthentication.     
# Протоколы: SSH2
# Значение по умолчанию: “no”
HostbasedAuthentication no

# В случае разрешенной аутентификации с помощью пароля, указывает, возможен ли
# вход с пустым паролем.
# Значение по умолчанию: “no”
PermitEmptyPasswords no

# Указывает, разрешить ли аутентификацию вида вопрос-ответ
# (challenge-response authentication). Поддерживаются все виды аутентификации
# login.conf. 
# Значение по умолчанию: “yes”
ChallengeResponseAuthentication no

# Указывает, разрешена ли аутентификация с использованием пароля.
# Протоколы: SSH1, SSH2
# Значение по умолчанию: “yes”
PasswordAuthentication no

# Указывает, должен ли sshd выводить на экран /etc/motd при интерактивном входе
# пользователя. На некоторых системах (например в Ubuntu) эта информация так же
# выводится на экран оболочкой.   
# Значение по умолчанию: “yes”
PrintMotd yes

# Указывает, должен ли sshd выводить на экран дату и время последнего сеанса при
# интерактивном входе пользователя.
# Значение по умолчанию: “yes”
PrintLastLog yes

# Указывает, какие переменные окружения, переданные клиентом, будут приняты
# (смотри опцию SendEnv в клиенте). Переменные указываются по имени, можно
# использовать маски (‘*’ и ‘?’). Можно указывать несколько переменных через
# пробел, или разбить на несколько строк AcceptEnv. Будьте осторожны - некоторые
# переменные окружения могут быть использованы для обхода запрещенных
# пользовательских окружений. Пользуйтесь этой директивой аккуратно.
# Протоколы: SSH2
# Значение по умолчанию: пользовательские переменные окружения не принимаются
AcceptEnv LANG LC_*

# Определяет и настраивает внешнюю подсистему (например демона передачи файлов
# - file transfer daemon). Аргументами служат имя и команда (с возможными
# аргументами), которая будет выполнена во время запроса на подсистемы. Команда
# "sftp-server"  запускает “sftp” - подсистему передачи файлов. Дополнительно
# можно указать в качестве подсистемы “internal-sftp” - что запустит внутренний
# sftp сервер. Это может значительно упростить настройку в случае использования
# директивы ChrootDirectory.
# Протоколы: SSH2
# Значение по умолчанию: никакие подсистемы не вызываются
Subsystem sftp /usr/lib/openssh/sftp-server

# Список пользователей, которым можно пользоваться sshd. Если указан хотя бы
# один пользователь, ssh-доступ к серверу разрешен только для него!
# Значение по умолчанию: ssh-доступ к серверу разрешен всем
AllowUsers koluna

# Задает временной интервал в секундах. Если в течении этого интервала не было
# обмена данными с клиентом, sshd посылает сообщение по зашифрованному каналу,
# запрашивающее ответ от клиента.
# Протоколы: SSH2
# Значение по умолчанию: "0" - не посылать сообщений
ClientAliveInterval 300

# Задает количество сообщений к клиентам, которые sshd посылает подряд, не
# получая какого-либо ответа от клиента. Если пороговое значение будет
# достигнуто, а клиент так и не ответил - sshd отключит клиента, прервав
# ssh-сессию. Стоит отметить, что использование таких сообщений в корне
# отличается от директивы TCPKeepAlive. Сообщения к/от клиентов посылаются по
# зашифрованному каналу и поэтому не подвержены спуффингу. Сообщения же
# TCPKeepAlive спуффингу подвержены. Механизм "client alive" особо ценен в тех
# случаях, когда серверу и клиенту нужно знать когда соединение стало неактивным.
# Протоколы: SSH2
# Значение по умолчанию: "3"
ClientAliveCountMax 0

# Указывает, какое семейство IP адресов должно быть использовано sshd.
# Возможные варианты:
# “any” - любые
# “inet” - только IPv4
# “inet6” - только IPv6
# Значение по умолчанию: “any”. 
AddressFamily inet

#
MaxStartups 2

# Количество попыток входа в систему в рамках сеанса связи. Неудачные попытки
# регистрируются в системном журнале регистрации событий. При достижении
# максимального разрешенного числа попыток сеанс обрывается.
# Значение по умолчанию: 6
MaxAuthTries 3

[koluna]

Кто-нибудь может покритиковать мои конфиги?
Буду рад конструктивной критике

[serg138]

Привет всем! Как считает стоит ли отключать простую парольную аутентификацию?Лучше все-таки ключами пользоваться?

И еще пишут что лучше в SSH отключить возможность входа под суперпользователем, а как же тогда я смогу допустим перезагружать сервер?

[Сперанский]

Возможность входа с паролем отключил (где то вычитал) пользуюсь ключами, это просто удобнее(создал ключи без пароля вообще никаких запросов не вижу). Компьютер перезагружать может и обычный пользователь, если находится в группе sudo.

[serg138]

Спасибо, попробую с ключами.
Пользователь решил продолжить мысль 27 Июля 2012, 17:46:10:Что у меня получилось. Сгенерировал ключи SSH-2 RSA. Приватный ключ себе в файл сохранил. Полдня потратил на то, чтобы в файл authorized_keys засунуть содержимое публичного ключа. Флешку так и не смог смонтировать, пришлось на диск приватный ключ нарезать. Вообщем указал в настройках сервера где брать публичный ключ. В настройках putty указал путь к моему приватному ключу и соединился. Что теперь выходит - у меня теперь просит только логин и все, пароль не просит.
Так и должно быть или что-то не то? Я думал, что меня будет пускать теперь автомато и без пароля и без логина.
Пользователь решил продолжить мысль 27 Июля 2012, 17:59:57:Недолго все проработало. Теперь приходится вводить пароль и еще выдает ошибку "server refused our key".
Пользователь решил продолжить мысль 27 Июля 2012, 19:11:36:Все на этой ошибке я и остановился. То пускало под root хоть. Решил сгенерировать ключи новые. Теперь и под рутом и так выдает ошибку "ыerver refused our key". Связь  с сервером потеряна.

[serg138]

Так и не могу по ssh с ключами зайти , пишет "server refused our key". беда.

[serg138]

Нашел параметр в файле конфигурации ListenAddress. Как я понял он позволяет указать по какой сетевой плате ждать подключений по ssh. Раскоментировал строку и дописал адрес сетевой платы сервера , смотрящей в локалку:

ListenAddress 192.168.1.1

После перезагрузки сервер ssh не может загрузиться о чем даже пишет при начальной загрузке сервера. Вернул все на свои места и все заработало. Может я что-то неверно понял?
Пользователь решил продолжить мысль 02 Августа 2012, 17:15:15:Может и не надо ssh снаружи закрывать. Удобно было из других мест подключаться, но не знаю насколько это безопасно.

[fisher74]

Может Вы что-то неверно ввели? Такой вопрос не возникал?
По поводу безопасности ssh во внешку - безпасно. Как, собственно, и любое шифровальное дело - до определённой степени.
Если гложет параноя: включите авторизацию по ключам и отключите по паролю; переведите прослушиваемый порт на нестандартный (допустим выше 1024); настройте netfilter на ограничение по кол-ву коннектов на этот порт (-m connlimit); .. на вскидку больше не прилетает идей

[Сперанский]

А можно мне на пальцах объяснить принцип защиты при авторизации по ключам, ведь там схема элементарна:
1) на клиенте создается ключ:

Код: [Выделить]

ssh-keygen -t rsa2) и ключ копируется на сервер

Код: [Выделить]

ssh-copy-id -i ~/.ssh/id_rsa user@serverЗлоумышленнику нужно только знать имя и пароль пользователя, что бы подключиться? Так? А где защита? Чем тогда отличается от авторизации по паролю?
Я правда не понимаю.

[Karl500]

После 2-го шага запрещаете авторизацию по паролю, оставляя только вариант авторизации по ключу, соответственно без ключа никто подключиться не сможет.

Т.е. имя и пароль требуется только при передаче ключа, и это логично: как иначе определить, что это именно Ваш ключ?