Hot answers tagged key-authentication
27
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 ...
19
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 ...
10
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.
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 ...
8
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 ...
7
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
7
Set StrictHostKeyCheking 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 via ssh -o StrictHostKeyChecking=no -l $user $host.
Here's an explanation of how this works from ...
7
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 ...
6
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 ...
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
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 ...
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
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 ...
5
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 ...
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
...
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
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.
4
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.
4
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 ...
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 ...
3
You may have just copied the key incorrectly. Try this:
On Server B(as mike): rm ~/.ssh/authorized_keys
On Server A(as john): ssh-copy-id -i /path/to/id_dsa.pub mike@serverb
The ssh-copy-id command basically connects to the remote host (using password auth) and then edits authorized_keys appropriately. I believe it is distributed with OpenSSH, if you ...
3
If public key authentication doesn't work: make sure that on the server side, your home directory (~), the ~/.ssh directory, and the ~/.ssh/authorized_keys file, are all writable only by their owner. In particular, none of them must be writable by the group (even if the user is alone in the group). chmod 755 or chmod 700 is ok, chmod 770 is not.
What to ...
3
It turns out that the key that didn't work wasn't configured properly in the authorized_keys file after all. Sorry about that...
I wrongly assumed that ssh -i /home/user1/.ssh/id_rsa user1@myserver was an indication that it was configured properly, but this turns out not to be the case. It makes use of other keys too. Forcing ssh -i /home/user1/.ssh/id_rsa ...
2
Yes, you can have a different keypair for each account; just mind the options when you run ssh-keygen and specify different identity files for them.
If your local computer is acceptably secure and you don't want to continuously re-enter your key password, ssh-agent might be worth looking into as well.
2
Do you have access to the SSH logs on ServerB? If not, can the admin send the relevant lines to you?
On ServerB, the permissions for make sure that you have the correct permissions as described in the SSH manpage:
~/.ssh/
This directory is the default location for all user-specific con‐
figuration and authentication information. There ...
2
For convenience, the optimal method is a combination of the answers of jmtd and Faheem.
Using ssh-agent alone means that a new instance of ssh-agent needs to be created for every new terminal you open. keychain when initialized will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have ...
Only top voted, non community-wiki answers of a minimum length are eligible
