Tag Info

Hot answers tagged

90

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 ...


39

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 ...


26

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 ...


22

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.


18

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 ...


15

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.


13

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 ...


12

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 ...


12

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


11

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.


11

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


11

Here's what works for me: sshfs me@x.x.x.x:/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.


11

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 ...


10

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, ...


10

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 created a /etc/ssh/username folder, owned by ...


9

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.[1] So, at the end of that file you could specify: Match User ...


9

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


8

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 ...


8

That question is worried about private keys stored on the server unencrypted. It's a scenario like: workstation 1 ---> gateway -> final server ⋮ | workstation n ------/ and the OP is worried about private keys on "gateway", which is a shared machine with multiple users. It is not possible to steal the private key by compromising ...


7

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 ...


7

You can see which SSH public key was used in the syslog. The authentication subset of the syslog is usually at /var/log/auth.log. For the whole syslog, you can try /var/log/syslog or /var/log/messages. The log lines should look something like this: Sep 10 19:17:00 server.example.com sshd[1337]: Accepted publickey for ansible from 127.0.0.1 port 59934 ...


6

You have to create your key first. ZFS supports two types of file based keys. Hex, and raw. For this you can use openssl to generate the key. openssl rand -out /media/stick/key 16 The 16 creates a 16-byte (i.e., 128-bit) key. For a 192-bit or 256-bit key use 24 or 32 respectively. Then create your dataset as you normally would, specifying the key. zfs ...


6

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 ...


6

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 ...


6

You can misuse /root/.ssh/rc for your purpose (see man sshd) and include a mailx command there.


6

I suggest reading the ssh_config man page. If you want to have a specific identity per-host, and another for all other hosts, do something like this in your ~/.ssh/config: Host hostname.example.com IdentityFile ~/.ssh/identity_rsa_or_else_private_key_file Host * IdentityFile ~/.ssh/another_identity_file By default, it uses ~/.ssh/id_rsa for the ...


6

I think what you're referring to is what's called the challenge-response model. With this approach the key pairs are never exposed in a manner that they could be sniffed off the wire, as is the case with sending a password over the line. And so it's deemed much safer because of this fact. One of the answers to this security SE Q&A titled: Is using a ...


5

You should also check the permissions on the various files and directories: authorized_keys needs perms of 600 (chmod 600 authorized_keys) the .ssh directory should be 700 your home directory should be at most 744 Your home directory must not be writable by anyone other than you.


5

Yes: -i identity_file 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 and ~/.ssh/id_rsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. ...


5

Try running eval $(ssh-agent -s) before ssh-add, to export the environment variables that refer to the just started agent, then run ssh-agent -k (without eval) at end of script to kill the agent.



Only top voted, non community-wiki answers of a minimum length are eligible