Network Security Hacks [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Network Security Hacks [Electronic resources] - نسخه متنی

Andrew Lockhart

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Hack 73 Quick Logins with SSH Client Keys

Use SSH keys instead of password authentication
to speed up and automate logins.

When you're
an admin on more than a few machines, being able to navigate quickly
to a shell on any given server is critical. Having to type
ssh my.server.com (followed by a password) is not
only tedious, but it also breaks your concentration. Suddenly having
to shift from "where's the
problem?" to "getting
there" and then back to
"what's all this,
then?" has led more than one admin to premature
senility. It promotes the digital equivalent of "Why
did I come into this room, anyway?"

At any rate, more effort spent logging into a machine means less
effort spent solving problems. Recent versions of SSH offer a secure
alternative to endlessly entering a password: public key exchange.

For these examples, I assume that you're using
OpenSSHv3.4p1 or later. To use public keys with an SSH server,
you'll first need to generate a
public/private key pair:

 $ ssh-keygen -t rsa

You can also use -t dsa for DSA keys, or
-t rsa1 if you're using Protocol
v1. (And shame on you if you are using v1! Upgrade to v2 as soon as
you can!) If at all possible, use
RSA keysthere are some problems with DSA keys, although they
are very rare.

After you enter the command, you should see something like this:

 Generating public/private rsa key pair.
Enter file in which to save the key (/home/rob/.ssh/id_rsa):

Just press Enter there. It will then ask you for a passphrase; just
press Enter twice (but read the following section, Section 6.8.1).
Here's what the results should look like:

 Enter passphrase (empty for no passphrase): 
Enter same passphrase again:
Your identification has been saved in /home/rob/.ssh/id_rsa.
Your public key has been saved in /home/rob/.ssh/id_rsa.pub.
The key fingerprint is:
a6:5c:c3:eb:18:94:0b:06:a1:a6:29:58:fa:80:0a:bc rob@localhost

This created two files: ~/.ssh/id_rsa and
~/.ssh/id_rsa.pub. To use this key pair on a
server, try this:

$ cat .ssh/id_rsa.pub | \ 
ssh
server
"mkdir .ssh && chmod 0700 .ssh && cat > .ssh/authorized_keys2"

Of course, substitute your server name for
server.
Now, simply ssh
server and it should log you in
automatically, without a password. And yes, it will use your shiny
new public key for scp, too.

If this didn't work for you, check your file
permissions on both ~/.ssh/* and
server:~/.ssh/*. Your private key
(id_rsa) should be mode 0600 (and be present
only on your local machine), and everything else should be mode 0655
or better. In addition, your home directory on the server will need
to be mode 755 or better. If it is
group writable, someone that belongs to the group that owns your home
directory could remove ~/.ssh, even if
~/.ssh is not writable by that group. This might not seem obvious at first, but if
they can do that, then they can create their own
~/.ssh and an
authorized_keys2 file, which could contain
whatever keys they wish. Luckily,
the SSH daemon will catch this and deny public key authentication
until your permissions are fixed.


Security Concerns


Some
consider the use of
public keys a potential
security risk. After all, one only has to steal a copy of your
private key to obtain access to your servers. While this is true, the
same is certainly true of passwords.

Ask yourself, how many times a day do you enter a password to gain
shell access to a machine (or scp a file)? How
frequently is it the same password on many (or all) of those
machines? Have you ever used that password in a way that might be
questionable (on a web site, a personal machine that
isn't quite up-to-date, or possibly with an SSH
client on a machine that you don't directly
control)? If any of these possibilities sound familiar, then consider
that an SSH key in the same setting would make it virtually
impossible for an attacker to later gain unauthorized access
(providing, of course, that you keep your private key safe).

Another way to balance ease of use with security is to use a
passphrase on your key, but use the SSH agent to manage your keys for
you. When you start the agent, it will ask you for your passphrase
once, and will cache it until you kill the agent. Some people even go
as far as to store their SSH keys on removable media (such as a USB
key chain), and take their keys with them wherever they go. However
you choose to use SSH keys, you'll almost certainly
find that they're a very useful alternative to
traditional passwords.

Rob Flickenger (Linux Server Hacks)


/ 158