Можно ли запретить вход пользователей с клиентом, отличным от openssh (против ботов и случайного захода с винды)?

А, может, придумать систему паролей (если даже возможно - отправка смской). Вы зашли с прокаженной винды на сервер через openssh, и сразу выполнился скрипт смены пароля пользователю, и новый пароль - либо вы его знаете по своей системе, либо, если рандом, отправляется вам смской. Одноразовые пароли, и не страшно заходить «откуда попало».

Извините, если оффтоп и я не угадал ход мыслей.

iptables -A INPUT -m string --dport 22 --string 'ну ты понял' -j DROP

Это же не телнет.

knockd и sshd созданы друг для друга.

Ход мыслей не поняли. Для этого есть RSA-токены, их программные реализации на мобильные (mobileotp), смарткарты, кнокинг и двухфакторная аутиентификация.

лучше прикрутить s/key

случайного захода с винды

если заходишь ты - это не случайно

По теме - по-моему проще реально таки ввести авторизацию по ключу.

/usr/sbin/sshd -ddd -p7777

ни единого намёка на user-agent name

scottlinux.com/2012/03/07/troubleshooting-ssh-server-logs-and-error-messages/

Debug level example. Вторая строчка сверху.

Снифер:
[from:10.101.1.39] $ ssh 10.101.58.111

T 10.101.58.111:22 -> 10.101.1.39:36272 [AP]
  SSH-2.0-OpenSSH_4.3.                                                       
##
T 10.101.1.39:36272 -> 10.101.58.111:22 [AP]
  SSH-2.0-OpenSSH_6.0p1 Debian-4..              

хм, действительно.

debug1: Client protocol version 2.0; client software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*

sshd.c

if (sscanf(client_version_string, "SSH-%d.%d-%[^\n]\n",
            &remote_major, &remote_minor, remote_version) != 3) {
                s = "Protocol mismatch.\n";
                (void) atomicio(write, sock_out, s, strlen(s));
                close(sock_in);
                close(sock_out);
                log("Bad protocol version identification '%.100s' from %s",
                    client_version_string, get_remote_ipaddr());
                fatal_cleanup();
        }
        debug("Client protocol version %d.%d; client software version %.100s",
              remote_major, remote_minor, remote_version);

вот пример дебага при коннекте через PuTTY

debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60

Отлично. Значит можно с PAM не извращаться для блокировки putty. А как можно средствами iptables разорвать соединение, если за определенное время (2 секунды для запаса, скажем) по каналу НЕ прошел указанный паттерн?

На данный момент вижу реализацию через xinetd (стандартный порт)->парсер->socat->sshd (нестандартный порт на 127.0.0.1). На уров
е парсера смотрим, есть ли в первых N (вообще она должна быть определнной по счету, но будет считать, что страндарт может вольно трактоваться, что может вызвать проблемы) строк «SSH-2.0-OpenSSH_», пропуская строки через read+grep и echo или через просто через (но я не знаю, как закрывать греп после каждого символа перевода каретки) grep (как вообще тут лучше реализовать то?). Далее смотрим, если греп ничего не вывалил за эти N строк, то делаем exit, иначе делаем перенаправление на ocat.

Меня только не очень радует, что это все на баше будет, и хз как оно будет по производительности.

Что ты думаешь по поводу моего сообщения анону?

Важный момент: хотя putty через iptables string и легко блочить, но мне хотелось не запретить putty (разрешив все остальное), а разрешить OpenSSH_ , запретив остальное.

iptables .... ! --string OpenSSH_ ... -j REJECT

Ага, только iptables анализирует стринги per панет, а не per коннект. В резутате тут даже до коннета не дойдет. Либо тут нужен какой-то хитрый модуль, которому можно будет из этого правила передать управление, который подсчитает количество количество своих вызовов, и, в случае количества вызовов более N сделает reject. Но тут есть один нюсанс: это будет работать только в случае с одним соединением (если два или более параллельно будут подключаться, то n переполнится раньше ввода стринга, т.к.
она глобальная. Либо модуль-счетчик должен уметь считать per ip внутри своей собственной логики. Я что-то читал про подобный модуль, надо будет погуглить.

Что ты думаешь... Ага, только iptables анализирует стринги per панет, а не per коннект...

именно это и думаю.