Мое лучшее предположение, что это эффект кэширования ssh - я ввел ключевую фразу вчера, и две машины все еще доверяют друг другу.
Это ssh-agent
или какой-то gnome-keyring
, который хранит ваш закрытый ключ в зашифрованном виде, чтобы его можно было использовать.
Какой самый простой и надежный способ промыть этот кэш для тестирования - перезагрузка?
Перечислите ключи, хранящиеся в вашем ssh-agent
, используя ssh-add -l
. Ключ должен появиться в списке. Вы можете удалить его, используя ssh-add -d /path/to/your.key
Я думаю, вы неправильно расставляете правила. В iptables -A
добавляет к цепочке, а не вставляет перед ней. Обычно у вас есть ...
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
, а затем
# Drop any tcp packet that does not start a connection with a syn flag.
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
Вместо изменения порядка вы можете переписать его с помощью -I INPUT 1
, чтобы каждое правило вставлялось перед предыдущим, т. Е. на вершине. Но в этом случае придется переместить правила хвостового ping / icmp.
Теперь вернемся к вашему вопросу:
iptables -N SSH_CHECK
iptables -N HTTP_CHECK
iptables -A INPUT -p tcp --dport 22 -j SSH_CHECK
iptables -A INPUT -p tcp --dport 80 -j HTTP_CHECK
iptables -A INPUT -p tcp --dport 443 -j HTTP_CHECK
iptables -A SSH_CHECK -s x.x.x.x -j ACCEPT -m comment --comment "allow joe to ssh from his IP"
iptables -A HTTP_CHECK -s y.y.y.y -j ACCEPT -m comment --comment "allow mary to visit my HTTP/S server"
Ваша политика отбрасывания по умолчанию заботится о несоответствующих IP-адресах.