I recently needed this too, and came up with this:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com
You need to make sure that the client isn't configured to disallow password authentication.
Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.
Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but ...
Use the -l option to ssh-add to list them by fingerprint.
$ ssh-add -l
2048 72:...:eb /home/gert/.ssh/mykey (RSA)
Or with -L to get the full key in OpenSSH format.
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc[...]B63SQ== /home/gert/.ssh/id_rsa
The latter format is the same as you would put them in a ~/.ssh/authorized_keys file.
If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, by issuing something like /usr/sbin/sshd -d -p 2222 on the server (full path to sshd executable required, which sshd can help) and then connecting from the client with ssh -p 2222 user@host. This will force the SSH daemon to stay in the foreground and ...
In my mind now what would happen is I would send them my public key which could be placed inside their authorized keys folder.
What's "in your mind" as what should now happen is correct.
Email is not a secure channel of communication, so from a standpoint of proper security, you (and they) should consider that private key compromised.
Depending on your ...
Here's what works for me:
sshfs email@example.com:/remote/path /local/path/ -o IdentityFile=/path/to/key
You can figure this out via man sshfs:
-o SSHOPT=VAL ssh options (see man ssh_config)
Specifies a file from which the user's DSA, ECDSA or DSA authen‐
tication identity is read.
The OpenSSH website has a page dedicated to legacy issues such as this one. It suggests the following approach, on the client:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 184.108.40.206
or more permanently, adding
This will enable the old algorithms on the client, ...
Set StrictHostKeyChecking no in your /etc/ssh/ssh_config file, where it will be a global option used by every user on the server. Or set it in your ~/.ssh/config file, where it will be the default for only the current user. Or you can use it on the command line:
ssh -o StrictHostKeyChecking=no -l "$user" "$host"
Here's an explanation of how this works ...
Yes, it is impossible to recover the private key from the public key. If it was possible, RSA would be fundamentally broken, and this would be major news (breaking RSA would not only break a lot of Internet communication security, but also allow all kinds of banking fraud, amongst others).
Logging in with a public key instead of a password in fact tends to ...
If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.
What I find generally very useful in any such cases is to start sshd without letting it daemonize. The problem in my case was that ...
Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config.
What I ended up doing was create a /etc/ssh/username folder, owned by ...
A way to solve this is with ssh-agent and ssh-add:
$ exec ssh-agent bash
Enter passphrase for ~/.ssh/id_rsa:
After this the passphrase is saved for the current session. and won't be asked again.
Should I just ignore the key he sent me and ask them to put my public key inside their authorized folder?
Yes, that's exactly what you should do. The whole point with private keys is that they are private, meaning only you have your private key. Since you received that key from the admin, he also has it. So he can impersonate you any time he wants.
You're mixing up the authentication of the server machine to the client machine, and the authentication of the user to the server machine.
One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client ...
As well as the method posted by scoopr, you can set per host options in your ssh client configuration file.
In your .ssh directory, create a file called config (if it doesn't already exist) and set the permissions to 600, you can then create sections which start with
host <some hostname or pattern>
and then set per host options after that, for ...
The AddKeysToAgent option does what I want. I can specify -o AddKeysToAgent=yes on the command line or add AddKeysToAgent yes on a line by itself in my .ssh/config. Either works.
It looks like this is a very recent addition to openssh, appearing in release 7.2, dated 2016-02-28!
Thanks, OpenBSD! I'll be using this a ...
Just try these following commands
Press Enter key till you get the prompt
ssh-copy-id -i root@ip_address
(It will once ask for the password of the host system)
Now you should be able to login without any password
ssh-keyscan - Gather ssh public keys
If you already know the list of hosts you will connect to, you can just issue:
ssh-keyscan host1 host2 host3 host4
You can give the -H option to have it hash the results like ssh defaults to now
Also you can give -t keytype were keytype is dsa, rsa, or ecdsa if you have a preference as to which type of key to grab ...
When you use the IdentityFile option in your ~/.ssh/config you point to the private, not the public, key.
From man ssh_config:
Specifies a file from which the user's DSA, ECDSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa ...
I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
Have a look at your ssh man page:
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
What you need to do is specify which private key to use in the ~/.ssh/config file. for example:
I tried this solution, but my problem was that I had many (legacy) clients connecting to my recently upgraded server (ubuntu 14 -> ubuntu 16).
The change from openssh6 -> openssh7 disabled by default the diffie-hellman-group1-sha1 key exchange method.
After reading this and this I came up with the changes I needed to do to the /etc/ssh/sshd_config file:
Gilles' answer is generally good, except
...especially if you're just storing the key in ~/.ssh where only
system administrators (who also know what IP address you logged in
from) can see it.
Your ssh keys in ~/.ssh can also be read by any software running under your own account. Which is probably most of the software you run. So you must trust ...
You can generate the public key using ssh-keygen -y. If your private key is in the default location, you can use the following to put the public key in the same place:
ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
SSH keys have two parts, the secret/private key (usually in ~/.ssh/id_rsa), and the public key (~/.ssh/id_rsa.pub). The secret key can be used to prove who you are (or at least that you hold that secret key), and the public key can be used to check the secret key.
You never pass the secret key to any other party, as that would give them the ability to ...