+------------------------------------------------------------------+ | 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 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 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 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 linux_security-requestat_private 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 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