Ouch!
You're creating backdoors on your own servers, and even doing so with
real user accounts.
Not only are you making a breakin easier, but you're also giving perfect
deniability to the users involved, defeating accountability.
You can solve the problem securely, with standard tools: ssh, sudo and
(if you prefer) keychain.
1 Use ssh's cryptographic authentication. This is more secure than
passwords anyway, and (once set up) is less work for you and me when we
use ssh.
2 Use ssh-agent for key handling. This allows your cron jobs to use
pre-authenticated keys for ssh connections, so you don't have to be
logged in when cron starts the jobs. I'd favour using keychain to hide
the details and simplify scripting, but the advantage is a small one.
You will have to change your cron scripts to source a file containing
the connection details for ssh-agent.
3 For remote administration, use only special admin (fictitious)
accounts on the servers, rather than recycle real user accounts. This
allows you to lock down the admin accounts to just the rights that they
need; real users then don't need to have admin rights; and if you
really, really have to have an admin script masquerade as a real user
use passwordless sudo. You should be using this anyway to avoid logging
on as root.
An added bonus of (3) is that, should your cron machine be broken into,
attackers have a more difficult time spreading their toe-hold to your
servers. They could use the ssh keys to log onto the restricted admin
accounts, but not masquerade as real users or root (except as allowed by
sudo).
On Wed, 2006-12-06 at 08:04 -0500, John Stefani wrote:
Hello Everybody,
I have some cron jobs that use ssh (version 4.4p1) to connect to other
servers and run certain tasks. The users in question sometimes are real
users, sometimes fictitious users that I created only for running the cron
job. I changed to *NP* the password field of /etc/shadow for the
fictitious users on the servers the cron jobs connect to, and all works
happily. Here's my problem: those servers to which the cron job tries to
connect to as a real user, who has a real password, does not allow ssh
connections with null passphrases. I can't set the password field in
/etc/shadow to *NP* because sometimes I have to connect as the real user.
Does someone know how I can connect automatically to a server, using ssh,
as a user that has a password, but with a null passphrase? Hope the above
was not too confusing...
Absolutely any thoughts or workarounds will be much appreciated.
John Stefani
jstefani _at_ yorku.ca
