Share your knowledge at the LQ Wiki.
Go Back > Forums > Linux Forums > Linux - Newbie
User Name
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!


  Search this Thread
Old 04-17-2015, 05:28 AM   #1
Registered: Feb 2011
Location: Republic Of Ireland
Distribution: Debian,Centos,Slackware
Posts: 485

Rep: Reputation: 29
ssh public and private keys...

hi guys,

i understand the concept of a public and private key for ssh signing and encryption...i just dont get the implementation.

if you have a client and a server and you want two way communication do both have to have each others public keys in the .ssh/authorized_keys files on each respectively?

should you use a password? does it matter if you want to run say rsync from one to the other with a cron job or script?

does anybody just have a breakdown of exactly what you need to do and how it works in different situations...

i found this:

seemed to help...but im still not 100% clear...
Old 04-17-2015, 06:34 AM   #2
Registered: Mar 2015
Location: Cheektowaga, NY
Distribution: ArchLinux
Posts: 34

Rep: Reputation: 7
ssh keys are used thusly:

Client A wants to communicate with server b without having to enter a password. Client A runs ssh-keygen and generates an RSA keypair. The keypair can optionally have a passphrase, which is client-side only (this is important, as its never transmitted over the network - passwords are, leaving them open to MTiM attacks). The generation results in two files:


id_rsa is the private key and stays on client A. is the public key and is distributed to server b as authorized_keys in ${HOME}/.ssh. Only the public key is transmitted to the server.

When an authentication request is made, the generated key is used before all other authentication methods (unless otherwise told), and no user input is required unless the key has a passphrase. If it does, then ssh-agent or a wrapper around ssh is necessary, but that's a little more in-depth than necessary right now.

To run in scripts or via cron, then a passphrase-free key will work unless ssh is wrapped or ssh-agent is used to load the key with earlier intervention.
Old 04-17-2015, 06:36 AM   #3
Registered: Feb 2011
Location: Republic Of Ireland
Distribution: Debian,Centos,Slackware
Posts: 485

Original Poster
Rep: Reputation: 29
Thank you so much for that...kudos!
Old 04-17-2015, 06:41 AM   #4
Senior Member
Registered: Dec 2010
Location: Internet
Distribution: Linux Mint, SLES, CentOS, Red Hat
Posts: 2,385

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
if you have a client and a server and you want two way communication do both have to have each others public keys in the .ssh/authorized_keys files on each respectively?
You can have two public keys or you can have a single key pair depends on how you want to set it up. For example: if I run ssh-keygen on first server it will generate a public and private key pair. Now I can copy this public key in the authorized_keys file of both first and second server. Copy private key as well on the second server so that it can ssh first server using sshkeys.

Distribution of private key is not encouraged as you are compromising the security. Usually private key is help on one machine and public key is copied onto all other machines on which I want to perform key based authentication.

For example: If I have 10 linux boxes in my home. I will create a public and private key pair. Push public key on all linux boxes and keep the private key on only 1 box, that box I can use to ssh all other machine. You can call that host as jumpoff host which has connectivity to all machines via ssh keys.

should you use a password? does it matter if you want to run say rsync from one to the other with a cron job or script?
You can use passphrase for added security. To be honest it is a good idea to use, incase your private key is compromised you will have added layer of passphrase to protect it. Not sure what you said about rsync.

The document link that you shared is good and you can follow it. Let us know what part in that link you are finding confusing.
Old 04-17-2015, 09:32 AM   #5
Registered: Sep 2003
Location: Texas
Distribution: Red Hat/CentOS
Posts: 295
Blog Entries: 4

Rep: Reputation: Disabled
If the machine is connected to the Internet, you'll want to use a passphrase for your SSH keys. Of course, the down side to this is that your cron jobs will need to account for that and you might have to use something like expect (for injecting the password) which would be more insecure. Although not completely secure, you might want to look at using an agent.

----Begin Paste----
The ssh-agent provides another, somewhat less vulnerable method of key storage for batch jobs. A human invokes an agent and loads the needed keys from passphrase-protected key files, just once. Thereafter, unattended jobs use this long-running agent for authentication.

In this case, the keys are still in plaintext but within the memory space of the running agent rather than in a file on disk. As a matter of practical cracking, it is more difficult to extract a data structure from the address space of a running process than to gain illicit access to a file. Also, this solution avoids the problem of an intruder's walking off with a backup tape containing the plaintext key.

Security can still be compromised by overriding filesystem permissions, though. The agent provides access to its services via a Unix-domain socket, which appears as a node in the filesystem. Anyone who can read and write that socket can instruct the agent to sign authentication requests and thus gain use of the keys. But this compromise isn't quite so devastating since the attacker can't get the keys themselves through the agent socket. She merely gains use of the keys for as long as the agent is running and as long as she can maintain her compromise of the host.

The agent method does have a down side: the system can't continue unattended after a reboot. When the host comes up again automatically, the batch jobs won't have their keys until someone shows up to restart the agent and provide the passphrases to load the keys. This is just a cost of the improved security, and you have a pager, right?

Another bit of complication with the agent method is that you must arrange for the batch jobs to find the agent. SSH clients locate an agent via an environment variable pointing to the agent socket, such as SSH_AUTH_SOCK for the SSH1 and OpenSSH agents. [Section, "Single-shell method"] When you start the agent for batch jobs, you need to record its output where the jobs can find it. For instance, if the job is a shell script, you can store the environment values in a file:

$ ssh-agent | head -2 > ~/agent-info
$ cat ~/agent-info
setenv SSH_AUTH_SOCK /tmp/ssh-res/ssh-12327-agent;
setenv SSH_AGENT_PID 12328;

You can add keys to the agent (assuming C shell syntax here):

$ source ~/agent-info
$ ssh-add batch-key
Need passphrase for batch-key (batch job SSH key).
Enter passphrase: **************

then instrument any scripts to set the same values for the environment variables:

# Source the agent-info file to get access to our ssh-agent.
set agent = ~/agent-info
if (-r $agent) then
source $agent
echo "Can't find or read agent file; exiting."
exit 1
# Now use SSH for something...
ssh -q -o 'BatchMode yes' user@remote-server my-job-command

You also need to ensure that the batch jobs (and nobody else!) can read and write the socket. If there's only one uid using the agent, the simplest thing to do is start the agent under that uid (e.g., as root, do su <batch_account> ssh-agent ...). If multiple uids are using the agent, you must adjust the permissions on the socket and its containing directory so that these uids can all access it, perhaps using group permissions.

TIP: Some operating systems behave oddly with respect to permissions on Unix-domain sockets. Some versions of Solaris, for example, completely ignore the modes on a socket, allowing any process at all full access to it. To protect a socket in such situations, set the containing directory to forbid access. For example, if the containing directory is mode 700, only the directory owner may access the socket. (This assumes there's no other shortcut to the socket located elsewhere, such as a hard link.)

Using an agent for automation is more complicated and restrictive than using a plaintext key; however, it is more resistant to attack and doesn't leave the key on disk and tape where it can be stolen. Considering that the agent is still vulnerable to being misused via the filesystem, and that it is intended to run indefinitely, the advantages of this method are debatable. Still, we recommend the agent method as the most secure and flexible strategy for automated SSH usage in a security-conscious environment.
----End Paste----
Old 05-07-2015, 05:11 PM   #6
Registered: Feb 2011
Location: Republic Of Ireland
Distribution: Debian,Centos,Slackware
Posts: 485

Original Poster
Rep: Reputation: 29
thanks very much...interesting stuff!!!

ok so i followed my tutorial and once you get it working its easy enough...
and i fully understand the difference between known_hosts and authorized_keys now!!!

next is ssh-agent...should be fun!!!

thanks guys!!!

Last edited by sigint-ninja; 05-07-2015 at 06:18 PM.


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
how does SSH use public/private Keys tripialos Linux - General 5 01-15-2013 02:51 AM
ssh public/private keys lord_darkhelmet Linux - Newbie 8 10-29-2005 03:14 PM
SSH public / private keys problem guideweb Linux - Software 7 08-27-2005 09:49 PM
How to delete public & private keys for SSH? TrulyTessa Linux - Security 2 11-18-2004 12:27 PM
Help with SSH and public/private keys stodge Linux - Security 5 05-14-2003 01:22 PM > Forums > Linux Forums > Linux - Newbie

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

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration