Vraag Waarom werkt ssh-agent doorsturen niet?


Op mijn eigen computer, met MacOSX, heb ik dit in ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 is een virtuele machine met Ubuntu 12.04. Ik doe het zo:

ssh pupeno@b1

en ik word ingelogd zonder dat ik om een ​​wachtwoord wordt gevraagd, omdat ik al mijn publieke sleutel heb gekopieerd. Vanwege doorsturen zou ik in staat moeten zijn om naar pupeno @ b1 van b1 te sshennen en het zou moeten werken, zonder me om een ​​wachtwoord te vragen, maar dat doet het niet. Het vraagt ​​me om een ​​wachtwoord.

Wat mis ik?

Dit is de uitgebreide uitvoer van de tweede ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

45
2017-07-03 16:32


oorsprong




antwoorden:


Het bleek dat mijn sleutel niet in de agent zat, en daarmee is het opgelost:

OS X:

ssh-add -K

Linux / Unix:

ssh-add -k

U kunt geladen sleutels weergeven met behulp van:

ssh-add -l

73
2017-07-03 16:48



Let daar op ssh-add -K is specifiek voor OS X. - Roger Lipscombe


Ik had een probleem met het doorstuurverzoek van sshd-serververwijderingsagent omdat er geen ruimte over was in / tmp. Dit kwam omdat sshd socket in / tmp moet maken. Ik heb mijn probleem opgelost door de schijf op te ruimen.

ssh -v zei toen:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

5
2018-05-22 11:02



Ik had hetzelfde probleem, alleen de rechten waren verkeerd op / tmp. BEDANKT!! - nevyn


  1. Controleer of uw ./ssh/id_rsa .ssh/id_dsa  .ssh/id_ecdsa bestanden hebben de juiste rechten die eigendom moeten zijn van je gebruiker en moeten 600 zijn.

  2. Controleer of u de juiste openbare sleutel hebt ingeschakeld pupeno/.ssh/authorized_keys op b1 en controleer of authorized_keys heeft een regeleinde aan het einde van de sleutel.

  3. Controleer of je ssh-agent hebt, probeer de sleutels via te laden ssh-add

  4. Probeer op GSSAPI gebaseerde authenticatie en doorsturen met ssh -K


5
2017-07-03 16:41



De toestemming van de toetsen is prima en de sleutel in authorized_keys is prima (anders denk ik dat ik problemen heb om op de eerste plaats te verbinden). - pupeno
Heb je ssh-agent gehad? Wat gebeurt er als je een ssh-add dan ssh -A pupeno @ b1 en dan ssh pupeno @ b1? - Daniel Prata Almeida
Waarom update je het antwoord niet om ssh-add -K te vermelden en ik accepteer de jouwe in plaats van de mijne (aangezien de informatie vrijwel gelijktijdig werd gepost). - pupeno


Een andere mogelijke reden is het delen van verbindingen: de ene is al ingelogd op de andere host zonder doorgestuurde agent te delen en de verbinding te delen. De tweede login met ssh -A (of equivalent gespecificeerd in het configuratiebestand) via de gedeelde verbinding negeert het -A vlag. Pas nadat u zich volledig hebt afgemeld of verbindings delen hebt uitgeschakeld voor de tweede keer aanmelden, werkt de agentdoorschakeling.


4
2017-08-14 18:43





Ten behoeve van andere googlers die ook op deze vraag zijn aangekomen:

Onjuiste witruimte in een ~ / .ssh / config-bestand kan ook leiden tot wat hoofd krabben.

Ik heb onlangs een van mijn collega's geholpen die dit hadden:

# incorrect
host foobar ForwardAgent yes

in plaats van dit:

# correct
host foobar
  ForwardAgent yes

Ik ben ook gevallen tegengekomen waarbij ontbrekende inspringing van de richtlijnen onder de lijst met hosts een verschil maakte voor functionaliteit, hoewel dat niet de bedoeling is.


1
2017-07-18 20:22





Voeg de volgende regels toe aan .ssh / config-bestand

  Host **Server_Address**
     ForwardAgent yes

Sleutel toevoegen aan SSH Agent

 ssh-add -K

Maak verbinding met Remote Server

ssh -v **username**@**Server_Address**

Voer een verbindingstest uit met GitHub

ssh -T git@github.com

Voer de remote test uit op de gerichte git repository

git ls-remote --heads git@github.com:**account**/**repo**.git

0
2017-08-17 01:39