☰

Есть ли способ заставить ssh предлагать больше ключей для автоматического входа?

tag-icon • tag-icon ssh login
Есть ли способ заставить ssh предлагать больше ключей для автоматического входа?

Из множества источников в Интернете я узнал, что (примерно) для входа на удаленный сервер без пароля необходимо сгенерировать ключ SSH, поместить общедоступную версию в authorized_keys на удаленной системе; поместить закрытую версию в локальный каталог ~/.ssh/; изменить его права на 0600 и все, вы в сети. Хотя это в основном верно, я обнаружил, что ключ (пара) должен называться id_rsa (id_rsa.pub) или id_dsa (id_dsa.pub), чтобы SSH мог предложить его удаленным серверам.

Позвольте мне немного вернуться назад. У меня есть логин SurnameGна моем локальном Mac. У меня есть учетная запись SurnameG на удаленной системе, otherserver.

Я скопировал содержимое ~/.ssh/surnameg.pubв системный /home/surnameg/.ssh/authorized_keys. Я протестировал с -iопцией с моего Mac для ssh in, и это работает отлично.

У меня есть ~/.ssh/id_rsa(который я сгенерировал для использования сgithub.com).

И, конечно, у меня есть ~/.ssh/surnamegи даже некоторые другие ключи там, которые не «пробуются», когда я пытаюсь войти в систему следующим образомotherserver.com:

ssh 1.2.3.4

Здесь я пытаюсь использовать SurnameG(текущего локального вошедшего в систему пользователя) для входа в свою SurnameGучетную запись надругойсерверЯ хочу, чтобы openssh предложил ~/.ssh/surnamegпопытку подключения, но этого не происходит — давайте подробнее рассмотрим вариант с подробным описанием:

BOX:~ SurnameG$ ssh -v 1.2.3.4
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/SurnameG/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [50.112.132.124] port 22.
debug1: Connection established.
debug1: identity file /Users/SurnameG/.ssh/id_rsa type 1
debug1: identity file /Users/SurnameG/.ssh/id_rsa-cert type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA ax:64:3e:4a:e3:2c:e4:30:dd:36:a4:a0:9x:fa:ba:6b
debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /Users/SurnameG/.ssh/known_hosts:88
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/SurnameG/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /Users/SurnameG/.ssh/id_dsa
debug1: No more authentication methods to try.

Любопытно, что openssh предлагает только ~/.ssh/id_rsa, но это не все. Он также "пытается" ~/.ssh/id_dsa? Я не уверен в разнице между ними (предложение и попытка). В любом случае, если я правильно понял, openssh никогда не пытается ни один из моих других закрытых ключей в ~/.ssh/*.

Хорошо, я знаю, что могу подробно описать каждый сервер ~/.ssh/configпримерно так:

Host otherserver
   HostName 1.2.3.4
   User surnameg
   IdentityFile ~/.ssh/surnameg

и затем войти с помощью

ssh otherserver

и это прекрасно и прекрасно работает. Но на самом деле мой ~/.ssh/config становится громоздким. К сожалению, я не делал этого cd ~/.ssh && git initдавным-давно. Но я отвлекся.

Мой вопрос таков: есть ли более простой, быстрый и автоматизированный способ заставить ssh динамически пробовать больше ключей в каталоге ~/.ssh при попытках входа в систему, или редактирование вашего ~/.ssh/config для каждого сервера, к которому вам нужно подключиться, является единственным способом настроить ssh? Я что-то неправильно понял выше о том, как должен работать SSH?

решение1

Если вы хотите предложить одинаковые ключи всем хостам, загрузите их в агент SSH с помощью ssh-add. Многие дистрибутивы Linux запускают его автоматически — попробуйте ssh-add -lпроверить, запущен ли он, а затем загрузите свои ключи:

ssh-add ~/.ssh/id_rsa ~/.ssh/surnameg etc.

Если агент не запустился автоматически, поместите в свой файл следующее ~/.profile:

agent_running() {
    [ "$SSH_AUTH_SOCK" ] && { ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]; }
}

env=~/.ssh/agent.env
if ! agent_running && [ -s "$env" ]; then
    . "$env" >/dev/null
fi
if ! agent_running; then
    ssh-agent >"$env"
    . "$env" >/dev/null
    ssh-add ~/.ssh/id_*
fi    
unset env

решение2

Есть еще один возможный подход. Вы можете использовать заполнители в IdentityFileопции в ssh_config. Согласноman ssh_config:

  • %d—домашний каталог локального пользователя
  • %u—локальное имя пользователя
  • %l—локальное имя хоста
  • %h—имя удаленного хоста
  • %r—имя удаленного пользователя

Я использую это так (в глобальном ssh_configфайле):

IdentityFile ~/.ssh/%r@%h

Это означает, что мои файлы закрытых ключей имеют имена типа [email protected].

Связанный контент