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
