Difference between revisions of "Using keys"

From Freephile Wiki
Jump to navigation Jump to search
VisualWikitext
(references better external article)
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
[[Image:Application-pgp-keys.svg|right|128px|Security]]
 
−
 
−
 
 
There are a lot of things you can do with computers to create security, that's why '''Security is a process, not a product'''.  One such thing is to use SSH Keys to authenticate with a remote host, rather than typing in your password all the time.  Of course, using SSH Authentication keys is convenient as well.
 
There are a lot of things you can do with computers to create security, that's why '''Security is a process, not a product'''.  One such thing is to use SSH Keys to authenticate with a remote host, rather than typing in your password all the time.  Of course, using SSH Authentication keys is convenient as well.
  
 
{{Messagebox
 
{{Messagebox
 
| type = success
 
| type = success
−
| text = Visit http://sial.org/howto/openssh/publickey-auth/ or http://www.unixwiz.net/techtips/ssh-agent-forwarding.html for a better and more in-depth look at using SSH keys and SSH agent}}
+
| text = Visit http://www.noah.org/wiki/SSH_public_keys for a better and more in-depth look at using SSH keys}}
−
 
 
−
Also, another good HOWTO can be found at http://www.debuntu.org/ssh-key-based-authentication
 
  
 
== Secure Shell Key Authentication ==
 
== Secure Shell Key Authentication ==
 
Setting up SSH Key Authentication allows a user account to connect from one server to another without requiring a password login.  This can be utilized for applications (e.g. Nagios monitoring other servers), as well as for publish scripts that move files around servers as well as individual users.
 
Setting up SSH Key Authentication allows a user account to connect from one server to another without requiring a password login.  This can be utilized for applications (e.g. Nagios monitoring other servers), as well as for publish scripts that move files around servers as well as individual users.
−
 
−
== SSH Agent ==
 
−
The SSH Agent is a program that holds your keys in memory so that it can present them automatically for you when connecting to remote hosts.  Assume you are connecting from host A through B to host C. If agent forwarding is allowed by the intermediary host, then your private keys can be used to connect to host 'C' without revealing the private key to host 'B'.  Even if you are connecting directly to a remote host, the agent can store the right keys (assuming that you use more than one.)
 
−
 
−
<source lang="bash">
 
−
eval $(ssh-agent) && ssh-add ~/.ssh/eQualityTech-Test.pem
 
−
</source>
 
−
 
−
== Desktop Applications ==
 
−
Graphical desktop tools such as [http://projects.gnome.org/seahorse/ Seahorse] or [http://utils.kde.org/projects/kgpg/ KGpg] can make this simpler for users, but it's worth understanding the command-line instructions for greater utility.  The added features of a desktop encryption tool is that they allow you to encrypt files in your file manager via a simple right-click menu.
 
−
 
−
Assuming you have generated a key, you can use Seahorse to "configure key for Secure Shell" with a simple right-click.
 
  
 
== Procedure ==
 
== Procedure ==
Line 29: Line 12:
 
## <code>sudo su ''user''</code>
 
## <code>sudo su ''user''</code>
 
# Ensure the user has a <code>~/.ssh/</code> directory with appropriate permissions.  It must allow the user access for RWX, and group and other permissions must not be writable.  Typically, 755 is a good setup.  If they don't have one, then <source lang="bash">mkdir ~/.ssh/ && chmod 755 ~/.ssh</source> Note that the actual identity files should NOT be readable by anyone but the user because <code>ssh-add</code> ignores identity files if they are accessible by others.  That means files like id_rsa should be 600 and id_rsa.pub should be 644
 
# Ensure the user has a <code>~/.ssh/</code> directory with appropriate permissions.  It must allow the user access for RWX, and group and other permissions must not be writable.  Typically, 755 is a good setup.  If they don't have one, then <source lang="bash">mkdir ~/.ssh/ && chmod 755 ~/.ssh</source> Note that the actual identity files should NOT be readable by anyone but the user because <code>ssh-add</code> ignores identity files if they are accessible by others.  That means files like id_rsa should be 600 and id_rsa.pub should be 644
−
# Create a new private/public key pairing for the user. Type: RSA, Bits: 1024, File:~/.ssh/identity[.pub]
+
# Create a new private/public key pairing for the user. Type: RSA, Bits: 1024, File:~/.svn/identity[.pub]
 
## <source lang="bash">ssh-keygen -t rsa -b 1024 -f ~/.ssh/identity</source>
 
## <source lang="bash">ssh-keygen -t rsa -b 1024 -f ~/.ssh/identity</source>
 
# Copy the contents of ~/.ssh/identity.pub so you can paste it in a file on the remote server.
 
# Copy the contents of ~/.ssh/identity.pub so you can paste it in a file on the remote server.
Line 37: Line 20:
 
## Paste the public key from step 4 above into this file, on one line only.
 
## Paste the public key from step 4 above into this file, on one line only.
 
# Try logging in from the first server to the second without using a password.
 
# Try logging in from the first server to the second without using a password.
−
 
−
== One-liner ==
 
−
<source lang="bash">
 
−
ssh-copy-id -i ~/.ssh/id_rsa.pub -o IdentitiesOnly=true admin@qbucket
 
−
# ssh-copy-id is essentially equivalent to
 
−
cat ~/.ssh/id_rsa.pub | ssh admin@qbucket "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"
 
−
# now you can just ssh, and your key will let you in
 
−
ssh admin@qbucket
 
−
# if not, check file permissions (tail /var/log/secure to see if there is a different problem, or ssh -vvv for maximum verbosity)
 
−
chmod 600 ~/.ssh/authorized_keys
 
−
</source>
 
−
 
−
== Man in the Middle (JumpHost or Firewall) ==
 
−
In Maine they would say, "[https://www.youtube.com/watch?v=gD3cYh5Pp1I You ''can'' get there from here!]"
 
−
 
−
Sometimes you have to hop through a hoop before you can get to your destination host.  In case you have to go from A through B to get to C, (A ==> B ==> C) here's how <ref> https://serverfault.com/questions/337274/ssh-from-a-through-b-to-c-using-private-key-on-b </ref>
 
−
<source lang="bash">
 
−
ssh -t B ssh C
 
−
</source>
 
−
To use a key stored on B.
 
−
<source lang="bash">
 
−
ssh -t B ssh -i ~/.ssh/id_rsa C
 
−
</source>
 
−
<code>-t</code> forces pseudo-tty allocation instead of a login shell. <code>-i</code> is the identity found on B
 
−
 
−
If the hoop is a configured to drop your connections after short time-outs, then you can insert a keep-alive on B so that it rings the bell every 60 seconds.
 
−
<source lang="bash">
 
−
# B:/~/.ssh/config
 
−
# keep ssh connections open
 
−
ServerAliveInterval 60
 
−
</source>
 
−
 
−
Since there are more ways than one to do something, you might also try the <code>ProxyCommand</code> option; If <code>-W</code> is not supported in your version of SSH, then your proxy command will need to use netcat.
 
−
<source lang="bash">
 
−
ssh -o ProxyCommand="ssh -W %h:%p firewall.example.org" server2.example.org
 
−
ssh -o ProxyCommand="nc %h:%p firewall.example.org" server2.example.org
 
−
</source>
 
−
== More ==
 
−
More configuration info is on the [[SSH]] page
 
  
 
== Troubleshooting ==
 
== Troubleshooting ==
−
Check <code>/var/log/auth.log</code> (or <code>/var/log/audit/audit.log</code> on RHEL/CentOS) on the remote server for details if this doesn't work as expected.
+
Check <code>/var/log/auth.log</code> on the remote server for details if this doesn't work as expected.
−
 
 
−
When logging in to the server, use the verbosity switch on the ssh command.  Increase verbosity with additional "v"s
 
−
<source lang="bash">
 
−
ssh -vvv me@example.com
 
−
</source>
 
  
 
If you want to check what version of SSH is running on a server, you could do this with telnet (although the ssh client will also tell you this information):
 
If you want to check what version of SSH is running on a server, you could do this with telnet (although the ssh client will also tell you this information):

Revision as of 16:21, 20 January 2009

There are a lot of things you can do with computers to create security, that's why Security is a process, not a product. One such thing is to use SSH Keys to authenticate with a remote host, rather than typing in your password all the time. Of course, using SSH Authentication keys is convenient as well.

Visit http://www.noah.org/wiki/SSH_public_keys for a better and more in-depth look at using SSH keys

Secure Shell Key Authentication[edit | edit source]

Setting up SSH Key Authentication allows a user account to connect from one server to another without requiring a password login. This can be utilized for applications (e.g. Nagios monitoring other servers), as well as for publish scripts that move files around servers as well as individual users.

Procedure[edit | edit source]

  1. If you are an administrator, please assume the role of the user for whom you are setting up this service.
    1. sudo su user
  2. Ensure the user has a ~/.ssh/ directory with appropriate permissions. It must allow the user access for RWX, and group and other permissions must not be writable. Typically, 755 is a good setup. If they don't have one, then 
    mkdir ~/.ssh/ && chmod 755 ~/.ssh
    Note that the actual identity files should NOT be readable by anyone but the user because ssh-add ignores identity files if they are accessible by others. That means files like id_rsa should be 600 and id_rsa.pub should be 644
  3. Create a new private/public key pairing for the user. Type: RSA, Bits: 1024, File:~/.svn/identity[.pub] 
    1. ssh-keygen -t rsa -b 1024 -f ~/.ssh/identity
  4. Copy the contents of ~/.ssh/identity.pub so you can paste it in a file on the remote server.
  5. Login to the remote server and assume the role of the user for whom you are setting up this service in step 1 above.
  6. On the remote server, ensure the user account also has a ~/.ssh/ directory with the same permissions as in step 2 above.
  7. Open a Text Editor and edit ~/.ssh/authorized_keys
    1. Paste the public key from step 4 above into this file, on one line only.
  8. Try logging in from the first server to the second without using a password.

Troubleshooting[edit | edit source]

Check /var/log/auth.log on the remote server for details if this doesn't work as expected.

If you want to check what version of SSH is running on a server, you could do this with telnet (although the ssh client will also tell you this information):

$ telnet example.com 22
Trying 192.168.1.1...
Connected to example.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3
^]
telnet> quit
Connection closed.

Retrieved from "https://wiki.freephile.org/wiki/index.php?title=Using_keys&oldid=4681"