Каталогу нужны разрешения на выполнение, чтобы перейти в него или получить листинг, поэтому, когда каталог создается, он автоматически устанавливает биты +x.
Файлам, однако, требуется только установить бит выполнения (s ), если они являются скомпилированными двоичными файлами (c/c++/etc )или интерпретируемым -скриптом (sh/bash/ php/perl/etc ), а также не делать вещи исполняемыми по умолчанию из соображений безопасности.
Строка sshd: username@ipaddress
в /etc/hosts.allow
применяла бы ограничение к службе sshd
(и только в том случае, если она была скомпилирована с поддержкой libwrap
или настроена на использование оболочек TCP ). Это вообще ничего не делает для proftpd
.
Если для подключения вы используете режим scp
или SFTP
WinSCP, вы фактически используете службу sshd
, и proftpd
вообще не будет задействован. Если вы используете режим FTP
или FTPS
, то proftpd
может справиться с ними, а sshd
вообще не будет задействован.
(Запуск ненужной службы с плохо -понятной конфигурацией на сервере, -доступном в Интернете, напрашивается на заражение вредоносным ПО. Ради себя и других пользователей EC2, пожалуйста, не делайте этого.)
Использование формы sshd: username@ipaddress
в /etc/hosts.allow
требует, чтобы на клиенте была запущена identd
или аналогичная служба. identd
— это служба, которая раскрывает локальное имя пользователя, связанное с активным TCP-соединением, всем, кто спрашивает. В наше время это считается опасным и ненужным раскрытием информации, поэтому служба identd
больше не включена и обычно даже не устанавливается по умолчанию в современных системах.
А если клиент не является Unix-подобной системой -, поддерживаемой кем-то, кому вы доверяете, удаленная служба identd
может быть настроена на ложь, даже если она существует и не блокируется брандмауэрами. Подводя итог, добавление имен пользователей в /etc/hosts.allow
вряд ли будет полезным в современной сетевой среде.
Сначала вам нужно будет принимать входящие подключения от каждого авторизованного клиентского хоста, а затем, когда они раскрывают имя пользователя, к которому они хотят подключиться, как (в рамках процедуры аутентификации ), вы можете отклонить не -соответствующие комбинации.
С помощью sshd
вы можете сделать это, добавив что-то вроде этого в ваш файл /etc/ssh/sshd_config
:
AllowUsers user1@ip.address.1 user2@ip.address.2...
Обратите внимание, что это также ограничит обычные подключения SSH, поэтому убедитесь, что вы не заблокировали себя.