Closed briggySmalls closed 6 years ago
Hi, seems that this problem is related to the ssh-agent. Running ssh-add -L
should display more than one ssh key passed to the ssh-agent and so when you trying to connect to the local VM it fails due to the "too many authentication failures" error. Clearing the entries for your ssh-agent with ssh-add -D
and re-adding the right key with ssh-add -K ~/.ssh/id_rsa
the ssh connection with the local VM should work.
Anyway, I'll update the tool with the right parameters passed to the ssh command to connect to the local VM as suggested. Thank you!
I've improved the README with the latest commit as suggested, so I close the issue as resolved. Let me know if the problem persists. Thank you for the help.
No problem. Thanks for the great tool!
Submit a feature request or bug report
Replace any
X
with your information.What is the current behavior?
When executing
./bin/database.sh production <sitename> push
TASK [Check if <_sitename_> folder exists]
fails with:
If too many key pairs are found by ssh.
What is the expected or desired behavior?
A connection to be successfully made to the vagrant VM to check the existence of the folder.
Bug report
Executing:
Returns the following:
Please describe your local environment:
Ansible version: 2.5.4 (although above command was run with 2.5.3)
OS name and version: macOS High Sierra 10.13.3
Trellis version: 1.0.0-rc2 master branch (commit 97e267107e9ad1c309473f0ce3e20f890ca18597)
Where did the bug happen? Development or remote servers?
Development server
Has the bug already been solved or discussed on Ansible issues page?
No
Other relevant information:
Executing the SSH command again manually returns:
Adding IdentitiesOnly=yes to the ssh options in
./hosts/development
fixes the issue. This is howvagrant ssh
achieves its connection, as shown by executingps aux | grep shh
:Alternatively, Adding _IdentitiesOnly=yes to ~/.ssh/config also fixed my problem.
It seems to me adding IdentitiesOnly=yes is the better option, as it mirrors the behaviour of vagrant, which is what I expected! I did not know about this behaviour of ssh. In fact I have no idea what all those public keys I have are for...