You need to use your private key, not your public key, with the
Since your public key is unable to pass the challenge sent from the other server based on that same public key (asymmetric cryptography, requiring you use the private key to answer the public-key-based challenge), then when key authentication fails
ssh proceeds to attempt other authentication methods including password.
The way asymmetric cryptography works is that your private key is kept private. It should not be shared with anyone; it should not even be copied off of the host on which it is created. (And it certainly shouldn't be sent by email!)
The public key can be sent all over the place.
Data encrypted with the public key can only be decrypted by the private key, and data encrypted by the private key can only be decrypted by the public key.
Mathematically, in the RSA algorithm, there is no functional difference between the two keys except that one of them must be kept secret. However, in the actual SSH implementation, the two keys are differentiated and look different, so be sure that:
- Your public key and NOT your private key is added to the "authorized keys" file on the target server, and
- You pass your private key to
ssh -i. (No harm if you pass your public key to
-i, it just won't work.)
If you've ever shared your private key or copied it to the target server, generate a new key and delete the old one.
I just looked more closely at exactly what steps you performed. You need to back up and start over. At this point, you should delete the key pair for
target.host and remove that public key from ANY authorized keys file you've put it in. Private keys should never be copied.
Note that to SSH into email@example.com from someother.host does NOT require that foouser even have a key pair.
What is required is that you generate a key pair on someother.host for the user count you will be SSHing from, and that you put the public key of that pair into
Simple step by step, but omitting the security cleanup steps you should now do since you copied a private key around. Just the simple way to set up connectivity:
startserver.host, as user
ssh-keygen. You can make a passphrase or not; up to you. (A passphrase adds additional safety in case the private key does get compromised.) Just pressing enter at each prompt will create the key pair with default settings, which is fine.
cat ~/.ssh/id_rsa.pub to display the public key.
- Copy the output of the command onto the other host (
target.host) and append it to
ssh firstname.lastname@example.org. You don't need the
To answer the comment:
If private keys should never be copied—can you explain what good is
ssh -i when it expects a private key?
You generate the key pair on the host from which you want to
ssh to other servers.
Your private key stays on that server and is never copied elsewhere. (Maybe it's in your backups. Maybe not. But for use, it's never copied elsewhere.)
Your public key is copied onto every server you want login access to, and specifically is appended to the
authorized_keys file in the
.ssh directory in the home directory of the user you want to be able to log in as on that server.
With this setup (the default), you will never need
-i. However, you may have more than one key pair on your own computer that you use for different purposes (different sets of servers). The point of
-i is to be able to specify an alternate location from which your private key identity will be read. You could accomplish the same effect with
cd ~/.ssh; mv id_rsa id_rsa.bak; mv id_rsa.other id_rsa and then just
ssh ... without
-i is more convenient.