The key you need to transfer to the host is the public one. If you can log in to a computer over SSH using a password, you can transfer your RSA key by doing the following from your own computer:
ssh-copy-id <username>@<host>
Where <username> and <host> should be replaced by your username and the name of the computer you're transferring your key to.
Due to this bug, you cannot specify a port other than the standard port 22. You can work around this by issuing the command like this: ssh-copy-id "<username>@<host> -p <port_nr>". If you are using the standard port 22, you can ignore this tip.
You can make sure this worked by doing:
ssh <username>@<host>
You should be prompted for the passphrase for your key:
Enter passphrase for key '/home/<user>/.ssh/id_rsa': |
Enter your passphrase, and provided host is configured to allow key-based logins, you should then be logged in as usual.
Troubleshooting
Encrypted Home Directory
If you have an encrypted home directory, SSH cannot access your authorized_keys file because it is inside your encrypted home directory and won't be available until after you are authenticated. Therefore, SSH will default to password authentication.
To solve this, create a folder outside your home named /etc/ssh/<username> (replace "<username>" with your actual username). This directory should have 755 permissions and be owned by the user. Move the authorized_keys file into it. Theauthorized_keys file should have 644 premissions and be owned by the user.
Then edit your /etc/ssh/sshd_config and add:
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
Finally, restart ssh with:
sudo service ssh restart
The next time you connect with SSH you should not have to enter your password.
username@host's password:
If you are not prompted for the passphrase, and instead get just the
username@host's password: |
prompt as usual with password logins, then read on. There are a few things which could prevent this from working as easily as demonstrated above. On default Ubuntu installs however, the above examples should work. If not, then check the following condition, as it is the most frequent cause:
On the host computer, ensure that the /etc/ssh/sshd_config contains the following lines, and that they are uncommented;
PubkeyAuthentication yes RSAAuthentication yes
If not, add them, or uncomment them, restart OpenSSH, and try logging in again. If you get the passphrase prompt now, then congratulations, you're logging in with a key!
Permission denied (publickey)
If you're sure you've correctly configured sshd_config, copied your ID, and have your private key in the .ssh directory, and still getting this error:
Permission denied (publickey). |
Chances are, your /home/<user> or ~/.ssh/authorized_keys permissions are too open by OpenSSH standards. You can get rid of this problem by issuing the following commands:
chmod go-w ~/ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Debugging and sorting out further problems
The permissions of files and folders is crucial to this working. You can get debugging information from both the client and server.
if you think you have set it up correctly , yet still get asked for the password, try starting the server with debugging output to the terminal.
sudo /usr/sbin/sshd -d
To connect and send information to the client terminal
ssh -v ( or -vv) username@host's
Where to From Here?
No matter how your public key was generated, you can add it to your Ubuntu system by opening the file .ssh/authorized_keys in your favourite text editor and adding the key to the bottom of the file. You can also limit the SSH features that the key can use, such as disallowing port-forwarding or only allowing a specific command to be run. This is done by adding "options" before the SSH key, on the same line in the authorized_keys file. For example, if you maintain a CVS repository, you could add a line like this:
command="/usr/bin/cvs server",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc ssh-dss <string of nonsense>...
When the user with the specified key logged in, the server would automatically run /usr/bin/cvs server, ignoring any requests from the client to run another command such as a shell
submitted by guest blogger
elena martins, Brazil
Retweet this story
submitted by guest blogger
elena martins, Brazil
No comments:
Post a Comment