On Thu, Nov 01, 2018 at 02:37:27PM +0000, Paul Tansom wrote:
** Chris Green cl@isbd.net [2018-11-01 14:16]:
On Thu, Nov 01, 2018 at 02:08:15PM +0000, John Cohen wrote:
No, for two reasons:-
You'd have to enter a password on the server to copy a file to the client - not possible in an automatically run script. The client can't be 'seen' by the server (when connecting from 'out there on the internet' anyway) so there's nowhere (DNS'wise) to send the file to.Ah, ok. I was thinking with ssh keys installed to connect to the other machine (laptop in your case?). I run duplicity to a remote machine that changes IP, but is always accessible- using ddclient in my case but could be anything. The server machine runs the script, scp's the files across and closes the connection without the need of password authentication.
This would work when the laptop is connecting only across my home LAN (which is one of the cases I want to handle). I do have *some* passwordless keys and the laptop doesn't need to be that secure, on purpose.
However when the laptop connects from 'out on the internet' there isn't a name (or IP) to connect back to, the IP which the ssh environment variables will show is just that of an intermediate system or the WAN address of the router via which the laptop is connecting. Since it usually won't be 'my' router I can't set up address translation or anything.
** end quote [Chris Green]
Security is a nightmare when trying to automate things, and deciding whether to pull from an internal network or push from an external one is better for a particularl security setup adds to the complications. I tend to pull from the internal network where possible on the basis that I am using connections already open rather than opening something extra.
I haven't quite got my head around the timing of your requirement (you mentioned an indeterminate time after the connection), but two suggestions come to mind that may be starting poings:
It's actually a requirement from using mutt. I want mutt to send a file (an HTML part of an E-Mail) when viewed in mutt. Mutt will trigger the send when I view the file. Thus it's essentially at random times after I've made the ssh connection.
One is an ssh tunnel. You can use the -L switch to create a tunnel to the remote location (i.e. if you want to access a web server on a remote network you can ssh into the server and make port 80 on the remote network server available on port 80 on your local machine). That isn't much help here, but you can do the same in reverse with the -R switch. This would allow you to ssh in from the client, making the ssh server on the client available to the server on a local port (other than 22, or whichever you are using). You could then use this from a script on the remote server to scp to your client - possibly using a script called by the same ssh connection. When combined with a password-less ssh key and possibly an extra restricted account on your client that you connect to with the key you can automate the copy without having to enter a password or store it in plain text.
Yes, I think this may be the best way, though (as you say) it does require a passwordless login on the 'client' from the 'server' (or I could set up an rsync server on the client, the data involved is totally non critical/confidential).
Can one use the -R switch in an ordinary ssh connection? I.e. can I set up the reverse tunnel at the same time as getting to a server prompt.
Another option would be to use Ansible. This does involve installing new software on your client, but the nice thing about Ansible compared to things like Puppet is that you don't need any additional software at the other end; everything works over a standard ssh connection. There are commands within Ansible that will handle the copying.
Ansible looks interesting but overkill!
Both or those eliminate the need for opening up ports on routers, as well as avoiding the need for the server to have an address to connect to. They are more the client pulling the file from the server than the server sending the file though (all be it in both cases the server is technically sending).