This is a follow up to:
Using JSch to SFTP when one must also switch user
This issue has been on the back burner since I asked the original question while our server management team reviews their policies, but I am now picking it up again!
What I want to do is to use JSch to connect to a remote server and then use sftp or scp to access some files - as per the code example in the original question. The issue is that these files are owned by another user and so I need to su to that user and then provide a password before issuing the sftp or scp command.
This cannot be done in JSch and this is right because it is a security risk to be able to send the password through the exec channel. So these are options I have going forward as I see them.
Override JSch functionality. Martin has very helpfully provided some guidance in an answer to the original question as to how this could be done by and how the password may be passed in "through the back door". But I am not confident in my own ability to override the JSch code and once again, even if successful, I would be circumventing a security feature that is there for legitimate reasons, so I am reluctant to attempt this.
On the server, grant my user password-less access to the other user. This is a no as my server management team will not agree to this.
Have a server-side .sh script that can be run by my user to gain access to the files. Again, this is a no as my server management team will not agree to it!
Automate a putty session i.e. phsically open putty and pass commands to the putty session line by line from the Java client.
Give up! Should I accept that I am trying to do something here that should not be automated and simply have a manual test instead?
I would be extremely grateful for any thoughts/guidance.
I am trying to do something here that should not be automated.
That's correct in principle.
The only correct automatic solution is to directly login with the user that has access to the files. Everything else is just a hack or working around your security policy. Ideally you should authenticate with a dedicated private key to allow monitoring the access from your application and to be able to control the access (e.g. temporary turning it off, without affecting other uses of the same account).
Though I can imagine that your system administrators won't allow you the direct login, because they cannot foresee what (if any) security issues it brings.