Korzystanie z dyrektywy IdentityFile w ssh_config, gdy agent jest używany

Czy można określić przekazane klucze za pomocą dyrektywy IdentityFile w .ssh / config?

Wpadłem na to dziwactwo, próbując wdrożyć jakiś kod za pomocą Capistrano / GIT na naszym serwerze produkcyjnym. Zarówno mój osobisty, jak i służbowy klucz GIT są zawsze ładowane do mojego agenta SSH i tak się złożyło, że mój osobisty klucz został najpierw dodany do agenta. Podczas wdrażania za pomocą Capistrano używam przekazywania agenta, więc gdy host próbował uwierzytelnić operację `git pull`, nie powiodło się z następującym błędem:

BŁĄD: Odmówiono zgody na „niektóre repo” dla „użytkownika”.

ponieważ próbował uwierzytelnić się przy użyciu mojego osobistego klucza git przed wypróbowaniem odpowiedniego klucza (który pojawił się później w agencie ssh) i założył, że uzyskiwałem dostęp do zagranicznego repo, do którego nie mam uprawnień. Mogę potencjalnie po prostu dać mojemu osobistemu użytkownikowi dostęp do każdego repozytorium pracy, ale na moim komputerze lokalnym mogę obejść ten problem, definiując niestandardowe domeny w .ssh / config w następujący sposób:

Host personal.github.com
Nazwa hosta github.com
Użytkownik git
IdentityFile ~ / .ssh / some_key

Host work.github.com
hosta github.com
użytkownika git
IdentityFile ~ / .ssh / some_other_key

i w ten sposób git nigdy się nie myli. Czy jest możliwe utworzenie reguł .ssh / config dla przekazanych kluczy w moich skrzynkach produkcyjnych, aby zawsze wiedzieli, którego klucza użyć przy pobieraniu nowego kodu? Zasadniczo chcę być w stanie:

Host work.github.com
Nazwa hosta github.com
Użytkownik git
IdentityFile some_forwarded_key

Dzięki!

— skryl
źródło

Za pomocą publicznej części klucza można określić klucz prywatny, którego chcesz użyć z przekazanego agenta. Wymaga to utworzenia dodatkowego pliku (publicznej części klucza) na dowolnych „pośrednich” komputerach (komputerach, na które przekazujesz lokalnego agenta ssh ).

Umów się, aby komputer pośredni miał kopię publicznej części żądanego klucza w dogodnej lokalizacji (np ~/.ssh/some_other_key.pub.).

Z dowolnego komputera, który ma już publiczną część klucza:
```
scp some_other_key.pub intermediate:.ssh/
```
lub na maszynie pośredniej:
```
ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
```
Możesz edytować końcową część „komentarza” klucza publicznego, aby lepiej zidentyfikować pochodzenie / właściciela / przeznaczenie klucza (lub spróbować ukryć to samo).
Użyj nazwy ścieżki do powyższego pliku klucza publicznego za pomocą -ilub IdentityFile.
Może być również konieczne użycie IdentitiesOnly yes(w .ssh/configlub -o), aby powstrzymać ssh od próby zaoferowania jakichkolwiek dodatkowych tożsamości od przekazanego agenta.

— Chris Johnsen
źródło

To jedyna rzecz, która zadziałała dla mnie z 10 innych rozwiązań.

— Tracy Fu,

Grając z tym zdałem sobie sprawę, że jeśli umieścisz klucz publiczny powiązany z kluczem prywatnym, którego chcesz użyć w ~ / .ssh / id_rsa.pub na maszynie pośredniej, zostanie on użyty domyślnie, bez potrzeby jakiejkolwiek konfiguracji w ~ / .ssh / config.

— bschlueter

Dzięki Chris i bschlueter! Teraz łączę się z: ssh someserver -t "ssh-add -L | grep something_unique> ~ / .ssh / id_rsa.pub; cd some / other / folder; bash --login"

— blablabla

Kiedy próbuję tego z ssh -v -T ...serwerem akceptuje klucz publiczny, ale potem ssh mówi, No such identity: /home/name/.ssh/id_rsa: No such file or directorya następnie uwierzytelnianie kończy się niepowodzeniem. Mam włączone ForwardAgent we wszystkich moich konfiguracjach. Co może być problemem?

— Lars Nyström,