Yeah, I googled it to heck and gone too! What I decided, I think, is not to use CURL at all because I want to change these scripts as little as possible and CURL is just another way to use ftp (and http, etc.). SO, I think I will use a .netrc file where I can keep all the addresses, users and passwords. These scripts are all run by the same ID so that should work. I put together a little script and it worked well.

I guess my question - now - is is there some risk attached to using a .netrc file? That I don't know about cause I'm a newbie?

Make sure the .netrc file is readable only by the user running the script. Actually, you won't be able to connect otherwise.

Make sure that the directory that contains the script has r and x permissions only for the user.
This is similar to ssh which won't make a connection if the .ssh/ directory is group or other readable.

If instead you were running your own ftp or other service, and users authenticated with you, you would store the hashes of passwords instead of the passwords themselves. As I understand it, your .netrc file contains passwords for the ftp sites of others.

One other thing to consider is whether the .netrc file will be contained in backups. You want to make sure that it is still secure, and not readily readable by anyone who has access to a NAS storage device.

1 members found this post helpful.

You make a good point. I will definitely check on backup. I would not have thought of that! Thanks! BTW, I haven't a clue what the code you included was supposed to be! Yikes!

never heard of a .netrc file but based on your description if it is just a list of addresses, usernames, and passwords then it is horribly insecure. how is it different than storing a file on your pc with a bunch of credit card numbers, names, expiratin dates and cvv's ?

1 members found this post helpful.

Well ONLY the ID has access to the file - no group or any other rights to anybody else. And ftp won't even USE the file if that is not so. Apparently the .netrc file is old to Unix!

The code is part of my signature. It formats a pdf man page file that is sized for a kindle, so you don't need to move side to side. At my age, I have a problem reading full sized pdf pages that are scaled down.

Suppose you cut and paste it into bin/makepdf, and run: chmod +x $HOME/bin/makepdf
First gunzip the manpage file. Then convert it.
You could make a full sized pdf file of a manpage like:
man -Tps find | ps2pdf - find.pdf

Or you could read it on the screen directly:
man -Tps find | okular -

1 members found this post helpful.

Given that you are the client for a large number of public ftp sites, you are the one providing the passwords, and due the the large number of sites, and passwords, you can't be expected to remember them all. Under these circumstances, I suppose a file of username/passwords is acceptable. If the ftp servers are your own, than using sftp or scp with public key authentication would be preferable. But if I understand it, they aren't, so you don't have this option.

Even an ssh private key will be written in a file. The file will be in $HOME/.ssh/ and the key, the .ssh and your $HOME/ directory will need to be only user readable or ssh will refuse to connect. If the same precautions to protect your username/password file are used as protects the ssh private key, I think that is the best you can do under the circumstances.
Another precaution could be to encrypt the ftp passwords file, and decrypt if before using it. The ssh private key can be protected with a passphrase.
example encluding with des3 cipher:
openssl enc -e -des3 -in ftppass -out ftppass.enc
example decoding:
openssl enc -d -des3 -in ftppass.enc -out ftppass

One precaution you could take with backups, is to exclude your ftp passwords file from being backed up. Simply add --exclude=PATTERN to your tar command, and back it up separately, in a secure manner. Another option is to encode the password file and delete the decoded file after use. Then the encoded file can be included with a non secured backup. Yet another option is simply to keep backups under lock and key. You could do this backups to tape or external drive.

2 members found this post helpful.

You guys are great! I have a Kindle too (and I hate those lousy Man pages). I will definitely try that code out! Good idea about the file - I shall see what the Unix/Linux group can come up with. I've got a test script working now and am finally getting my plan together to actually convert the scripts. Only been 2 weeks. *sigh* I always expect things to go more smoothly than they do! It is a real help that this group exists. I hesitate to consult all my very busy colleagues with stupid questions but you all are very polite!

Thanks!

at my work we have the same problem. the outside facing server is unix so healthcare vendors can send us claims thru sftp/scp. the internal machines are all ibm mainframes which dont support ssh so all the jobs that transfer files have the ftp user name and password written in them... whats worse is they post to a log that gets cleared nightly but it is readable by everyone.

1 members found this post helpful.

Oh that is so ugly! We are currently doing a project to eliminate our IBM now. Our focus seems to be to do all windows/unix/linux boxes. So it's a good thing I'm learning that stuff! My main experience is Tandem - and they are going to eliminate that one too. I suppose this is progress, of a sort!