По умолчанию ssh ищет id_dsa
и id_rsa
файлы. Ключи не обязательно должны быть названы так, вы можете назвать их mykey
так же, или даже поместить их в другой каталог. Однако, если вы сделаете любой из них, вам нужно явно указать ключ в команде ssh следующим образом:
ssh user@server -i /path/to/mykey
Если команда не принимает -i
, например sshfs
, используйте IdentityFile
параметр:
sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint
Как это устроено
При создании ключа вы получите два файла: id_rsa
(закрытый ключ) и id_rsa.pub
(открытый ключ). Как следует из их имен, закрытый ключ должен храниться в секрете, а открытый ключ может быть опубликован для общественности.
Аутентификация с открытым ключом работает с открытым и закрытым ключом. И клиент, и сервер имеют свои собственные ключи. При установке openssh-server
на сервере открытый и закрытый ключи генерируются автоматически. Для клиента вы должны будете сделать это самостоятельно.
Когда вы (клиент) соединяетесь с сервером, обмениваются открытыми ключами. Вы получите один сервер, а сервер ваш. При первом получении открытого ключа сервера вам будет предложено принять его. Если этот открытый ключ со временем изменится, вы будете предупреждены, потому что происходит возможная атака MITM (Человек посередине), перехватывающая трафик между клиентом и сервером.
Сервер проверяет, разрешено ли вам подключаться (определено в /etc/ssh/sshd_config
), и указан ли ваш открытый ключ в ~/.ssh/authorized_keys
файле. Возможные причины отказа в открытом ключе:
/etc/ssh/sshd_config
:
AllowUsers
или AllowGroups
указан, но пользователь вашего сервера не указан в списке групп или пользователей (по умолчанию не определено, не накладывая никаких ограничений на пользователей или группы при входе в систему).
DenyUsers
или DenyGroups
указан, и вы в списке пользователей или групп.
- Вы пытаетесь войти в систему как root, но
PermitRootLogin
установлено No
(по умолчанию yes
).
PubkeyAuthentication
установлено на No
(по умолчанию yes
).
AuthorizedKeysFile
установлен в другое место, и открытые ключи не добавляются в этот файл (по умолчанию .ssh/authorized_keys
, относительно home dir)
~/.ssh/authorized_keys
: ваш открытый ключ не добавлен в этот файл (обратите внимание, что этот файл читается как пользователь root)
Использование нескольких клавиш
Нередко используют несколько ключей. Вместо запуска ssh user@host -i /path/to/identity_file
вы можете использовать файл конфигурации ~/.ssh/config
.
Общие настройки - IdentityFile (ключи) и порт. Следующая конфигурация будет проверять «id_dsa» и «bender» только при соединении с ssh youruser@yourhost
:
Host yourhost
IdentityFile ~/.ssh/id_dsa
IdentityFile ~/.ssh/bender
Если вы пропустите Host yourhost
, настройки будут применяться ко всем SSH-соединениям. Для этого соответствия хоста могут быть также указаны другие параметры, например User youruser
, Port 2222
и т. Д. Это позволит вам соединиться с сокращением ssh yourhost
вместо ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender
.
ssh_config(5)
: имя файла может использовать синтаксис тильды для ссылки на домашний каталог пользователя или один из следующих escape-символов: «% d» (домашний каталог локального пользователя), «% u» (локальное имя пользователя), «% l '(имя локального хоста), "% h" (имя удаленного хоста) или "% r" (имя удаленного пользователя). Не возможно указать групповые символы, но это должно быть достаточно удобно, я думаю. Имейте в виду, что сервер должен проверять каждый отправленный вами ключ, поэтому лучше указывать меньше ключей. Подстановочные знаки на хосте работают, см. Снова страницу руководстваssh_config(5)
..ssh/authorized_keys
файл на удаленных компьютерах. Если вы используете стандартное.ssh/id_rsa
имя файла (или id_dsa, id_ecdsa или недавний id_ed25519), тогда ssh попытается сделать это автоматически, и вам не нужно указывать этоIdentityFile
в вашей конфигурации (или-i path/to/id_file
параметре дляssh
).Мой любимый метод позволяет автоматически выбирать закрытый ключ
SSH заменит% l на имя локальной машины,% r на имя удаленного пользователя и% h на удаленный хост, поэтому, если я захочу подключиться со своего компьютера с именем foo к bar как пользователь, я запустлю:
И SSH будет автоматически использовать:
Поскольку локальный хост также хранится, это позволяет использовать домашние каталоги по NFS (разные ключи для машины!) Или даже определять, на какой машине должен был находиться ключ ...
источник
Принимая во внимание комментарий СтивенРуза о том, что для определения множества клавиш требуется больше времени, и мне довелось поиграть с множеством клавиш, я хотел бы предложить свое личное решение.
Я создаю символическую ссылку на ключ, который хочу использовать в данный момент, и, поскольку он меняется редко, в зависимости от того, над каким проектом я работаю, я доволен им.
Здесь я связал свои ключи для машин, работающих под virtualbox:
Можно также добавить действительно быстрый скрипт для переключения на другой набор без необходимости повторного ввода команды ln вручную .
Опять же, это не решение для двух ключей, но для большего числа это может быть работоспособным.
источник