Tag Info

Hot answers tagged

52

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 ~ and your ~/.ssh directory on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good, even if you ...


36

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


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

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


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

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.


10

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


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


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

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


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

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


8

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.


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

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


6

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


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


5

I found the solution based on @jasonwryan comment under my question. There was #AuthorizedKeysFile /usr/NX/home/nx/.ssh/authorized_keys2 in the /etc/ssh/sshd_config sshd config file. Changing the entry to standard AuthorizedKeysFile .ssh/authorized_keys solved the issue.


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

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


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

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


5

For automated logins you have to use keyless ssh keys as you would have to manually intervene at the startup and provide a pass-phrase and have to resupply it after an restart. To secure such keys there are multiple solutions - see man sshd for more details: Restrict the remote host for the key with the from= parameter, e.g: from="*.example.com" ssh_key ...


5

A key pair is not tied to you as a user or your machine. Imagine having the keys to your house stolen. The keys aren't bound to you, anyone can use them to unlock your doors. In the exact same way, if I get my hands on your private key, I can use it to make changes to your Github repositories. If you wish to access your repositories using both your new keys ...


5

Here's the culprit: drwxrwxr-x 2 emerg wheel 4096 Apr 10 11:51 .ssh/ You're allowing anyone in the group wheel write access to your .ssh directory. This means that any member of that group could replace your authorized_keys file - so SSH refuses to trust the file. Fix your permissions and the problem should go away.


4

If you have multiple ssh keys and already have one set up for authentication on the server or if you have some other non-password authentication system in place, I believe you can use ssh-copy-id to copy a ssh identity to the server. In the ssh-copy-id manual page it says: ssh-copy-id is a script that uses ssh to log into a remote machine ...


4

You can make .tcshrc check a special environment variable (like subuser), and conditionally source .tcshrc_cust. When you log in, run subuser=nozimica tcsh. It will get that enironment variable and execute your custom rc script. In addition, vim's :sh command will work. You can even make it fancy and source .tcshrc_$subuser; that way everyone could do it. ...


4

Have you tried: gpg --export-secret-key That should do it. You might have to give the id of the key you want to export. And maybe also provide --armor if you want it in nice ASCII. You don't need the public key because the public key can always be trivially generated from the private key. Keeping a backup is likely a wise idea. I also tend to generate a ...


4

You probably want to unlock private keys on your server to access different machines from there using these keys. Since these are the same keys as on your local machine, there is an easier way than unlocking those, by using ssh key forwarding. This concept is described here in the section ' Public Key Access with Agent Forwarding'. From the commandline ...



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