Postępuję zgodnie z procedurą podwójnej tożsamości dla bitbucket :
Mam 2 konta bitbucket ccmcbeck
i chrisbeck
. Pierwsza jest osobista, druga to praca.
Na moim lokalnym komputerze Mac mam to w swoim ~/.ssh/config
Host *.work.com
User chris
ForwardAgent yes
IdentityFile ~/.ssh/work_dsa
Host bitbucket-personal
HostName bitbucket.org
User ccmcbeck
ForwardAgent no
IdentityFile ~/.ssh/bitbucket_ccmcbeck_rsa
Host bitbucket-work
HostName bitbucket.org
User chrisbeck
ForwardAgent no
IdentityFile ~/.ssh/bitbucket_chrisbeck_rsa
Na moim lokalnym komputerze Mac ssh -T
wszystko jest w porządku, otrzymuję:
$ ssh -T git@bitbucket-personal
logged in as ccmcbeck.
$ ssh -T git@bitbucket-work
logged in as chrisbeck.
Na moim lokalnym komputerze Mac wersja ssh to OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
Kiedy ssh foo.work.com
przechodzę do mojego Linux-a, otrzymuję:
$ ssh-add -l
1024 ... /Users/chris/.ssh/work_dsa (DSA)
2048 ... /Users/chris/.ssh/bitbucket_ccmcbeck_rsa (RSA)
2048 ... /Users/chris/.ssh/bitbucket_chrisbeck_rsa (RSA)
Na foo.work.com
, mam to też w moim~/.ssh/config
Host bitbucket-personal
HostName bitbucket.org
User ccmcbeck
ForwardAgent no
IdentityFile ~/.ssh/bitbucket_ccmcbeck_rsa
Host bitbucket-work
HostName bitbucket.org
User chrisbeck
ForwardAgent no
IdentityFile ~/.ssh/bitbucket_chrisbeck_rsa
Jednak w foo.work.com
momencie , gdy ja ssh -T
, odwołuje się do niewłaściwego użytkownikagit@bitbucket-work
$ ssh -T git@bitbucket-personal
logged in as ccmcbeck.
$ ssh -T git@bitbucket-work
logged in as ccmcbeck.
Włączona foo.work.com
jest wersja sshOpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
Dlaczego moja konfiguracja powoduje foo.work.com
odsyłanie do niewłaściwego użytkownika?
ssh-add -d
mojabitbucket-personal
tożsamość, tofoo.work.com
używa poprawnegoUser
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
foo.work.com
używa pierwszego zgłoszonego przezssh-add -l
.Odpowiedzi:
Najbardziej prawdopodobne wytłumaczenie wydaje mi się, że ssh-agent używa dowolnego klucza, który załadował w dowolnym momencie. Możesz upuścić to zachowanie, używając
IdentitiesOnly
dyrektywy w pliku konfiguracyjnym w następujący sposób:Z
ssh man page
:EDYTOWAĆ:
W twoim poście są te linie, pod sam koniec:
Wyraźnie pokazują, że ten klucz nie został zaakceptowany. Dlatego zawsze logujesz się jako ccmcbeck: ten klucz działa, a bez
IdentitiesOnly yes
niego klient próbował innych kluczy, dopóki nie znalazł działającego. Wprowadzając to ograniczenie, przynajmniej wyjaśniliśmy charakter problemu.Ponieważ z komputera Mac nie masz takiego problemu, musi on znajdować się w kliencie Linux, a zwłaszcza w kluczu prywatnym, którego próbujesz użyć. Najlepszą rzeczą jest wygenerowanie nowego, lokalnego dla Linuksa i umieszczenie jego
.pub
odpowiednika wśródauthorized_keys
. Mam nadzieję że to pomoże.EDYCJA 2:
... lub możesz postępować zgodnie z odpowiedzią SuperUser, aby wybrać klucz prywatny, którego chcesz użyć, określając jego publiczny odpowiednik od przekazanego agenta. Odpowiedź nadal wymaga użycia
IdentitiesOnly yes
opcji.źródło
ssh -T
do dowolnego aliasu.ccmcbeck
ichrisbeck
działają, jeśli są pierwszessh-add -l
bezIdentitiesOnly yes
. PoIdentitiesOnly yes
włączeniuwork.foo.com
ssh wydaje się szukać tylko kluczy lokalnych, a nie kluczy przekazywanych przez agenta ssh na moim komputerze Mac.work.foo.com
i odwołać się do tego w~/.ssh/config
. Jeśli zaktualizujesz swoją odpowiedź, zaakceptuję