Istnieje bardzo podobne pytanie, na które odpowiedź może być odpowiedzią na to pytanie. Niestety jest to przypadek „nie trzeba odpowiadać na zadane przeze mnie pytanie, ponieważ problem nie był taki, jak myślałem”.

Ustawić

1. Serwer bastion.ec2 akceptuje połączenie ssh z mojej stacji roboczej za pośrednictwemssh -i mykey.pem [email protected]
2. Serwer service1.ec2 przyjmuje połączenia ssh tylko z bastion.ec2 przezssh -i sharedkey.pem [email protected]

Wymagania

1. Oba klucze są tylko na mojej stacji roboczej, więc nie mogę wykonać drugiego polecenia bez skopiowania klucza
2. Ze względów bezpieczeństwa chcę używać przekazywania ssh-agent zamiast kopiować klucze ssh do bastion.ec2

Rozwiązanie

W tym miejscu wchodzisz. Jak mogę przekazać inny klucz dla drugiego połączenia?

Jeśli shareuser miałby plik mykey.pub, działałoby to ~/.ssh/authorized_keys:

ssh -i mykey.pem [email protected] ssh [email protected]

Nie chcę jednak, aby każdy użytkownik musiał umieszczać swój klucz publiczny na każdym serwerze.

Krok 1

Upewnij się, że Twój lokalny agent jest gotowy

To, że możesz ssh na serwerze bastionu bez określania ścieżki klucza lub uzyskiwania monitu o hasło, nie oznacza, że ​​agent ssh jest uruchomiony i trzyma Twój klucz. Niektóre nowoczesne systemy operacyjne (np .: OSX) obsługują to za Ciebie.

Na twoim komputerze lokalnym

$ ssh-add -L
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem

^Ryc.1

Oznacza to, że agent działa i ma Twój klucz.

$ ssh-add -L
The agent has no identities.

^Ryc.2

Oznacza to, że nie dodałeś żadnych kluczy do swojego agenta. Napraw to za pomocą:

ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem

^Ryc.3

Krok 2

Upewnij się, że Twój zdalny agent jest gotowy

SSH na serwerze bastionu i powtórz sprawdzenie z rys. 1 i rys . 2 . Jednak bardziej prawdopodobny błąd to:

$ ssh-add -L
Could not open a connection to your authentication agent.

^Ryc.4

To najprawdopodobniej oznacza, że ​​klient SSH nie przekazuje połączenia z agentem uwierzytelniania.

Możesz to wymusić za pomocą -Aflagi (o ile pozwala na to konfiguracja sshd na serwerze, co jest ustawieniem domyślnym ).

$ ssh -A bastion.ec2

^rys.5

Krok 3

Upewnij się, że używasz odpowiednich kluczy

Jeśli dodano klucze do agenta, agent przekazuje dalej, a zdalny agent wyświetla klucze lokalne. Istnieją tylko dwa prawdopodobne powody, dla których nie można uzyskać połączenia. Albo nie używasz właściwego klucza, albo nie używasz właściwej nazwy użytkownika.

Wypisuj publiczny odpowiednik do swojego klucza prywatnego:

$ cd
$ cd .ssh
$ ssh-keygen -y -f mykey.pem
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13
$ ssh-keygen -y -f sharedkey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13

^Ryc.6

Te powinny być takie same jak to, co było zobaczyć od ssh-add -Lgóry do ==najbliższej końca.

Teraz w ten czy inny sposób musisz wejść do pola, z którym nie możesz się połączyć, i sprawdzić zawartość $HOME/.ssh/authorized_keyspliku dla użytkownika, z którym próbujesz się połączyć. Musisz upewnić się, że klucz publiczny, który wypisujesz za pomocą powyższego polecenia, znajduje się w tym pliku w wierszu. Nie możesz ufać, że to, sharedkey.pubco przesłałeś do ciebie pocztą Bro 2, ma rację. Zweryfikować! Może to wymagać pozyskania kogoś, kto może SSH jako ten użytkownik, aby uzyskać plik autoryzowanych_kluczy lub uzyskać dostęp do konta root. Jeśli zaszedłeś tak daleko i nadal nie działa, nie masz możliwości korzystania ze skrótów.

Krok 4

Uczynić to prostym

Mamy nadzieję, że powyższe kroki Cię wciągnęły. Teraz sprawmy, aby ból głowy zniknął na tak długo, jak długo używasz tej stacji roboczej.

Skonfiguruj lokalnego klienta ssh

Host *
    # A lot of people put an IdentityFile line in this Host * section.
    # Don't do that unless you will use only 1 key everywhere forever.
    #IdentityFile id_rsa

Host bastion.ec2
    # You want to make sure you always forward your agent to this host.
    # But don't forward to untrusted hosts. So don't put it in Host *
    ForwardAgent yes
    # Go a head and put the IP here in case DNS ever fails you.
    # Comment it out if you want. Having it recorded is a good backup.
    HostName 172.31.0.1
    # You don't want to create a proxy loop later, so be explicit here.
    ProxyCommand none
    # SSH should try using all keys in your .ssh folder, but if you
    # know you want this key, being explicit speeds authentication.
    IdentityFile ~/.ssh/mykey.pem

# Connect effortlessly by hostname or IP address
# This assumes that your internal DNS uses the fake TLD ec2
# This assumes that 172.31.0.0 is your C-Class subnet
Host *.ec2 172.31.*
    # This command says proxy all ssh connections through bastion as if
    # you had done an ssh -A
    ProxyCommand ssh -W %h:%p bastion.ec2
    ForwardAgent yes
    # These next lines are documentation you leave as a love letter to
    # your future self when all else fails or you have to help a
    # coworker and decide to look at your own config.
    # ssh-add ~/.ssh/*.pem
    # ssh -At bastion.ecs ssh [email protected]

^Ryc.7

Jeśli nie bierzesz nic innego z rys . 7, powinno to być właściwe użycie ProxyCommand& ForwardAgent.

Automatycznie wypełnij plik .bash_profile

Nie musisz robić tego ssh-addręcznie przy każdym logowaniu do komputera. ~/.bash_profileto skrypt uruchamiany przy każdym logowaniu **. Umieść linię z rys. 3 tam i zawsze powinieneś mieć swojego agenta gotowego.

** Nie należy mylić tego z działaniem .bashrcdla każdego nowego [interaktywnego] terminala. Agent nadal działa, nawet jeśli zamkniesz wszystkie sesje terminalu. Nie trzeba ponownie ładować kluczy

Alternatywa dla używania .bash_profile

Utworzyłem także listę dodającą agenta uruchamiania OSX / macOS . Możesz użyć tej metody do uruchomienia ssh-agentprzy starcie. Jest bardzo łatwy w instalacji:

curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash

W tym miejscu wchodzisz. Jak mogę przekazać inny klucz dla drugiego połączenia?

Nie przekazujesz kluczy. Przekazujesz agenta, który może mieć całkowicie niezależne klucze, których używasz do uwierzytelnienia w pierwszym skoku. Sprawdź klucze w swoim agencie za pomocą ssh-add -L.

Ale jeszcze lepiej, uruchom połączenie ProxyCommand ssh -W %h:%p [email protected], co pozwoli uniknąć konieczności przekazywania agenta, sterty lub opcji wiersza polecenia oraz konieczności uwierzytelnienia z bezpośredniego hosta.

Możesz to po prostu umieścić w swojej konfiguracji (patrz man ssh_config).