Неправильно ли настроена эта конфигурация SSH и представляет ли она угрозу безопасности?
В файле конфигурации для локального сетевого интерфейса (файл, соответствующий шаблону имени /etc/systemd/network/*.network), мы должны либо указать, что хотим получить адрес локального DNS-сервера от DHCP-сервера, используя параметрDHCP=:
[Network]
DHCP=yes
или указать его адрес явно с помощью опцииDNS=:
[Network]
DNS=10.0.0.1
Дополнительно нужно указать (в том же разделе )локальные домены с помощью опцииDomains=
Domains=domainA.example domainB.example ~example
Мы указываем локальные домены domainA.example domainB.example, чтобы получить следующее поведение (от systemd -разрешил.service, systemd -разрешил справочную страницу):
Lookups for a hostname ending in one of the per-interface domains are exclusively routed to the matching interfaces.
Таким образом, hostX.domainA.exampleбудет разрешаться исключительно нашим локальным DNS-сервером.
Мы указываем с помощью ~example, что все домены, оканчивающиеся на example, должны рассматриваться как домены только маршрута -, чтобы получить следующее поведение (из описания этой фиксации):
DNS servers which have route-only domains should only be used for the specified domains.
Таким образом, hostY.on.the.internetбудет разрешаться исключительно нашим глобальным удаленным DNS-сервером.
Примечание
В идеале при использовании протокола DHCP локальные доменные имена должны быть получены от DHCP-сервера, а не указаны явно в файле конфигурации сетевого интерфейса выше. См. UseDomains=, опция . Однако с этой функцией все еще остаются нерешенные проблемы — см. проблему systemd -networked DHCP search domains .
Нам нужно указать удаленный DNS-сервер в качестве нашего глобального системного -DNS-сервера. Мы можем сделать это в файле /etc/systemd/resolved.conf:
.
[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
Не забудьте перезагрузить конфигурацию и перезапустить службы:
$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-networkd
$ sudo systemctl restart systemd-resolved
Внимание!
Приведенные выше гарантии применяются только в том случае, если имена разрешаются с помощью systemd -resolve — см. справочную страницу для nss -resolve, libnss _resolve.so.2и man-страницы для systemd -разрешил.service, systemd -разрешил .
См. также:
- Описание запросов поиска маршрутизации на справочных страницах, связанных с systemd, неясно
- Как устранить неполадки DNS с помощью systemd -?
Ссылки:
SSH не отправляет ваши личные ключи на сервер. Механизм основан на вычислении с использованием того, чем обладает объект -сервер вычисляет что-то на основе открытого ключа, клиент на основе закрытого ключа (см. этот пост Information Security Stack Exchange для получения дополнительной информации ).
В любом случае, независимо от того, добавляете вы ключи к агенту или нет, SSH пробует все ключи, пока один из них не будет успешным. Если у вас не настроена переадресация агента, я не думаю, что что-либо на сервере может использовать ключи, добавленные к агенту.
Host *
HostName github.com
AddKeysToAgent yes
Это устанавливает Hostnameкаждого Hostна github.com, что, безусловно, не то, что вы хотите делать (это означает, что ssh foo.barбудет подключаться кgithub.com). Если вы хотите применить некоторую конфигурацию только к подключениям к github.com, используйте это как шаблон Host:
Host github.com
IdentityFile ~/.ssh/my-secret-key.pem
Является ли это угрозой безопасности, зависит от того, от кого вы защищаете. Если ваши SSH-ключи защищены паролем -, и кто-то еще может получить доступ к SSH-агенту в вашей системе, конечно, это открывает доступ ко всем защищенным паролем -ключам после их добавления в агент.
Но я бы сказал, что эта угроза маловероятна.