Предположим, у меня есть удаленная система с именем «remotesystem» и учетная запись пользователя «foouser» в этой системе.
Я знаю, что в моей локальной системе я могу сгенерировать пару ключей SSH как локальный пользователь «foouser», поместить открытый ключ в файл «/home/foouser/.ssh/authorized_keys» на «удаленной системе». Когда я использую SSH как «злоумышленник» из моей локальной системы в «удаленную систему», SSH использует пару ключей для аутентификации меня.
Но что, если мое локальное имя пользователя не совпадает с именем пользователя в удаленной системе? То есть, что, если я хочу использовать SSH как локальный пользователь «baruser» в «удаленной системе»? Очевидно, мне нужно будет создать пару ключей для «baruser» и добавить открытый ключ в «/home/foouser/.ssh/authorized_keys». Тогда я смогу «ssh foouser @ remotesystem» войти в систему как «baruser» локально, и SSH будет использовать пару ключей для аутентификации, верно?
Я спрашиваю, потому что безуспешно пытаюсь заставить аутентификацию ключа работать в этом сценарии. Я не уверен, связано ли это с несоответствием имени пользователя или проблемой конфигурации с SSH-сервером в удаленной системе.
Да, вы можете это сделать, как вы это описали.
baruser@here ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) baruser@here ~$ ssh foouser@remotesystem сообщение motd и т. д. foouser@remotesystem ~$
Это немного в сторону, но ...
Если вы всегда используете одно и то же имя пользователя для удаленного сервера, вам также может быть полезно добавить хост в вашу конфигурацию ssh:
Host remotesystem
User baruser
Таким образом, вам не нужно помнить об указании имени пользователя при входе в систему, и вы исключаете это при возникновении проблем с ключами в будущем.
Ваше локальное имя пользователя на самом деле не имеет значения (кроме того, что закрытый ключ должен находиться в домашнем каталоге вашего локального пользователя). Просто скопируйте ключ удаленному пользователю authorized_keys раздел и он будет работать.
При любых проблемах, связанных с ssh, первое, что нужно сделать, это повысить уровень детализации клиента:
ssh user@machine -vvv
Если это не поможет вам понять, что не так, вам необходимо изменить уровень журнала на сервере и перезапустить демон.
LogLevel DEBUG3
Вы должны найти вывод отладки в /var/log/auth.log (или там, где когда-либо настроен ssh для входа). Как только вы нашли проблему, не забудьте вернуть ее к тому, как вы ее нашли.
Разрешения на каталоги .ssh на обеих машинах очень правильные. Обычно это означает 700 в каталоге .ssh и максимум 755 в домашнем каталоге. В дополнение к 600 для всех файлов в каталогах .ssh.
Если пользователь удаленной системы является пользователем root, убедитесь, что root может использовать ssh. (PermitRootLogin в sshd_config) и этот открытый ключ (PubkeyAuthentication) и, если необходимо, RSA (RSAAuthentication) включены.
Если у вас включен SE Linux, вам также нужно будет сделать следующее.
Добавьте метку SELinux в authorized_keys чтобы к нему мог получить доступ sshd.
semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh
Похоже, вы все делаете правильно, но убедитесь, что права на authorized_keys верны. Их следует установить на 600.