LinuxQuestions.org
Help answer threads with 0 replies.
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 05-01-2015, 10:19 AM   #1
wingman358
Member
 
Registered: Mar 2008
Location: Northeast US
Distribution: Mint, Ubuntu, Backtrack
Posts: 77

Rep: Reputation: 16
Question SSH / Asymmetric Key Cryptography Basics


Hi all, I'm a little bit confused about asymmetric key cryptography, particularly the use of RSA keys with SSH.

I have used ssh keys successfully in the past, but only after much headache and not much understanding. My comprehension is this: there is a public and private key, which when combined, allow a user to login.

My question is essentially which key goes where?

I have tried reading several posts and articles online, but they are mostly way above my head and the jargon does not make sense to me. I believe the private key is carried with the user, as in a "license" or fingerprint that is individually owned by a user. I think the public key stays on the remote server (the machine that is connected to during ssh 168.x.x.x ??), and the private key is on the local machine from which you are initiating the ssh session.

If that is true, then how does the private key stay private? Doesn't that schema mean the private key is transmitted over the network to the remote server, to be checked against the public key and accepted/rejected? or is the public key transmitted by the remote server to the local machine? In that case, how can the remote machine verify the local machine is authorized to connect?

I am sure I am missing something simple here.
 
Old 05-01-2015, 10:41 AM   #2
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,294
Blog Entries: 3

Rep: Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719
The public key goes onto the remote server you are going to connect to.

The private key stays on the local client you are going to connect from.

During authentication, the actual private key never leaves the client. Instead, the client takes some identifying session data and signs it with the private key. The server then checks using the public key to see if the signature is valid.
 
Old 05-01-2015, 10:46 AM   #3
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 4,138

Rep: Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263Reputation: 1263
The keys never need to be combined. The private key stays only readable and usable by you. The public key may be given to anyone to whom you need to prove your identity. The way it works is that nobody without the private key can sign a message that the public key will verify.
 
Old 05-01-2015, 12:47 PM   #4
wingman358
Member
 
Registered: Mar 2008
Location: Northeast US
Distribution: Mint, Ubuntu, Backtrack
Posts: 77

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by Turbocapitalist View Post
The public key goes onto the remote server you are going to connect to.

The private key stays on the local client you are going to connect from.

During authentication, the actual private key never leaves the client. Instead, the client takes some identifying session data and signs it with the private key. The server then checks using the public key to see if the signature is valid.
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
 
Old 05-01-2015, 08:25 PM   #5
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
Quote:
Originally Posted by wingman358 View Post
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
I think this has what you are looking for (under the section "Asymmetrical Encryption")

https://www.digitalocean.com/communi...ection-process

and (harder to read, but the section '7 Public Key Authentication Method: "publickey"'
https://www.ietf.org/rfc/rfc4252.txt

Last edited by jpollard; 05-01-2015 at 08:31 PM.
 
Old 05-01-2015, 09:49 PM   #6
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Just FYI, the asymmetric encryption and signing keys are two different keys, they have to be because using a key for both gives away info about it.

A signature scheme is basically a MAC with non-repudiation. It basically hashes the message using a hash function and then applies a keyed asymmetric signing transform (decryption). Whoever receives the message and the signature can check it by encrypting the signature and checking the hash.

As said above, think of the public key as a lock (only for encryption) and the private key as a key (only for decryption).
 
Old 05-02-2015, 03:31 AM   #7
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,294
Blog Entries: 3

Rep: Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719
Quote:
Originally Posted by wingman358 View Post
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
The signature verification comes after the encrypted connection between the machines is already established. So no clear text is transmitted. Here's a description of the SSH connection process (if the link works)
http://www.linuxjournal.com/article/9566

For key-based authentication, the server has a priori the public part of the public/private key pair. In other words, that type of authentication cannot take place if the keys are not already in place first. Then if a private key was used to sign something then the matching public key, and only the matching public key, works to verify the signature (public key cryptography).
 
Old 05-02-2015, 11:01 AM   #8
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,780

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by Turbocapitalist View Post
The signature verification comes after the encrypted connection between the machines is already established. So no clear text is transmitted. Here's a description of the SSH connection process (if the link works)
http://www.linuxjournal.com/article/9566
This is incorrect according to the article: the signature verification is used to establish the encryption keys in the first place, so the signature itself can't be encrypted.

Quote:
We know how to compute the individual encryption and MAC keys provided that we derive the basic parameters using the simple equation above. But, how do we get the parameters to begin with, in a secure, authenticated manner?

...we use a known and trusted server public key to authenticate key exchanges. Authentication of key exchange data is nothing more than signing with a private key. And, OpenSSH typically uses ssh-dsa or ssh-rsa keys for this purpose.
However, reading a signature will not reveal the private key (provided the thing signed was correctly padded), so encryption is not needed.
 
Old 05-02-2015, 12:18 PM   #9
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,294
Blog Entries: 3

Rep: Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719Reputation: 3719
Quote:
We know how to compute the individual encryption and MAC keys provided that we derive the basic parameters using the simple equation above. But, how do we get the parameters to begin with, in a secure, authenticated manner?

...we use a known and trusted server public key to authenticate key exchanges. Authentication of key exchange data is nothing more than signing with a private key. And, OpenSSH typically uses ssh-dsa or ssh-rsa keys for this purpose.
My reading of that is rather than the user's key it would be the server's key, the one(s) in /etc/ssh/, where the initial connection is established before authentication. However, I've not studied the transport layer protocol at all.
 
Old 05-02-2015, 12:54 PM   #10
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912

Rep: Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513Reputation: 1513
According to RFC 4251 (https://www.ietf.org/rfc/rfc4251.txt) section 9.4,

Quote:
The purpose of this protocol is to perform client user
authentication. It assumes that this runs over a secure transport
layer protocol, which has already authenticated the server machine,
established an encrypted communications channel, and computed a
unique session identifier for this session.
So user authentication is done AFTER the encrypted session is set up.
 
  


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
Does public key cryptography encrypt data in both directions with SSH? wulp Linux - Security 3 02-28-2012 09:05 AM
Can someone logically explain public/private key asymmetric encryption? abefroman Linux - Security 6 09-02-2009 06:52 AM
asymmetric key cryptography leedude General 7 09-19-2008 08:12 AM
LXer: OpenSSH with Public Key Cryptography Tutorial LXer Syndicated Linux News 0 10-13-2006 08:03 AM
Can someone explain the basics of private-key authentication through SSH? lowpro2k3 Linux - Security 2 06-08-2005 11:22 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

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

Main Menu
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