New answers tagged ssh-keys
When you write Host BitBucket, you also have to ssh BitBucket, not the real hostname (but you could put that into the Host line...)
Update I think the issue you get is because you were using other key previously. Please remove ~/.ssh/known_hosts file: rm ~/.ssh/known_hosts Anyway: debug1: Authentication succeeded (publickey). It is working correctly and the same key that is specified is being used. The connection is closed due to a reason specified in the log: you cannot use the ...
According to ssh-config(5), ssh will always try all keys known by the agent in addition to any Identity Files: IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files config‐ ured in the ssh_config files, even if ssh-agent(1) offers more identities. The argument to this keyword must be “yes” or ...
So I had 5 keys in my ssh-agent and despite the explicit option of using the vagrant ssh key it still insisted on looping through keys in my agent before reaching max_tries conveniently before getting to the right key. To check you have this problem: Run ssh-add -l - if this list is > 5 you need to remove keys or disable the agent. To fix: Run ssh-add -d ...
Key message is Received disconnect from 192.168.222.111: 2: Too many authentication failures for vagrant You copied the vagrant ssh-config output as the default host into .ssh/config but this is skipped because it has conflicting parameters (hostname, port). With no matching entry, ssh will just try all the keys it can find. Test the ssh attempt ...
Oh sweet heavens, the answer from this question by s_t_e_v_e worked: http://stackoverflow.com/questions/4008837/configure-ssl-on-jetty I have no idea why and the documentation for this stuff is really wild, kudos to anyone that can figure it out on their own!
Try running the command like below: knife ec2 server create --image ami-xxxx -i /root/.ssh/deploy.pem --flavor t1.micro -x root --groups ChefGroup -Z ap-southeast-1a -r "recipe[apt]"
I looked online and there are VPS consoles that will enable you access to your server. Your cloud provider should be able to help you with this. After you get back into the server copy a "known good" copy of the sshd_config file, over top your existing file. Are you sure you disabled all other methods of connecting to your server?
Login via your remote console, rescue disk, etc, depending on what your provider gives you. If you only want to be able to ssh to root with keys, and not with passwords, then set: PermitRootLogin without-password
You need console/out of band access. Contact your hosting provider or schedule a visit or whatever.
Top 50 recent answers are included