Краткий ответ: Вы облажались, и вам понадобится физический доступ к машине, чтобы открутить ее.
Длинный ответ: вы неправильно поняли значение и синтаксис директивы AllowUsers
.
Из справочной страницы:
AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for
user names that match one of the patterns. Only user names are
valid; a numerical user ID is not recognized. By default, login
is allowed for all users. If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts. HOST criteria
may additionally contain addresses to match in CIDR
address/masklen format. The allow/deny directives are processed
in the following order: DenyUsers, AllowUsers, DenyGroups, and
finally AllowGroups.
See PATTERNS in ssh_config(5) for more information on patterns.
Обратите внимание на второе предложение: «Если указано, вход в систему разрешен только для имен пользователей, которые соответствуют одному из шаблонов »
Когда вы добавили второго пользователя (и только второго) кому: AllowedUsers
вы заблокировали всех остальных пользователей. Включая рут. И все, что вы неправильно сконфигурировали в ssh или ошибочно набрали при изменении пароля второго пользователя, не позволяет вам войти в систему как этот пользователь.
На самом деле невозможно получить дополнительную информацию о том, почему вы не можете войти в систему; в конце концов, ssh
не может определить, являетесь ли вы враждебным субъектом, пытающимся подобрать пароль, или законным пользователем, который забыл свой настоящий пароль, и давая прежние полезные советы относительно того, как успешно войти в систему было бы что-то вроде риска для безопасности.
Если вы используете стандартный unix openSSH, вы можете попробовать использовать ssh -vvv
для подключения и посмотреть, есть ли в рукопожатии что-нибудь, что подсказывает, что вы делаете неправильно, кроме неправильного ввода учетных данных. , но учитывая, что root действительно работал, пока вы не захлопнули дверь перед собой, эта часть , вероятно, не является проблемой.
Это выглядит неправильно:
20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
Почему должен быть ICMP с общедоступного IP-адреса A мобильному клиенту, если A просто пересылает трафик B? То, что вы ожидаете, - это пакет ESP с публичным IP-адресом A, но определенно не ICMP.
Возможно, существует правило NAT для A? В таком случае обязательно используйте модуль policy , чтобы исключить трафик, соответствующий политике IPsec, из действующего правила NAT. В основном добавьте что-то вроде этого перед фактическим правилом NAT (также объясненным в strongSwan wiki ):
iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT