LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Linux Answers > Networking
Reload this Page Public key authentication with ssh
User Name
Password

Notices


By david_ross at 2003-12-05 14:35
TITLE: Public key authentication with ssh

Introduction
This LinuxAnswer describes how to set up public key authentication with ssh{1}.
It will include all sub components like scp too.
I will refer to the client machine{2} as the "client" and the server machine{3} as "server"


Assumptions
1) You know how to open up a terminal and type a few basic commands.
2) You have a working ssh server and client installed. If not then see:
ftp://ftp.ca.openbsd.org/pub/OpenBSD...rtable/INSTALL


Why would you want to?
There are many reasons so I'll just list a few:
1) You don't need to type your password each time you want to login to a remote system. This can protect against malicious applications such as keyloggers
2) You can run automated maintenance tasks/checks on other machines.
3) You can run secure backups over ssh using rsync. See LinuxAnswer Using rsync to mirror data between servers


The real howto
1) Create the private{4} and public{5} keys:
ssh-keygen -t dsa
You will be prompted for a key location, the default is fine so just press enter.
Then you are asked to enter a passphrase. From man ssh-keygen:
Quote:
The program also asks for a passphrase. The passphrase may be empty to indicate no passphrase (host keys must have an empty passphrase), or it may be a string of arbitrary length. A passphrase is similar to a password, except it can be a phrase with a series of words, punctuation, numbers, whitespace, or any string of characters you want. Good passphrases are 10-30 characters long, are not simple sentences or otherwise easily guessable (English prose has only 1-2 bits of entropy per character, and provides very bad passphrases), and contain a mix of upper and lowercase letters, numbers, and non alphanumeric characters.
If you are intending to set up automated tasks that will use this key it is probably best not to supply a passphrase although it will inevitably be less secure{6}.
2) Copy the public key to the server (you will need to enter the password):
cat ~/.ssh/id_dsa.pub | ssh user@server "cat - >> ~/.ssh/authorized_keys"
3) That's it, to test it just ssh to the other server and you shouldn't need a password. If you entered a passphrase then you need will need to enter it when prompted:
ssh user@server

If it doesn't work then please look at the troubleshooting section below.
Answers to most questions should be there.
If you still have problems then search the LQ forums and if you still have a problem start a new thread.


Using ssh-agent to store passphrases
If you decided to use a passphrase then you need only enter it once per session using ssh-agent and ssh-add.
1) The parent shell process in which you work should be started by ssh-agent - ie:
ssh-agent /bin/bash
2) Then to store your passphrase for that session run:
ssh-add
Enter your passphrase when prompted
3) Thats it, to test it just ssh to the other server and you shouldn't need a password or passphrase:
ssh user@server

If you use a desktop environment or window manager you can start it in the same way as a the bash shell was above with ssh-agent so that any child processes (terminals etc) also have access to your passphrase.


Troubleshooting
If you get a connection refused message
You probably have a server problem, check sshd is running "netstat -nlp" and there is no firewall rule in place blocking port 22 "iptables -nL".

You still get prompted for a password
Try to ssh to the server with verbose output:
ssh -vv user@server
If you get a line like this, not containing "publickey":
debug1: Authentications that can continue: password,keyboard-interactive
Then check sshd_config on the server and remove the line "PubkeyAuthentication no" if it exists then restart sshd.
If you don't get a line like:
debug1: try pubkey: /home/rossy/.ssh/id_dsa
Then check "ssh_config" on the client and if it exists, remove "PubkeyAuthentication no" if it exists.
If you still don't see that line then make sure that "~/.ssh/id_dsa" exists on the client.
If you get a line like:
debug2: we sent a publickey packet, wait for reply
Check that "~/.ssh/authorized_keys" exists on the server and contains a line the same as "~/.ssh/id_dsa.pub" on the client.


A small bit about the jargon
{1} ssh stands for Secure SHell on a basic level it is like telnet but has many other differences the main one being encryption.
{2} Client the client is the machine that initiates the connection.
{3} Server the server is the machine that listens for incoming connections.
{4} Private keys are stored on the client.
{5} Public keys are stored on the server.
{6} Less secure if the client is compromised so is access to the server

‹ PPTP VPN on Slackware How-toupquick and easy way to get internet connection sharing ›

by teacup on Mon, 2003-12-22 02:06
I followed the instructions and I still get prompted for a password.

Code:
pcurry@lisacomp:~/.ssh$ ssh -vv teacup
OpenSSH_3.6.1p2 Debian 1:3.6.1p2-10, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /home/pcurry/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to teacup [192.168.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/pcurry/.ssh/identity type -1
debug1: identity file /home/pcurry/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/pcurry/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-10
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 124/256
debug2: bits set: 1582/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'teacup' is known and matches the RSA host key.
debug1: Found key in /home/pcurry/.ssh/known_hosts:2
debug2: bits set: 1539/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pcurry/.ssh/identity
debug1: Trying private key: /home/pcurry/.ssh/id_rsa
debug1: Offering public key: /home/pcurry/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
pcurry@teacup's password:
Code:
]Check that "~/.ssh/authorized_keys" exists on the server and contains a line the same as "~/.ssh/id_dsa.pub" on the client.
They are the same.
I can ssh without a password from slackware to debian, but I cannot do it from debian to slackware.

by blanny on Thu, 2004-01-22 03:10
Thank you for the tutorial. I found it extremely useful.

by yoowin on Thu, 2004-06-10 01:17
A ssh login to B, it was successful.
B ssh login to A, secure connection refused.

By allowing/enabling port 22, what else could be blocking the SSH login?

by legolin on Sat, 2004-06-19 16:22
i have the same problem as yoowlin,

from fedora to debian i can login without a password, but from debian to fedora it ask for pasrword... my ssh --v host ist the same as the one posted here...


thanks


leg

by yoowin on Tue, 2004-06-22 01:19
Apologize for any inconvinience caused.
I have posted twice the same issue, the thread is continued from here:
http://www.linuxquestions.org/questi...threadid=51930

by legolin on Tue, 2004-06-22 01:31
now i have solve the problem. i jusst used rsa and renamed the file ~/.ssh/id_rsa.pub (or ~/.ssh/id_dsa.pub) in ~/.ssh/identity.pub and the file ~/.ssh/id_rsa in ~/.ssh/identity

now it works...

what is the difference between rsa and dsa? is dsa more secure?

thankx a lot for the discussion,


leg

by jgruss on Wed, 2004-07-07 09:18
I am using ssh from my ibook to connect to my Fedora 2 box on my home network. i am able to connect using the password but i cant get the keys to work. i having been trying to get this to work for more than 4 or 5 days now. Any help would be greatly appreciated. I would really like to get this working please help.

jason

by gointomexico on Thu, 2004-09-30 00:19
I had to do this for a class project. I found this information extreemly infomrative, and helpful, thanks!

I had the same problem trying to get mine to work. I did a chmod on the server: <chmod 600 authorized_keys>
and then it started working. no password required!

hope this helps.

P.S. This was a debian to debian connection following the steps outlined in the guide.

by Donboy on Sat, 2005-01-08 16:24
I'm trying to use Putty on Windows to access my remote machines. How can I get this working? How can I present my public key (on Windows) to the remote server so it can check the key? I've been reading elsewhere how people are using the private key under the "Auth" section of Putty, but mine's not working. The screen blanks out before I can see what the error was.

by Donboy on Sat, 2005-01-08 16:53
Nevermind... I got it. All I had to do was open the private key in PuttyGen and save it in Putty's own format. After that, it worked fine.


  



All times are GMT -5. The time now is 10:52 PM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration