LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-27-2011, 05:59 AM   #1
vahab
Member
 
Registered: Jun 2011
Posts: 56

Rep: Reputation: Disabled
SSH Public/Private Key Authentication Concepts


Hi,

I have some problem understanding steps involving a SSH public/private key authentication and I am looking for an article which describes the steps clearly.

Before, I had thought that SSH client, offers its public key to SSH server and ... but recently I have found that I am wrong because by deleting for example id_dsa.pub ,the authentication is done without any problem so it shows that the authentication depends on private key and not public key !

Can you please help in this regard.

Thanks

Last edited by vahab; 12-27-2011 at 06:06 AM.
 
Old 12-27-2011, 07:05 AM   #2
lithos
Senior Member
 
Registered: Jan 2010
Location: SI : 45.9531, 15.4894
Distribution: CentOS, OpenNA/Trustix, testing desktop openSuse 12.1 /Cinnamon/KDE4.8
Posts: 1,144

Rep: Reputation: 217Reputation: 217Reputation: 217
Hi,

It depends how your SSH server is configured to use SSH protocols (1,2) and keys.

Much help can be found on google

however DSA key is somehow related with SSH protocol 1 and not protocol 2 (which is recommended use nowadays)

Here is a SSH authentication protocol - RFC 4252 explained (I think) as you may wish.

good luck.
 
1 members found this post helpful.
Old 12-27-2011, 08:12 AM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,033

Rep: Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755
It's actually pretty straightforward; keep in mind that SSH is user oriented, not server oriented (well, mostly) for our purposes.

What you do is log in and execute ssh-keygen. That creates a directory in your home directory named .ssh and generates two files in that directory: id_rsa and id_rsa.pub, the private and public keys. You would repeat this for every user account that needs to have SSH access between machines (you do notcopy these keys from one account to another, you generate unique keys for each account).

When you execute ssh-keygen you will be prompted for a pass phrase, just hit the return key for the pass phrase and the "enter it again" prompts (this is not a security hole, it just makes your life a little easier). Try not to confuse the pass phrase with the account password as we go alone here -- they're not the same.

That will allow an external user to connect with SSH and log in as the user you generated the keys for (using the password for the account); generally, SSH is used by a user to connect to his or her own account remotely.

There are some tricks you can do, one of them being remote log in without a password (this is the real benefit of secure log in with the public and private keys).

Those two files? One of them, id_rsa.pub, can be copied to another server and allow password-less connection (you never copy the private key anywhere, only the public key).

Let's say you've got two servers, fubar and snafu that you wish to allow password-less connections for one or more users on. Let's say that the user is you and your log in on both machines is john and you have already generated the publich and private keys on each machine using ssh-keygen. So, you log in on fubar and do this:
Code:
fubar: cd .ssh
fubar: cp id_rsa.pub fubar
fubar: ssh snafu
<enter snafu's password>
snafu: cd .ssh
snafu: cp id_rsa.pub snafu
snafu: ^D (or exit)
fubar:
What you've done is create a file on each machine, named the machine name, containing the public key; you're going to copy those files to the other machine:
Code:
fubar: pwd       < make sure you're still in the .ssh directory)
fubar: sftp snafu
<enter password>
cd .ssh
get snafu
quit
fubar: cp snafu authorized_keys
What you've done is, from fubar, connected to snafu and copied the file you created above containing the public key and copied that public key into the file authorized_keys in the .ssh directory. Now you might see the reason for naming the public key files something other than id_rsa.pub so you can conveniently copy them to another server and not overwrite the existing id_rsa.pub file there -- think about doing this on five or six machines and you may get the idea.

OK, so now snafu can connect to fubar and you need to do the same thing in the other directory; assuming you're still on fubar,
Code:
ssh snafu
<enter password>
cd .ssh
sftp fubar
cd .ssh
get fubar
quit
cp fubar authorized_keys
exit
You've copied the public key file from fuabr to snafu and copied that into authorized_keys.

Now they can talk to each other without a password.

The next thing you want to do is create a file named config in the .ssh directories on each machine. On fubar, it will look like this:
Code:
Host snafu
ForwardAgent yes
ForwardX11 yes
Compression yes
Protocol 2,1
User john

Host *
ForwardX11 no
Do the same thing on snafu, changing the Host to fubar.

Once you've done all this, you can connect to either machine without a password. For example, if you're working on snafu, you can simply
Code:
ssh fubar
and you're connected (and vice versa).

If you have a bunch of servers that you need to work on, simply repeat the above stuff for each one. The line in config for the user account name permits you to have different accounts on other servers that may connect without a password -- pretty slick, that.

Now there is an excellent article that will explain much of the above (plus some other interesting things), see http://www.linuxjournal.com/article/6602. It's an oldie but a goodie.

Hope this helps some.
 
2 members found this post helpful.
Old 12-27-2011, 02:17 PM   #4
vahab
Member
 
Registered: Jun 2011
Posts: 56

Original Poster
Rep: Reputation: Disabled
Smile

Thank you guys, maybe I asked the question wrongly because of my bad English . I do know the how-to-implement-publickey-authentication and I have done it so many times, but I do not know exactly what is happening in backgroud.

I studied : http://tools.ietf.org/html/rfc4252

I found out that client sends a signature using its private key as follows (As the document says ):

The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:

string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication


So my question is : Is client sending its public key within the signature ?

I guess it is not ! Because after deleting public key file from client it still works.

I guess it is sending only the "publickey" string (English phrase of public key !) encrypted using its private key. Then server tries to decrypt this string using public keys in its authorized_keys file (containing the line that matches server name string) and if the decrypted string is equal to "publickey" then the authentication is successful.

Please correct me if I am wrong and many thanks for your answers.
 
Old 12-27-2011, 03:38 PM   #5
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 518

Rep: Reputation: 51
if you are using keys for auth then the authentication side (ssh server) must have the allowed users public key placed into a special directory/file by the admin. when the user tries to authenticate the server checks if user's public key is listed, and if so the server will then challenge the user to see if the user does in fact hold the private key that matches the presented public key. if the challenge fails the server denies access, if the challenge passes then the server allows access.

is that what you were asking, or do you also want low level step-by-step key exchange and challenge/response tasks??

an no, client does not encrypt its public key with its private key and then server decrypts that. i think what you are describing in post #4 is the challenge phase after the client had presented public key for auth.

Last edited by Linux_Kidd; 12-27-2011 at 03:42 PM.
 
Old 12-27-2011, 11:55 PM   #6
vahab
Member
 
Registered: Jun 2011
Posts: 56

Original Poster
Rep: Reputation: Disabled
Yes I am looking for low level step-by-step key exchange and challenge/response tasks
 
Old 12-28-2011, 04:56 AM   #7
ssilayaraja
Member
 
Registered: Aug 2003
Location: chennai
Posts: 115

Rep: Reputation: 15
have a look in the url
http://www.cyberciti.biz/tips/ssh-pu...on-how-to.html
 
Old 12-28-2011, 05:09 AM   #8
Reuti
Senior Member
 
Registered: Dec 2004
Location: Marburg, Germany
Distribution: openSUSE 11.4
Posts: 1,319

Rep: Reputation: 252Reputation: 252Reputation: 252
At this webpage at the end is a brief explanation “How Key Challenges Work” work, but it’s the concept, not low level.

And yes: you can delete the public key on the machine where you created the keypair, as it’s only used on the side where you connect to. There is also the option ssh-keygen -y to recreate the public key out of the private key in case you deleted it by accident and don’t want to create a new keypair.
 
1 members found this post helpful.
Old 12-28-2011, 07:23 AM   #9
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,033

Rep: Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755Reputation: 755
Maybe this will help, maybe not -- when you first connect to a remote machine with SSH you are asked to enter the password for the user you are attempting to log in as. If that is successful, you are asked if you want to add the foreign machine to your known hosts file (in the ~/.ssh directory); that's the initial recognition between the two, the remote knows who you are and you know who the remote is.

This is, in a way, similar to caller ID on your telephone -- somebody calls, you see who it is (or isn't) and you decide whether or not to answer. Those that hide their identity are the ones you don't want to bother with, say.

In your ~/.ssh directory, you can look at the files with an editor (or simply cat them -- it's all gobbledigook (meaningless, encrypted), but you can see the log in account name and other identification strings that are used by SSH to authenticate both ends. Unless you copy the public keys between the two machines (and store them in the ~/.ssh/authorized_keys file on both machines as described above) you will always be asked for the user account password when you connect to the remote (and vice versa). The use of a pass phrase when generating the keys with ssh-keygen is an additional layer of security on top of the user account password.

The web page suggested by Reuti is a pretty good explanation of the steps involved. Just keep in mind that you're going there and it's up to "there" whether to answer your "call" and how much authentication to require.

Hope this helps some.
 
Old 12-28-2011, 08:05 AM   #10
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 518

Rep: Reputation: 51
Quote:
Originally Posted by Reuti View Post
At this webpage at the end is a brief explanation “How Key Challenges Work” work, but it’s the concept, not low level.

And yes: you can delete the public key on the machine where you created the keypair, as it’s only used on the side where you connect to. There is also the option ssh-keygen -y to recreate the public key out of the private key in case you deleted it by accident and don’t want to create a new keypair.
i dont think this is true. the public key is presented to the remote server as an authentication piece. if as stated in an earlier post that the client side had deleted the actual public key yet auth still works it is likely because the public key was wrapped up into a certificate and its the certificate that is being sent to the remote server. remote server then validates whether it allows that public key, and if so the public-private key challenge is invoked. a public key (in one form or another, but typically via a cert) has to be presented to the remote server as it is not a scalable solution to do public-private key challenge for every public key stored on remote server. if the public key and cert are deleted from the client then auth should fail.

i guess its possible for a sshd server to not require a public key during initial auth, rather just a UID, server then checks if the UID exists and has a public key mapping, then the server invokes the key challenge. but from what i have seen the client typically follows the steps below.

i dont have debug output to show which files/processes are being touched/invoked, but these are the steps:
  1. ssh client connects to sshd server
  2. some ssh handshakes occur
  3. ssh client presents UID along with cert (public key)
  4. sshd server checks to see if UID is valid and if client public key is allowed
  5. sshd then uses client public key to sign/encrypt random challenge string and sends it back to client
  6. client decrypts the challenge and then encrypts it using server's public key, sends back to server
  7. server decrypts the reposnse to verifies the response was indeed the same as the original challenge string
the challenge response can only be valid if the client has a valid public-private key pair.

the key challenge is essentially the password, but the client or user doesnt have to remeber a password, etc. but of course pros and cons to everything. a password can be used anywhere, a challenged key means the client(machine,usb token,whatever) must have the private key, and if the private key itself is only accessible by a passphrase then the user must enter the passphrase to unlock the private key either prior to starting ssh session or during the challenge phase, etc.

Last edited by Linux_Kidd; 12-28-2011 at 08:49 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Query related to ssh private-public key authentication saagar Linux - Newbie 3 03-23-2010 10:59 AM
Private/Public key vs. Password authentication w/ SSH MykeV Linux - Security 5 11-25-2007 11:49 AM
SSH public / private key authentication problems thronh Linux - Security 7 06-14-2006 11:21 AM
SSH public/private key authentication with GnuPG keys? thinksincode Linux - Security 1 02-25-2005 02:33 PM
public/private key authentication with PuTTY NetAX Linux - Security 5 10-27-2004 06:00 PM


All times are GMT -5. The time now is 12:50 PM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration