Login Script

[/dev/null]

Monks,

I seek advice about writing a login script. I work in a UNIX environment of about 1700 servers, mostly SUN running solaris 5.8, and IBM running AIX 5L. The criteria for my script is as follows:

Preferrably ssh to the requested server or telnet if it is not installed. Install ssh package if ssh is not installed.

If ssh is installed, the script should copy my rsakey from my home directory to the remote server to allow login without a password.

Log all hosts that have ssh installed with RSA key added so the script knows when not to use a password.

Encrypt my password when sending via Telnet i.e. MD5, RSA

su to root and drop into interactive mode after completing the above. (Expect?)

Any suggestions on how I would complete the above would be greatly appreciated. Modules used in the past, scripting methods, etc.. My scripting skills leave something to be desired, but I believe this may help future endeavors.

Thanks in advance,
/dev/null

[tachyon]

Any suggestions on how I would complete the above would be greatly appreciated?

Do some research perhaps? Hire someone to do it for you? Hope someone does it for you based on the above spec? This sort of thing is a very commonly (solved) problem so why don't you have a look at Super Search for terms like 'SSH' or 'remote exec' where you will find gems like Moving around with password protected machines amongst many others. On the module front look at Net::SSH and all its friends. There is also Expect but you probably won't need it.

There is nothing you can do to make normal Telnet secure, that is why SSH exists. Login is plaintext. There are 'secure' telnet servers that use Kerebos but why would you not use SSH? You can't 'encrypt' with MD5 it is a non reversible hashing algorithm. SSH uses RSA.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[/dev/null]

Thanks tachyon,


Articles I have found do not come close to doing the required actions I've listed in this node. I usually do my research before throwing myself to the wolves. In a perfect environment I would be able to ssh to every box, but I may need to use telnet when SSH is not installed. How would it be possible to ftp my ssh key to the box and su to root without using Expect? Any examples?

/dev/null

[tachyon]

Many of the articles I have found on this site do not come close to doing the required actions I've listed in my article.

Well given that some of them are technically impossible (as pointed out) ie encrypt your Telnet session that is perhaps not surprising. Actually there are examples of everything you want here and all over the web. Remote administration if not all that new you know. Unless you are on Win32.

Net::FTP will let you FTP in (one protocol with all its restrictions). Net::Telnet will let you telnet in and isssue arbitray commands. You need Net::Telnet if you can't use Net::SSH.

If you have to do 1700 boxen the simplest way to do it is to put up a web server, encrypt your ssh key with some decent algoritm that will be available on your boxen then stick the encrypted file in the server root. Then just telnet in, cd to the correct dir, use wget to pull the file down then decrypt it. Perhaps use wget to get ssh and then issue the commands to install it as well if need be. Perhaps use wget to pull (and Net::Telnet to issue the install commands) for Crypt::CBC and Crypt::Blowfish or similar so you can decrypt your ssh key using a perl command line call. Repeat ad infinitum.

If you have currently only been using Telnet to get into all your boxen and they have public Internet interfaces it is probable that at least one if not many are compromised. This is a significant issue due to the fact that when you use ssh keys for authentication your security is only as good as the weakest link. Compromise one box, compromise all.

If you read the docs for Net::Telnet you will find plenty of examples. In the examples section ;-) Seriously, the Net::Telnet docs are extensive.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[JSchmitz]

VERY rough sketch that may help you get started - assumes you have a txt file somewhere with all the hosts names -
cheers



#!/usr/bin/perl

use strict;
use warnings;

use Net::SSH;

open IN,  "<hosts.txt" or die "Can't open hosts.txt";

 while(<IN>) {
  chomp;


    ssh_cmd('user@hostname', $command);
    ssh_cmd( {
    user => 'user',
    host => 'host.name',
    command => 'command',
    args => [ '-arg1', '-arg2' ],
    stdin_string => "string\n",
  } );

[reyjrar]

If this is like ANY other similar request I've worked on, ssh will not be the last package that needs to be distributed. You might want to look into rsync and rdist as a viable alternative to a homegrown perl script for binary/configuration synchronization across multiple hosts. Rdist even uses ssh as a transport mechanism. Rsync's claim to fame is efficiency, transporting only the differences between the src and the dest host. This may be a big gain for you with 1700 hosts. I belive the last time I checked it was able to use ssh as its transport mechanism as well.

Just a few random ideas.

-brad..

[diakonos]

Wow, that would definately be an overwhelming server environment. It would be very tempting to automate as much as I could. However, my advice would be to "stick with ssh" and its ftp counterparts. Even if these servers are not physically connected to the Internet you obviously are in an environment that security would be an issue (college institution etc.).

I am going to think out loud a little on this one. First, the management of the scripts on each server and the keys would be a little bit of a headache. (I want to say nightmare but I am going to avoid that.) If you decide that you are going to write login scripts across multiple platforms you want to make sure that you write the scripts very generic but very well. And since these are login scripts, poor programming + script language upgrade can lock you out of 1700 servers (especially if you want to login as root).

Still thinking out loud here. You cannot successfully expect to securelly login to a server using telnet. Everything sent across that port is clear text. So, if you encrypt the password, send it across telnet, and the server side auto-compares the encrypted password with the shadow files or un-encrypts them, then a capture and reproduce of the packet and then a login with the same encrypt string will allow access to the server (along with the su password if sent afterwards across telnet).

With SSH you can allow direct root access (not my advice but it is a config option - usually on by default).

.If you are accessing from a Windoze box then a program like secureSSH will allow you to store your passwords and easily create multiple connections quickly. It does all of the key management (saving etc.) for you on the client end. It will also allow you to create scripts to run on the server after you login in. This is not the only package out there, there are others like Reflections etc. If you are loggin from another Unix box then then you can script a nice client that includes the basic login "ssh server -l user" and then do whatever your heart desires.

The login script on the server side needs to only contain what you do after you have successfully logged in. Don't let that be part of the login validation and install process.

There is good advice in the other answers you have been given. Now for the part of the installation of the ssh software. You can script that with Perl. As long as all of you OS's are consistent with the locations, versions of libraries, and module requirements. If not then creating a install script may take some time but be very valuable in your setup. The important thing is SECURITY, SECURITY, SECURITY. There is too much junk flying around the Internet these days to ignore that. I wish you the best but I don't envy you.

[mattr]

I don't know if it is such a good idea to be automating the installation of security software as root over the net with a fresh program and 1700 servers... um, how did you get the list of 1700 root passwords again? ;)

If there are other admins of these machines they might get ticked off if something happens.. and hopefully the bugs will be worked out on just a few machines first! That said, with the frequency of ssh upgrades recently I can understand the need to automate the upgrade, this could be a seriously needed tool. But I just wonder if you don't already have that kind of tool in your size department.

Anyway assuming this is all on the level, the company has fired all of its administrators and just hired you to admin 1700 unix servers even though (no personal offense intended) you don't know shell scripting, um, I think this could be a bad situation for you. Actually that isn't really fair. You may have the tool but still be assigned the job, and anyway how else do you learn? Maybe you can make something more useable than whatevery you have. So given that this is probably a good idea.

It is certainly possible to automate these kinds of things see for example Melbourne.pm's talk on Expect.pm. (by the way the link about fastmail.fm on mod_perl is interesting though off-topic.) It does seem to me that passwords sent over telnet, including the initial login itself, will be cleartext over your network (unless you installed something through another route, that would set up ssh on the target machine by itself). So you would need at least to quickly change them by logging in over ssh again. And maybe disable telnet right away, which could if a bug creeps in, lock you out of a lot of machines. Also there may be firewalls settings involved. Well anyway caveat emptor and all that. The tools are there, why not experiment with your own machine first? Maybe you want to set up a distribution server there too.

Sounds like maybe you should keep your private key on a very secure removable piece of equipment.. Also I guess I should mention that if you have machines without ssh installed, you may have a private interface (i.e. ethernet cable) which is not open to the outside world. So maybe you want to see if these machines are on an internal (i.e. 10.x.x.x) network. Telnet and ssh could be set to only be accessible from within.

Finally, my own two niggling cents but while shell scripting is fine, to a lot of people perl is more advanced than it, not less so. Though you maybe want to know both. Anyway I wish you luck.

Oh, finally I shold mention, though I have never used it, a hit on freshmeat.net that sounds quite fresh! SWUP - The Secure SoftWare UPdater written in python but maybe that's okay. Meant for linux but maybe you want to check it out anyway.

[tzz]

I'd go with Net::SSH and Net::Telnet for the login processes, as others have pointed out.

For file copies, I would consider rsync or cfengine in a pull setup. You can signal the pull on the client so it acts like a push, and it has the advantage that if you update the configuration you can have it automatically propagate. You can do this based on machine classes (e.g. machine "zorro" is in class "bandits") so you know exactly what machines are going to copy your RSA key, for instance. Logs are kept by rsync and cfengine, but you'll find that things will Just Work, and logs will be used very rarely. I can't recommend cfengine enough for the kind of administration you are doing.

Ted

[spartan]

Here's my $.02...

I know NOTHING about AIX, so my discussion will deal with solaris exclusivley.

I have worked in an environment with a couple hundred solaris boxen, and they were all on a localized network where telnet was eventually turned off in favor of ssh. I do not know who installed the initial hodge-podge of ssh servers on this network, but it simplified (to some extent) the job I had to do. Although, using Net::Telnet should fill in the gaps for initial instsalls.

The job you ask? I had to upgrade (read: replace) every ssh installation.

The requirement was simple, figure out if the current ssh install was a solaris package, if so, removing the current iteration would be easy, otherwise it was up to me on a per-machine basis to try and remove it, this may not be a concern for you, other than bugs in old ssh versions, but I digress.

I suggest for all of your sun boxen to create a stream based package (plenty of info out there on creating sun packages check here) move it out to the sun boxes, and perform a pkgadd -d myssh.pkg.

I wrote a combination of perl scripts, and shell scripts to automate this process for a given list of hosts from a text file. Although I have to say, I spent a lot of that time just figuring out the package creation process on sun machines, and how to install them COMPLETELY (that is answering questions in the package install) hands off, it's possible, but a pain in the butt. After that all I had to do was "push a button", wait and see what happened, and fix any errors.

I know I'm making this seem easy, it was anything but. Although if you put a bit of thought into this, given the excellent comments above, you should be able to figure something out. I might be able to find the docs if you're REALLY interested, let me know.

Very funny Scotty... Now PLEASE beam down my PANTS!

[astrobio]

I have had success with the unix utility, socat. There are examples for this sort of problem, including scripting a ssh or scp session without using Expect or transferring non-securely.