Secure Passwordless Logins with SSH Part 1
By Bri 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. 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.
Root can also enable a similar user-based system-wide passwordless access setup
- 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
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
Next week I'll give a quick overview of setting up SSH identities
in general, before we delve into our command restrictions.
 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.
 Of course, the administrator must allow this form of authentication
in the /etc/ssh/sshd_config file.
 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)
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 email@example.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_Securityfirstname.lastname@example.org.