I'm new to Linux.
I am working with a Redhat 5.5 server and am using a Java-based SFTP script that will allow multiple users to upload text files to a server. I am undecided if each user will have a separate directory or if I will use a naming convention that includes their customer ID.
The files include some personal information about their LAN settings, so I prefer to use SFTP as apposed to FTP. It is my understanding that SFTP is encrypted (Also, I have a Java class configured to upload via SFTP, so I prefer not to switch protocols unless their is a very-good reason).
The prototype is for a system that will support large numbers of customers and the thought of continually adding and removing clients through the command line seems highly impractical. (Again, I am new_to/learning Linux and Redhat).
What are normal conventions for giving multiple users permission to SFTP upload files with a unique username and password for each.
You can do this by setting up your external sshd as chrooted sftpd (use the sftpd-internal option in sshd_config for this). Every user can have his own chroot-jail. On the authorized_key file of your users (don`t allow passwords!) you should prefix each public key with the neccessary prefixes that will disallow shell-access. You chroot should also contain only the basic setup for sftp-access (no binaries, no libraries, just /dev/null, /dev/zero, /dev/random and /dev/urandom - as far as I remember).
What you are describing is possible, but it is probably not the best of ideas, especially not if you, as you say, are new to Linux.
As you say, managing file permissions and users is going to be a bit of a nightmare, and SFTP requires SSH that in itself can expose all kinds of functionality like executing code on the remote server and downloading files.
It is possible to configure an SFTP server with a modicum of security, but there are many pitfalls in configuring it. There's a lot of misleading advice out on the internet about configuring SFTP-only users with SSHd. Long story short, it is not sufficient to simply change their login shell to an invalid shell, you also need to worry about their ability to remotely executing commands bypassing the shell, and their ability to read potentially sensetive system files outside of their home directory, as well as their ability to use SSH tunneling to bypass firewalls. As well as any other functionality I might not remember off the top of my head.
And it is possible to bypass the whole "need to create a user for every customer" thing, either by doing some dark wizardry with PAM to let SSH authenticate against some other user database, or by simply sharing a single user account (which should be sufficient as long as you only care about letting users upload files).
In addition, you're going to somehow solve a basic security problem SFTP has in your kind of application with many remote users that need to be able to verify if the remote server is the one it seems to be. There are no Certificate Authorities for SSH - the method SSH uses to protect against man-in-the-middle attacks is to cache a fingerprint of the SSH server keys of the servers the client connects to, and if the key matches the previously seen key, all is good. However if the key is not known, because it's the first time a client connects, SSH requires the user to check the fingerprint manually. It is not reasonable to expect your clients to actually do this, pretty much everyone will just click "yes" because they want to get on with their lives. You might be able to distribute the valid host fingerprint with your application, but that seems like a bit of a nightmare.
If you do decide to go forward with SFTP, despite the potential issues described I would suggest investigating rssh to restrict users to SFTP only. In addition, you should keep all your SFTP users in a chroot jail, where they cannot interfere with the operations of the server, or access any system files. (Even then, it might be possible for an attacker to enumerate the users of your system...) And you also need to make sure the sshd is configured to prevent SSH tunneling from your SFTP users.
...
Rather than deal with this kind of mess, I would suggest considering another protocol to upload your files which seems a lot more suited to your use case - why not consider uploading the files using HTTPS? You would need some kind of server-side CGI script or a Java servlet or something to receive the files and do something useful with them and perform authentication. The server-side script could take care of storing the files in a useful location. As for the client-side problem, uploading a file over HTTPS is such a common thing to want to do, that I would be astonished if there weren't some ready-to-roll API class you can just easilly use to do that kind of file upload.
Of course, this means you'd have to actually write some server-side CGI script to deal with your problem, but I do suspect you were going to want to somehow programmatically deal with the incoming files anyway, this actually makes it easier because code will be called for you every time there's a new file.