I want to use the Command Line Interface while ssh'ed into the appliance to copy a file to a remote Red Hat Linux server via SFTP.
This is successfully working from the CLI in an interactive session:
copy export:///WinningLotteryNumbers.zip sftp://someuserid@MyServer.abc.prod//datapower/stuff/NothingOfInterestHere.zip
I get prompted for the password for someuserID, I type it in, and the file is successfully copied to MyServer (fully qualified DNS name is MyServer.abc.prod)
I want to get this to work without having to type in the password for that sftp, so I followed the instructions here to set up that DSA key pair.
On MyServer while logged on as someuserid I ran the command ssh-keygen -t dsa
and it produced the id_dsa file. I copied that file up to the certs directory on my DP appliance, and I gave it a more meaningful name, id_dsa_MyServer_someuserid. (Was it wrong to give it a new name when I copied it up to the appliance? The original file has the original name on the Linux server)
I created a Crypto Key referencing the cert:///id_dsa_MyServer_someuserid file called MyServer_someuserid_CK.
I modified the default User Agent and gave it a PubKey-Auth Policy which references that new Crypto Key (MyServer_someuserid_CK), and I specified this for the URL matching Expression:
Applied and saved the configuration.
The good news is this PubKey-Auth Policy is getting a match on that URL string when I am in the CLI and try to sftp to that destination. I know it is seeing it because if I use something slightly different in the sftp command I execute, or if I modify the URL Matching Expression to have an extra character the behaviour of my CLI command changes.
The bad new - the behaviour of my CLI command to copy via sftp!
If this PubKey-Auth Policy is invoked, I get the generic error in the CLI that says the file can't be found. Its the same generic error I get if I remove that PubKey-Auth Policy and then purposely enter a bad password when prompted.
Looking at this from the RHEL server's perspective:
11.222.333.44 is the (changed for this posting) IP address of my DP appliance.
In /var/log/secure on the RHEL server
When I enter a bad password on the CLI while SSH'ed into the DataPower appliance.
Dec 23 13:34:28 MyServer sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=MyDPappliance.thisdomaind.com user=someuserID
Dec 23 13:34:30 MyServer sshd: Failed password for someuserID from 11.222.333.44 port 18916 ssh2
Dec 23 13:34:30 MyServer sshd: Connection closed by 11.222.333.44
When I enter a good password on the CLI while SSH'ed into the DataPower appliance.
Dec 23 13:34:58 MyServer sshd: Accepted password for someuserID from 11.222.333.44 port 18921 ssh2
Dec 23 13:34:58 MyServer sshd: pam_unix(sshd:session): session opened for user someuserID by (uid=0)
Dec 23 13:34:58 MyServer sshd: subsystem request for sftp
Dec 23 13:34:59 MyServer sshd: pam_unix(sshd:session): session closed for user someuserID
When the Pubkey-Auth Policy is invoked on the DataPower appliance the only entry on the Linux server is:
Dec 23 13:37:32 MyServer sshd: Connection closed by 11.222.333.44
/var/log/btmp only shows something when I don't use the Pubkey-Auth Policy and I type a bad password. Nothing shows up in /var/log/btmp when the Pubkey-Auth Policy is invoked in the Datapower appliance side.
So I must have done something wrong with that id_dsa file. Was it OK to rename it when I copied it up to the appliance? Did I miss some other step?
It seems like the DP appliance is attempting to make a connection to the RHEL server, and then the DP appliance is the one that kills the connection, based on that single line entry in /var/log/secure on the RHEL server when the connection is attempted using the PubKey-Auth Policy