Я хочу використовувати декілька приватних ключів для підключення до різних серверів або різних частин одного сервера (мої способи використання - це системне адміністрування сервера, адміністрування Git та звичайне використання Git в межах одного сервера). Я спробував просто скласти ключі у id_rsaфайли, безрезультатно.

Мабуть, прямо це зробити - скористатися командою

ssh -i <key location> login@server.example.com 

Це досить громіздко.

Будь-які пропозиції щодо того, як зробити це трохи простіше?

Від мого .ssh/config:

Host myshortname realname.example.com
    HostName realname.example.com
    IdentityFile ~/.ssh/realname_rsa # private key for realname
    User remoteusername

Host myother realname2.example.org
    HostName realname2.example.org
    IdentityFile ~/.ssh/realname2_rsa  # different private key for realname2
    User remoteusername

І так далі.

Ви можете доручити ssh спробувати кілька клавіш послідовно під час з'єднання. Ось як:

$ cat ~/.ssh/config
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_old
IdentityFile ~/.ssh/id_ed25519
# ... and so on

$ ssh server.example.com -v
....
debug1: Next authentication method: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa_old
debug1: read PEM private key done: type RSA
....
[server ~]$

Таким чином, вам не потрібно вказувати, який ключ працює з яким сервером. Він буде просто використовувати перший робочий ключ.

Крім того, ви б ввели пароль, лише якщо даний сервер готовий прийняти ключ. Як було показано вище, ssh не намагався запитувати пароль, .ssh/id_rsaнавіть якщо він був.

Звичайно, це не перевершує конфігурацію кожного сервера, як в інших відповідях, але принаймні вам не доведеться додавати конфігурацію для всіх і кожного сервера, до якого ви підключаєтесь!

Відповідь від Рендал Шварц майже допоміг мені весь шлях. У мене на сервері інше ім’я користувача, тому мені довелося додати до мого файлу ключове слово користувача :

Host           friendly-name
HostName       long.and.cumbersome.server.name
IdentityFile   ~/.ssh/private_ssh_file
User           username-on-remote-machine

Тепер ви можете підключитися за допомогою дружнього імені:

ssh friendly-name

Більше ключових слів можна знайти на чоловічій сторінці OpenSSH . ПРИМІТКА. Деякі з перелічених ключових слів можуть бути вже наявними у вашому / etc / ssh / ssh_config файлі.

Попередні відповіді правильно пояснили спосіб створення файлу конфігурації для керування кількома ключами ssh. Думаю, важливим, що також потрібно пояснити, є заміна імені хоста на ім'я псевдоніма під час клонування сховища .

Припустимо, ім’я користувача облікового запису GitHub вашої компанії abc1234 . І припустимо , ім’я вашого особистого облікового запису GitHub - jack1234

Припустимо, ви створили два ключі RSA, а саме id_rsa_company та id_rsa_personal . Отже, ваш конфігураційний файл буде виглядати нижче:

# Company account
Host company
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company

# Personal account
Host personal
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_personal

Тепер, коли ви клонуєте сховище (з ім’ям демонстрації) з облікового запису компанії GitHub, URL-сховище буде приблизно таким:

Repo URL: git@github.com:abc1234/demo.git

Тепер, виконуючи ці дії git clone, ви повинні змінити вищевказану URL-адресу сховища як:

git@company:abc1234/demo.git

Зверніть увагу, як тепер github.com замінено псевдонімом "company", як ми визначили у файлі конфігурації.

Подібно, вам потрібно змінити URL-адресу клонування сховища в особистому обліковому записі залежно від псевдоніму, який надається у файлі конфігурації.

foo:~$ssh-add ~/.ssh/xxx_id_rsa

Переконайтесь, що ви протестували його, перш ніж додавати:

ssh -i ~/.ssh/xxx_id_rsa username@example.com

Якщо у вас виникли проблеми з помилками, іноді зміна безпеки файлу допомагає:

chmod 0600 ~/.ssh/xxx_id_rsa

1. Створити ключ SSH:

   $ ssh-keygen -t rsa -C <email1@example.com>
   

2. Створити another SSH key:

   $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <email2@example.com>
   

   Тепер у каталозі мають існувати два відкриті ключі ( id_rsa.pub , accountB.pub ) ~/.ssh/.

   $ ls -l ~/.ssh     # see the files of '~/.ssh/' directory 
   

3. Створіть конфігураційний файл ~/.ssh/configіз таким вмістом:

   $ nano ~/.ssh/config
   
   Host bitbucket.org  
       User git  
       Hostname bitbucket.org
       PreferredAuthentications publickey  
       IdentityFile ~/.ssh/id_rsa  
   
   Host bitbucket-accountB  
       User git  
       Hostname bitbucket.org  
       PreferredAuthentications publickey  
       IdentitiesOnly yes  
       IdentityFile ~/.ssh/accountB  
   

4. Клон з defaultрахунку.

   $ git clone git@bitbucket.org:username/project.git
   

5. Клон з accountBрахунку.

   $ git clone git@bitbucket-accountB:username/project.git
   

Детальніше тут

Я погодився б з Туомасом щодо використання ssh-агента. Я також хотів додати другий приватний ключ для роботи, і цей підручник працював як шарм для мене.

Кроки наведені нижче:

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key напр ssh-add ~/.ssh/id_rsa
3. Підтвердити за $ ssh-add -l
4. Перевірте це, $ssh -v <host url>наприкладssh -v git@assembla.com

Я не раз стикався з цією проблемою, коли у мене було два облікові записи Bitbucket і хотілося зберігати окремі SSH ключі для обох. Це те, що працювало для мене.

Я створив дві окремі конфігурації ssh наступним чином.

Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/personal
Host work.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/work

Тепер, коли мені довелося клонувати сховище зі свого робочого рахунку - команда була такою.

git clone git@bitbucket.org:teamname/project.git

Мені довелося змінити цю команду на:

git clone git@**work**.bitbucket.org:teamname/project.git

Аналогічно команду клонування з мого особистого кабінету довелося змінити

git clone git @ personal .bitbucket.org: ім'я / personalproject.git

Перейдіть за цим посиланням для отримання додаткової інформації.

Використовуйте ssh-агент для своїх ключів.

Тепер, з останньою версією git, ми можемо вказати sshCommand у специфічному файлі git config для сховища.

  [core]
      repositoryformatversion = 0
      filemode = true
      bare = false
      logallrefupdates = true
      sshCommand = ssh -i ~/.ssh/id_rsa_user   
   [remote "origin"]
      url = git@bitbucket.org:user/repo.git
      fetch = +refs/heads/*:refs/remotes/origin/*

ВАЖЛИВО: Ви повинні запустити ssh-агент

Ви повинні запустити ssh-агент (якщо він вже не працює), перш ніж використовувати ssh-add:

eval `ssh-agent -s` # start the agent

ssh-add id_rsa_2 # where id_rsa_2 is your new private key file

Зауважте, що команда eval запускає агент на GIT bash на windows. Інші середовища можуть використовувати варіант для запуску агента SSH.

Ви можете створити файл конфігурації, названий configу вашій ~/.sshпапці. Він може містити:

Host aws
    HostName *yourip*
    User *youruser*
    IdentityFile *idFile*

Це дозволить вам підключитися до таких машин

 ssh aws

На ubuntu 18.04 робити нічого.

Після успішного створення другого ключа ssh система спробує знайти відповідний ключ ssh для кожного з'єднання.

Щоб зрозуміти, ви можете створити новий ключ за допомогою цих команд

# generate key make sure you give it a new name (id_rsa_server2)
ssh-keygen 
# make sure ssh agent is running
eval `ssh-agent`
# add the new key
ssh-add ~/.ssh/id_rsa_server2
# get the public key to add it to a remote system for authentication
cat ~/.ssh/id_rsa_server2.pub

Кілька пар ключів у GITHUB

1,0 SSH CONFIG FILE

1.1 СТВОРИТИ ~ / .ssh / config

1,2 chmod 600 ~ / .ssh / config (ОБОВ'ЯЗКОВО)

1.3 вхід, наступний у файл:

Піца господаря

HostName github.com

PreferredAuthentication publickey # необов'язково

IdentityFile ~ / .ssh / privatekey1

Випадок A: свіжий новий GIT CLONE

використовуйте цю команду для git clone:

$ git clone git @ pizza: yourgitusername / pizzahut_repo.git

Примітка. Якщо ви хочете в майбутньому змінити ім'я хосту “pizza” .ssh / config, перейдіть у клоновану папку git та відредагуйте рядок URL-адреси .git / config (див. Випадок B)

Випадок B: ВЖЕ МАЄТЬ СКЛАДУ GIT CLONE

2.1 перейдіть до клонованої папки, потім перейдіть у .git папку

2.2 редагувати конфігураційний файл

2.3 оновіть URL-адресу від старого до нового:

(Old) url = git@github.com:yourgitusername/pizzahut_repo.git    

(New) url = git@pizza:yourgitusername/pizzahut_repo.git

для мене єдиним робочим рішенням було просто додати ~/.ssh/config

Host *
  IdentityFile ~/.ssh/your_ssh_key
  IdentityFile ~/.ssh/your_ssh_key2
  IdentityFile ~/.ssh/your_ssh_key3
  AddKeysToAgent yes

your_ssh_key без будь-якого розширення, не використовуйте .pub

На Centos 6.5, що працює з OpenSSH_5.3p1, OpenSSL 1.0.1e-fips, я вирішив проблему, перейменувавши свої ключові файли, щоб жоден з них не мав ім'я за замовчуванням. Мій каталог .ssh містить id_rsa_foo та id_rsa_bar, але немає id_rsa тощо.

Як mentionend на Atlassian сторінці блогу генерувати конфігурації в межах .ssh , включаючи наступний текст:

#user1 account
 Host bitbucket.org-user1
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user1
     IdentitiesOnly yes

 #user2 account
 Host bitbucket.org-user2
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user2
     IdentitiesOnly yes

Тоді ви можете просто зареєструватися з доменним суфіксом, і в межах проектів ви можете налаштувати імена автора тощо.

Ви можете спробувати цей пакет sshmulti npm для підтримки декількох ключів ssh.

Ось рішення, яке я використав, натхненний відповіддю @ sajib-khan. Конфігурація за замовчуванням не встановлена, це мій особовий рахунок на gitlab, а інший вказаний - мій обліковий запис компанії. Ось що я зробив:

Створіть ключ ssh

ssh-keygen -t rsa -f ~/.ssh/company -C "name.surname@company.com"

Відредагуйте ssh config

nano ~/.ssh/config

    Host company.gitlab.com
    HostName gitlab.com
    PreferredAuthentications publickey  
    IdentityFile ~/.ssh/company

Видалити кешовані ssh-ключі

ssh-add -D

Перевірте це!

ssh -T git@company.gitlab.com

Ласкаво просимо до GitLab, @ hugo.sohm!

ssh -T git@gitlab.com

Ласкаво просимо до GitLab, @HugoSohm!

Використай це !

Рахунок компанії

$ git clone git@company.gitlab.com:group/project.git

Персональний / типовий обліковий запис

$ git clone git@gitlab.com:username/project.git

Ось джерело, яке я використав, сподіваюся, що це допомагає!

Я люблю підхід встановити наступне в ~ / .ssh / config:

# Config for Github to support multiple Github keys
Host  github.com
  HostName github.com
  User git
# UseKeychain adds each keys passphrase to the keychain so you don't have to enter the passphrase each time.
  UseKeychain yes
# AddKeysToAgent would add the key to the agent whenever it is used, which might lead to debugging confusion since then sometimes the one repo works and sometimes the other depending on which key is used first.
#  AddKeysToAgent yes
# I only use my private id file so all private repos don't need the env var `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
  IdentityFile ~/.ssh/id_rsa

Тоді у вашому репо репері можна створити .envфайл, який містить команду ssh, яка буде використовуватися:

GIT_SSH_COMMAND="ssh -i ~/.ssh/your_ssh_key"

Якщо ви використовуєте, наприклад, dotenv, середовище var експортується автоматично, а whoop whoop ви можете вказати потрібний ключ для проекту / каталогу. Пасфаза запитується лише один раз, оскільки вона додана в брелок.

Це рішення відмінно працює з git і розроблено для роботи на Mac (завдяки UseKeychain).