Andy,
As you know, you can have only one clustered index on the table, but you can have plenty of non-clustered indexes on the table.
If you want this query to run quickly, I would suggest individual non-clustered indexes on the individual columns I mentioned earlier.
From what I understand about indexes, having a clustered index really slows down any updates (that involve columns in the clustered index) and inserts/deletes to the table. Especially with a large table, inserting a single row into the "middle of the index" requires the movement of huge amounts of data. Alternatively, you can just let your data reside in a "heap," and rely on your non-clustered indexes to navigate through that "heap" in an efficient manner.
(I like to think of a clustered index as being like a telephone book, usually with each page filled to capacity. If you insert a name, all the subsequent names must be moved to make room for the new entry. You can use FILL_FACTOR on the clustered index to leave room for new entries on each "page" of the table. So there are plenty of I/O operations involved, just to insert a single row. But if the telephone book is replaced by putting all the entries in a "heap", where the indexes are like having a search-engine's knowledge of the data, you can enter any set of indexed values to find rather quickly the "entries of interest." With the non-clustered index, you end up with a "pointer(s)" to the data row(s) of interest; with the clustered index, when you get "to the bottom" of the index, you find the row of data itself, instead of merely a pointer to the row of data.)
IMHO the main benefits for clustered indexes arise with tables that are "static," i.e., tables that experience no INSERT, UPDATE, or DELETE actions.
I have plenty of moderately large (millions of rows, as opposed to tens of millions, or billions of rows) tables for which I have only non-clustered indexes. The data access is plenty fast with non-clustered indexes. (I created the tables and indexes long before I understood anything about clustered versus non-clustered indexes -- so I just used "create index" without any special qualifiers.)
Because of the way you are performing your JOINs, with only a single column at a time, I would recommend the separate indexes for each column that you mention. The size of the index is related to the number of columns in the index, and the size of the data in each column.
Yes, it will take a bit more space to have five indexes with one column each, rather than one index with all five columns, but the five-column index is only useful when your JOINs include the "first" column listed in the index; it is not useful if you only use the "second and third" columns of the index, for instance; it is only moderately useful if you only use the "first and third" columns of the index. (I say "moderately useful" in that last instance because the index can only benefit the query with the "first" column; it cannot benefit with the "third" column because the "second" column gets in the way. Maybe think of an index on street addresses, wherein the "first" column is the alphanumeric "street number", the second column is the "street name", and the third column is the "city". To search for "street name" and "city" cannot use the index, so a complete table scan must be performed. To search for "street number", e.g., with a LIKE condition, works fine; but, to search for "street number" and "city" requires a complete scan of the portion of the table that matches the "street number" condition, since all the "street name" entries come between "street number" and "city", preventing the "city" aspect of the index from being used.) You probably know all this already, so please forgive my elaboration on this issue.
Those are the suggestions I would try, anyway, were I in your position.
Dan