03
Приёмка SSH-подключения к удалённому Mac на macOS 26
Безопасная последовательность состоит не в том, чтобы сразу заменить все способы входа, а в постепенном переходе с доказуемым откатом.
Шаг 1. Зафиксируйте отпечаток хоста
При первом подключении с каждого клиента проверьте адрес, имя узла и отпечаток ключа сервера:
Не принимайте неизвестный ключ автоматически. Отпечаток должен быть получен по независимому каналу от владельца узла или оператора инфраструктуры. Повторный вход после сохранения ключа должен проходить без неожиданного предупреждения о смене хоста.
Если узел переустанавливали, старую запись удаляют только после подтверждения новой идентичности:
ssh-keygen -R <MAC_ADDRESS>
Эта команда не доказывает безопасность нового ключа — она лишь удаляет старую локальную запись. Такой порядок важен при переезде между временными Mac.
Шаг 2. Проверьте ключ с трёх типов клиентов
На macOS и Linux базовая проверка выглядит так:
ssh -i <PRIVATE_KEY> <USER>@<MAC_ADDRESS>
В Windows современный клиент OpenSSH доступен через системные средства, а общая модель его работы описана в обзоре OpenSSH для Windows от Microsoft. Команда остаётся той же:
ssh -i <PRIVATE_KEY> <USER>@<MAC_ADDRESS>
Первый вход выполняется с явным ключом, а повторный — через пользовательский файл конфигурации:
Host <MAC_ALIAS>
HostName <MAC_ADDRESS>
User <USER>
IdentityFile <PRIVATE_KEY>
IdentitiesOnly yes
Проверяем отдельно:
- macOS-клиент;
- Linux-клиент;
- Windows-клиент;
- первый вход после удаления локальной записи о хосте;
- повторный вход без явного указания
-i.
При сбое сохраняем диагностический вывод:
В нём нельзя публиковать закрытый ключ, токены и содержимое приватных переменных. Для анализа достаточно строк о выборе конфигурации, предложенных методах аутентификации и причине отказа.
Шаг 3. Проверьте права и агент
Закрытый ключ не должен быть общедоступным:
chmod 700 ~/.ssh
chmod 600 <PRIVATE_KEY>
Затем проверяем, что агент действительно содержит ожидаемый ключ:
ssh-add -l
ssh-add <PRIVATE_KEY>
На macOS взаимодействие клиента со связкой ключей имеет собственные особенности. Для ошибки ssh-add: illegal option -- apple-use-keychain полезно сверяться с разъяснением GitHub о параметре AppleUseKeychain, а не переносить конфигурацию с одной операционной системы на другую без проверки.
Только после успешного входа с резервного клиента можно обсуждать ограничение парольной авторизации. Сначала сохраняем открытый сеанс, проверяем новый ключ в отдельном окне, убеждаемся в наличии доступа оператора и только затем меняем серверную конфигурацию. Одновременное редактирование sshd_config, закрытие текущего сеанса и удаление пароля — плохая процедура восстановления.
