[ISN] Secure Passwordless Logins with SSH Part 1

From: InfoSec News (isnat_private)
Date: Thu Dec 12 2002 - 00:38:47 PST

  • Next message: InfoSec News: "Re: [ISN] The good and bad of computer hacking"

    |  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
    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.
        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 jdoe@foo 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 jdoe@foo
        may allow john_doeat_private 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
    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.
    [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 brianat_private
    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
    Archives of this and previous newsletters are available at
    Copyright 2002, Brian Hatch.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Thu Dec 12 2002 - 04:13:08 PST