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_doe@my_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

Bri 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. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002

This is the December 11, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.