Из-за чего может с одной машины не пускать на другую по ssh при одинаковых файлах group и sshd_config?

iptables? Что значит «не пускать»?

iptables?

iptables не работает.

Что значит «не пускать»?

Не принимает пароль, как-будто он некорректный.

kep

Тебе помогать не буду

«ssh -v» с тех машин на которых не работает. Скорей всего проблемы либо с правами на ключи, либо с пробелами.

у каждого пользователя есть в ~/.ssh — id_rsa и id_rsa.pub, если что.

Ты делаешь, что-то некорректно. Приватный ключ используется для доступа, публичный заносится в authorized_keys. При этом часть с именем хоста, может быть опущена. Для доступа с двух сторон, тебе нужно «2 пары» ключей соотвественно. С хорошими правилами по настройке openssh можеть ознакомиться здесь.

Спасибо за ссылку, пару ключей и права на них генерирует:

ssh-keygen -t rsa -b 4096

С паролями проблема только с PAM бывает если все верно настроено, но такое может случится только с LFS каким-нибудь. И то openssh достаточно лоялен в этом плане. Я уже где это возможно на ed25519 перешел. Хотя бы потому-что rsa ключи, генерируются не очень спешно.

Сколько уж твердили, что по "ssh -v" ничего толкового увидеть нельзя и все-равно находится "умник" советующий бесполезную хрень.

Это первое средство диагностики, которые покажет большинство проблем с подключением и базовые проблемы с настройкой, и позволит узнать, что openssh от тебя ожидает. А вот в auth.log или syslog скорей уже покажет проблемы как раз не связанные с openssh, а проблемы с авторизацией как таковые. Так что, «ssh-v» это действительно первое средство диагностики для большинства проблем.

Это первое средство диагностики, которые покажет большинство проблем с подключением и базовые проблемы с настройкой,

Что ты мелешь?! Покажи мне хотя бы две (одну за последние 16 лет я таки увидел) успешные диагностики при помощи ssh -vvv

Окей. Типичная задача. Пользователю vps дали пароль и IP-aдрес для доступа к vps. И у него не получается соединиться с vps, при этом IP-aдрес vps он спокойно пингует. Какие данные гуру тру-anonymous возьмет у него чтобы понять в чем состоит проблема?
Естественно подключиться по предоставленным данным действительно можно.

Шлангуешь

99.9% проблем на стороне сервера — ssh -v не может принципиально ничего путного сказать

Проверь наличие /etc/nologin возможно он блокирует вход.

/etc/nologin отсутствует на обеих машинах.

ssh -v

Password: 
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
user@192.168.0.104's password: 
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
user@192.168.0.104's password: 
Received disconnect from 192.168.0.104 port 22:2: Too many authentication failures
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.104 ([192.168.0.104]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.0.104 closed by remote host.
Connection to 192.168.0.104 closed.
Transferred: sent 2744, received 1752 bytes, in 0.0 seconds
Bytes per second: sent 6891718.7, received 4400251.9
debug1: Exit status -1

Не говорит чего не коннектит. PAM отключал, история та же.

На хосте А в /etc/ssh/sshd_config проверить опцию AllowUsers на предмет наличия там юзера.

Так тебя выкидывает уже после успешного логина, может что-то в .bashrc стопорит.

На хосте А в /etc/ssh/sshd_config

Конфиги идентичные на обеих машинах, ни AllowGroups, ни AllowUsers нет: https://bpaste.net/show/7a9fd21f4419

.bashrc и .bash_profile идентичные, вообще это какой-то баг, что оно говорит, что есть успешный логин, какой же он успешный, если до того 5 раз переспрашивало пароль.

Ты на хосте A вообще можешь под пользователем залогиниться (от рута su user)?

Попробуй жестко указать AuthenticationMethods, либо сделать исключения для пользователя в конфиг файле клиента, чтобы он не использовал publickey, либо укажи как опцию во время подключения через -o как PreferredAuthentications метод. Либо сделай отдельную секцию для пользователя в самом sshd_config c AuthenticationMethods через Match User.
Мое подозрение в том, что publickey стоит приоритетнее чем password или keyboard-interactive, и в твоем случае это вызывает проблемы. Причем я бы оставил через keyboard-interactive, а не password.

Ты на хосте A вообще можешь под пользователем залогиниться (от рута su user)?

Да.

На сервере запустить sshd с дебагом и сразу все увидишь. Ты, клоун, так и будешь дальше пальцем тыкать?

Received disconnect from 192.168.0.104 port 22:2: Too many authentication failures
debug1: Authentication succeeded (password).

Так тебя выкидывает уже после успешного логина, может что-то в .bashrc стопорит.

Уверен, да?

При запрещенном входе по паролю (только ключи) он об этом сообщает. Инфа 146% в этом году подсоединялся к чужому серваку, так и узнал в чем дело.

Я конечно попробую это всё, но мне интересно, почему вторая машина с такими же настройками, версиями openssh и всего другого, поднятая с того же стейджа — не требует этого всего.

При запуске sshd -d -v:

Apr  6 08:40:45 T420 sshd[8533]: Server listening on 0.0.0.0 port 22.
Apr  6 08:40:45 T420 sshd[8533]: Server listening on :: port 22.
Apr  6 08:40:50 T420 sshd[8577]: User kep not allowed because account is locked
Apr  6 08:40:50 T420 sshd[8577]: input_userauth_request: invalid user kep [preauth]
Apr  6 08:40:53 T420 sshd[8577]: error: Could not get shadow information for NOUSER
Apr  6 08:40:53 T420 sshd[8577]: Failed password for invalid user kep from 192.168.0.100 port 56844 ssh2

Это проблема описана здесь.

Помогло:

~# usermod -U kep
~# passwd kep

Теперь пускает. Странно, ведь аккаунты создавались одинаковыми командами с одинаковыми паролями.

При запуске sshd -d -v:

Сразу все стало понятно. Что и требовалось доказать! Слушайтесь старших.

Так у тебя юзер был заблокирован.

А какого дьявола он был заблокирован?

Сразу все стало понятно. Что и требовалось доказать! Слушайтесь старших.

Да, спасибо приятель.

Второй параметр в shadow не должен быть ! (символ восклицательный знак) т.е. просто руками могли бы поправить и без команд.

А в каких случаях он становится "!" (заблокированным)?

Тут я за все системы не скажу. Но что-то типа useradd username должно такое делать точно.