Hot answers tagged key-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 ...
I recently needed this too, and came up with this: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com
I've discovered a shortcut for this purpose: ssh user:@example.com Note the colon (:) and the empty password after it.
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, e.g.: service ssh stop # will not kill existing ssh connections /usr/sbin/sshd -d # full path to sshd executable needed, 'which sshd' can help ...debug output... service ssh start (If you can access the server through any port, you can just ...
You need to use an ssh agent. Short answer: try $ ssh-add before pushing. Supply your passphrase when asked. If you aren't already running an ssh agent you will get the following message: Could not open a connection to your authentication agent. In that situation, you can start one and set your environment up thusly eval $(ssh-agent) Then repeat ...
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 ...
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 from ...
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. Troubleshooting sshd 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 ...
Here's what works for me: sshfs firstname.lastname@example.org:/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) man ssh_config IdentityFile Specifies a file from which the user's DSA, ECDSA or DSA authen‐ tication identity is read.
Use ssh-keygen -R hostname to remove the hostname from your known_hosts file. The next time you connect, the new host key will be added to your known_hosts file.
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 ...
You're mixing up the authentication of the server machine to the client machine, and the authentication of the user to the server machine. Server authentication 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 ...
No, you keep id_rsa to yourself; however, id_rsa.pub, which is your public key, may be copied to servers to which you wish to have access. Concatenate them onto the end of ~/.ssh/authorized_keys. Yes, you may create ~/.ssh/authorized_keys if it is not already created; otherwise, just append to the end of the file, using cat id_rsa.pub >>~/.ssh/...
You can have different private keys in different files and specify all of them in ~/.ssh/config using separate IdentityFile values (or using -i option while running ssh). They would be tried in sequence (checkout man 5 ssh_config). If you are using ssh-agent though, you might have to tell the agent about the multiple keys you have using ssh-add.
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
A way to solve this is with ssh-agent and ssh-add: $ exec ssh-agent bash $ ssh-add Enter passphrase for ~/.ssh/id_rsa: After this the passphrase is saved for the current session. and won't be asked again.
You can add the fingerprint to each server's known_hosts. For a single user: cat ~/.ssh/known_hosts echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts
When you use the IdentityFile option in your ~/.ssh/config you point to the private, not the public, key. From man ssh_config: IdentityFile 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 ...
Generating a key doesn't automatically allow you to log in with it to remote machines. You need to copy the corresponding public key to the machines you want to access, like this: ssh-copy-id email@example.com This operation will ask you for user's password on remote.machi.ne, but after that you'll be able to ssh with your key: ssh -l user remote....
What you really want to do is to use SSH CA and sign keys used by each support person (they should have their own ssh keys, like passports) and configure your clients' servers to use the TrustedUserCAKeys /etc/ssh/users_ca.pub in the /etc/ssh/sshd_config. This way the server will accept any key signed by the CA key (which you have access to) and you will be ...
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 manage these identities with ~/.ssh/config. For example: Host acc1-server User ACCOUNT1 Hostname SERVER IdentityFile ~/.ssh/id-ACC1-SRV Host acc2-server User ACCOUNT2 Hostname SERVER IdentityFile ~/.ssh/id-ACC2-SRV Afterwards just type ssh acc1-server to connect to SERVER as ACCOUNT1 with key ~/.ssh/id_rsa-ACC1-SRV, ...
The problem is the fact that files permissions are too open. Try setting the mode of authorized_keys to 600 and the .ssh directory to 700.
Also there is a tool that sorts all this for you called ssh-copy-id. It will append the key in your agent if you have one running to the authorized_keys file and create it if it does not exist with the right permissions. If you aren't running an agent you can specify the key to push with -i: ssh-copy-id -i ~/.ssh/id_rsa
You can use the Match option in sshd_config Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. So, at the end of that file you could specify: Match User ...
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 ...
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.
You SSH key is encoded in Base 64. This format is commonly used in cryptography (and beyond) to store binary information in ASCII format. And, in base64, the '=' sign is a padding character, with a very specific meaning: The '==' sequence indicates that the last group contained only 1 byte, and '=' indicates that it contained 2 bytes. The example ...
Only top voted, non community-wiki answers of a minimum length are eligible