+------------------------------------------------------------------+
| Linux Security: Tips, Tricks, and Hackery |
| Published by Onsight, Inc. |
| |
| 11-December-2002 |
| http://www.hackinglinuxexposed.com/articles/20021211.html |
+------------------------------------------------------------------+

This issue sponsored by: Onsight, Inc, your source for open-source
solutions.

Onsight offers on-site training on Basic Perl programming, Advanced
Perl programming, CGI programming using Perl, Tcl/Tk, XML and
JavaScript. All courses are hands-on, designed by real-world
consultants and fully customizable. Because all classes are on-site,
our overhead is low and our prices consistently beat those of our
competitors. Every Onsight instructor is a seasoned consultant able
to provide back-end web programming, network security, system
administration and other support services.

For more information, visit http://www.onsight.com/

--------------------------------------------------------------------

Secure Passwordless Logins with SSH Part 1
By Brian Hatch

Summary: How to create passwordless logins to allow remote
administration tasks securely with SSH

Many of my past newsletters have detailed configuration setups that
required you to be able to execute commands on remote machines
without interactively supplying a password. The next few articles
will help show how you can set up such a system.

In general, your passwordless SSH needs fall into three categories:

Interactive Administrator Access
    An administrator may want to be able to 'ssh destination' and log
    in without a password between the many machines she maintains.
   
Triggered Commands
    Some commands may be triggered by other events. For example you
    may set up your CVS system to run a 'sync_website' command
    whenever the tree is committed which will update a local copy and
    run 'wmk -a' and then scp the html files to the actual webserver.
    Or perhaps you want your /etc/tinydns/root/data file to be
    automatically rsync'd when you make changes to your DJBDNS files.
   
Cronjobs/etc
    Say you want to have certain directories copied to a remote
    system as poor-man's backup system using scp or rsync. Or perhaps
    you want to push /etc/passwd and /etc/shadow to all your machines
    from the master server, rather than run NIS, LDAP, or other
    real-time password syncing options.
   
There are many different ways you may implement passwordless access
via SSH.

Host-based authentication
    This authentication system allows an administrator to create
    trust between machines. If machine "foo" trusts machine "bar"
    then when a user "jdoe" at bar tries to ssh to foo, he is able to
    log into jdoefoo without any password.[1] This is ideal for lab
    environments where a user should be allowed to log into all
    machines. Only root can set this up, by creating entries in /etc/
    ssh/shosts.equiv and making sure all the necessary host keys are
    in /etc/ssh/ssh_known_hosts.
   
Shosts/rhosts-based Authentication
    In this scenario, a user on foo lists the username/host pairs
    that should be granted passwordless access. For example jdoefoo
    may allow john_doemy_isp.net to connect without a password. This
    style of trust can be enabled by the user directly[2].
   
    Root can also enable a similar user-based system-wide
    passwordless access setup using /etc/ssh/shosts.equiv.[3]
   
Identity-based Authentication
    In this scenario, an account specifies which public/private key
    pairs should be allowed to connect, and can place various
    restrictions on the access granted depending on the key in
    question.

The first two options are the most general, and quickest to set up.
They intentionally do not allow root logins, but have few other
useful restrictions. You can get plenty of information about creating
this kind of passwordless access by reading the sshd man page, as
well as the SSH faq[3]

Identity-based authentication, on the other hand, can be very finely
controlled. For example you can

  * restrict which machine(s) can connect with that identitiy
  * place variables into the process' environment
  * disable port, agent, or X11 forwarding
  * permit only certain host/port forwarding requests
  * prevent TTY allocation
  * force a specific program to be run, regardless of what command
    the user specified

It is that last item that can be the most useful. The end goal of
this project is to allow a remote account to log into this machine
and run only approved commands. Then we'll try a few examples that
you may find helpful in the real world.

Next week I'll give a quick overview of setting up SSH identities in
general, before we delve into our command restrictions.

NOTES:

[1] There's a lot more that goes on behind the scenes. The ssh
process on "bar" must prove it is bar by answering a challenge from
foo. Foo needs to have the public portion of bar's ssh host key in
order for this to work.

[2] Of course, the administrator must allow this form of
authentication in the /etc/ssh/sshd_config file.

[3] Using hostnames with /etc/ssh/shosts or /etc/rhosts is almost
always not what you want -- it lets that remote user log in as any
local user. (Except root)

[4] http://www.onsight.com/faq/ssh/

                            -------------
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He's been using SSH to secure
his remote logins since Tatu posted the first version of the code -
even if the administrators of those machines refused to install it
for him. Brian can be reached at brianhackinglinuxexposed.com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-requestlists.onsight.com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2002, Brian Hatch.

-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomoattrition.org with 'unsubscribe isn'
in the BODY of the mail.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]