Importing multiple ssh keys

[so.nimda]

Hi,

I have a general question on the import of multiple ssh keys :

If there are several such files generated from many 'source' servers, will the import based on that same file name (id_dsa.pub) overwrite each other in the 'target' server?

Does it matter if the 'id_dsa.pub' sent over for import is an ascii or binary file?

Sorry if the question sound silly as I am trying to help the other party managing the target server which I have no visibility.

Thanks & regards

[Bill Hassell · Accepted solution]

The public key is a simple ASCII file although it may be generated with Unix-style (from PuTTY) or PC style (from Reflection). The target server just requires that the text be appended to the authorized_keys file. There are 3 parts:

ssh tag (ie, ssh-rsa or ssh-dsa, etc) which may be missing in the pub file.

public key - this is the meat of the key and must be a single string, no embedded spaces or new lines (CR+LF or LF), followed by an optional comment about the source of the public key (usually a good place to add the local system name, perhaps a date).

The biggest problem in adding these keys are with unsophisticated editors (ie, GUIs). vi works very well but you must turn off text wrap (wrapmargin=0) and auto-indent (noai). For Unix systems, just appending the file to the .ssh/authorized_keys file is OK but depending on the pub-key generator, you may need to clean up the result to get it to work.

Of course, there are bigger issues as far as propagation of the keys. The keys must be allowed for the specified user(s) and must be permitted on each specific server. That is the responsibility of the target server(s) sysadmin. I would also treat the public key as a secure file -- sending by open email is not a good idea. If you send it via ftp from a PC, check the local key using Notepad. If it has strange characters, send the file in BINARY, otherwise use ASCII.

[so.nimda]

Hi Bill,

Thanks (once again!) for the detailed reply.

I managed to find out more about the issue I am facing. Here's the scenario :

I have 2 UX servers (clustered) which need to sftp to a Windows server running "ws-ftp".

Under normal circumstances, both UX servers are up and running and batchjobs that's going to sftp to Windows can run on either server. The problem (I was told) is that only one key can be imported to the Windows ID. This means that I have to limit the batchjobs to only run on one UX server.

The problem isn't so much about ASCII or BINARY format of the key but that the Windows ID can only accept one key - at least that's what I was told.

I'm not sure if this is a "ws-ftp" product limitation or a limitation in general in the way public/private keys work.

I'm sure there are situations out there whereby many "source" servers are logging in to a "target" server using only one (and the same) ID. The "target" ID in this case must be able to accept the importation of the many "source" keys. It doesn't make sense to create hundreds of unique IDs for the "source" to connect to the "target".

Is my assumption correct?

If so, how does that one unique "target" ID accept the many "source" keys?

Are the many "source" keys being appended one after another in the "target" ID?

Thanks & regards

[Steven Schweda]

> [...] need to sftp to a Windows server
> running "ws-ftp".

Is there only one version of this "ws-ftp"?

> [...] but that the Windows ID can only
> accept one key - at least that's what I was
> told.

If your question is about some SSH software
on Windows, then you would seem to be asking
it in the wrong forum.

[Bill Hassell]

This is really a question for the SSH package on the PC. There is no limitation to the number of keys you can put in the authorized_keys file on any of the OpenSSH versions I've seen. I suspect that the Windows admin needs to read the docs for ws-ftp (or whatever is running on the PC to accept incoming sftp connections. Appending files might be a foreign concept if all you know is mice and GUIs.

[Jim Walls]

If it is possible, you might want to consider turning the problem around the other way: run the batch jobs on the Windows machine - i.e. make the Windows end the originator.

We do this on several of our servers, using the command line utilities (plink, psftp and pscp) supplied as part of the PuTTY package for Windows. The jobs are run out of the Windows scheduler (the equivalent of cron in UNIX).

[so.nimda]

Thanks all for your replies.

@Steven : I was thinking out loud. I thought that there could be some issues on the UX end.

@Bill : We actually experimented the appending file concept to the "ws-ftp" software and it didn't work. So I guess you are right about the "foreign concept".

@Jim : That's an idea we can explore but as the data file originates from the UX server, it may be faster to just put them in the Windows server. To have it the other way round, we will need to work out the timings for the transfer to take place.