I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
I need the server machine to be able to do this from a script running on the server at some indeterminate time after the ssh connection has been made.
The only remotely possible way I can think of to do this is to run something via the 'LocalCommand' option in the client ssh configuration. However, at the moment, that's about as far as I can get. I can't think of a way of actually doing it at the moment.
The best I can come up with is to have a script (run as a LocalCommand) that uses sshfs to mount a server directory on the client. Then a server script can simply copy a file to the mounted directory and it will be visible on the client. Job done..., or not.
There are problems with this however. Firstly as I often have several ssh connections running at the same time there needs to be some way to prevent the LocalCommand running multiple sshfs instances. This isn't too bad to overcome but the second issue is how to pull down the sshfs connection when the last ssh exits, at present I can't see any way to do this, there isn't the equivalent of LocalCommand which runs when a connection is about to be closed.
Does anyone have any ideas which might help?
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
https://www.howtoforge.com/reverse-ssh-tunneling
Kind Regards Andrew
On 31/10/2018 18:56, Chris Green wrote:
I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
I need the server machine to be able to do this from a script running on the server at some indeterminate time after the ssh connection has been made.
The only remotely possible way I can think of to do this is to run something via the 'LocalCommand' option in the client ssh configuration. However, at the moment, that's about as far as I can get. I can't think of a way of actually doing it at the moment.
The best I can come up with is to have a script (run as a LocalCommand) that uses sshfs to mount a server directory on the client. Then a server script can simply copy a file to the mounted directory and it will be visible on the client. Job done..., or not.
There are problems with this however. Firstly as I often have several ssh connections running at the same time there needs to be some way to prevent the LocalCommand running multiple sshfs instances. This isn't too bad to overcome but the second issue is how to pull down the sshfs connection when the last ssh exits, at present I can't see any way to do this, there isn't the equivalent of LocalCommand which runs when a connection is about to be closed.
Does anyone have any ideas which might help?
On Thu, Nov 01, 2018 at 09:40:56AM +0000, Andrew Hutchings wrote:
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
I've thought long and hard about using SSH tunnels but I can't quite get my mind round how it would actually work.
The first problem is that it's non-trivial to automatically open an ssh tunnel using a ssh 'LocalCommand' run when doing the initial ssh from client to server (I do want to get the normal ssh connection as well). This probably can be managed though, I've done something similar before,
Then, how do you automate the file copy back through the reverse tunnel? It would need a passwordless ssh connection and I'm not to keen on that security-wise.
Finally (and this is probably the most difficult bit) how do you pull down the reverse tunnel when you've finished? If it has (as is likely) used the ssh ControlMaster connection created by the initial ssh then that will hang until you kill the reverse tunnel ssh. This is basically the same issue as I originally described using sshfs (which doesn't have the password issue).
On 01/11/2018 14:05, Chris Green wrote:
On Thu, Nov 01, 2018 at 09:40:56AM +0000, Andrew Hutchings wrote:
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
I've thought long and hard about using SSH tunnels but I can't quite get my mind round how it would actually work.
The first problem is that it's non-trivial to automatically open an ssh tunnel using a ssh 'LocalCommand' run when doing the initial ssh from client to server (I do want to get the normal ssh connection as well). This probably can be managed though, I've done something similar before,
Then, how do you automate the file copy back through the reverse tunnel? It would need a passwordless ssh connection and I'm not to keen on that security-wise.
If you are doing something automated push rather than pull based it is likely going to need a keystore somewhere along the line.
Finally (and this is probably the most difficult bit) how do you pull down the reverse tunnel when you've finished? If it has (as is likely) used the ssh ControlMaster connection created by the initial ssh then that will hang until you kill the reverse tunnel ssh. This is basically the same issue as I originally described using sshfs (which doesn't have the password issue).
Hmm... I was thinking the SSH tunnel would be semi-permanent. VPN possible?
Kind Regards
On Thu, Nov 01, 2018 at 02:19:17PM +0000, Andrew Hutchings wrote:
On 01/11/2018 14:05, Chris Green wrote:
On Thu, Nov 01, 2018 at 09:40:56AM +0000, Andrew Hutchings wrote:
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
I've thought long and hard about using SSH tunnels but I can't quite get my mind round how it would actually work.
The first problem is that it's non-trivial to automatically open an ssh tunnel using a ssh 'LocalCommand' run when doing the initial ssh from client to server (I do want to get the normal ssh connection as well). This probably can be managed though, I've done something similar before,
Then, how do you automate the file copy back through the reverse tunnel? It would need a passwordless ssh connection and I'm not to keen on that security-wise.
If you are doing something automated push rather than pull based it is likely going to need a keystore somewhere along the line.
Finally (and this is probably the most difficult bit) how do you pull down the reverse tunnel when you've finished? If it has (as is likely) used the ssh ControlMaster connection created by the initial ssh then that will hang until you kill the reverse tunnel ssh. This is basically the same issue as I originally described using sshfs (which doesn't have the password issue).
Hmm... I was thinking the SSH tunnel would be semi-permanent. VPN possible?
I think you've probably confirmed what I have been finding, I was just hoping there might be an easier/neater way.
When you say '... the SSH tunnel would be semi-permanent." were you thinking it might be brought up when the laptop is turned on as it were? The problem is that I tend to have it permanently turned on and wander around from house to more distant places and back. The ssh tunnel probably won't survive this.
I guess a VPN might be the answer but it seems to be overkill for such a small requirement. It also probably can't handle wandering around.
My problem is that I'm lazy and expect the computer(s) to do all the hard work for me! :-) Thus I use ssh's ControlMaster facility to connect so I only ever have to enter the password once for multiple connections. On the other hand I *don't* want the laptop to automatically connect when turned on as I do disconnect all the ssh connections when I leave it so someone getting access to my laptop *won't* get access to anything else as a result.
On 01/11/2018 14:05, Chris Green wrote:
On Thu, Nov 01, 2018 at 09:40:56AM +0000, Andrew Hutchings wrote:
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
I've thought long and hard about using SSH tunnels but I can't quite get my mind round how it would actually work.
The first problem is that it's non-trivial to automatically open an ssh tunnel using a ssh 'LocalCommand' run when doing the initial ssh from client to server (I do want to get the normal ssh connection as well). This probably can be managed though, I've done something similar before,
Then, how do you automate the file copy back through the reverse tunnel? It would need a passwordless ssh connection and I'm not to keen on that security-wise.
Doesn't need to be passwordless. see http://www.linuxproblem.org/art_9.html
I run backups from host_a as user_a to host_b by running a script on host_a which is started by user_b on host_b with: user_b@host_b ~ $ ssh user_a@host_a  /home/user_a/bin/backup.sh
This runs without the need to enter the passwords as they are stored in the .ssh/authorized_keys files on each host. backup.sh basically runs rsync
Sorry if I've misunderstood the problem.
Nev
On Fri, Nov 02, 2018 at 11:18:29AM +0000, Nev Young wrote:
On 01/11/2018 14:05, Chris Green wrote:
On Thu, Nov 01, 2018 at 09:40:56AM +0000, Andrew Hutchings wrote:
Hi Chris,
I believe reverse SSH tunneling may cover what you need here. You would just need some automated way of keeping the connection up.
I've thought long and hard about using SSH tunnels but I can't quite get my mind round how it would actually work.
The first problem is that it's non-trivial to automatically open an ssh tunnel using a ssh 'LocalCommand' run when doing the initial ssh from client to server (I do want to get the normal ssh connection as well). This probably can be managed though, I've done something similar before,
Then, how do you automate the file copy back through the reverse tunnel? It would need a passwordless ssh connection and I'm not to keen on that security-wise.
Doesn't need to be passwordless. see http://www.linuxproblem.org/art_9.html
This is the same as passwordless in effect, they use keys without a passphrase. So, if you get access to machine A you then automatically have passwordless (passphrphraseless) access to machine B (and any other machine to which machine A accesses using the same key).
I suppose it's better than real 'passwordless' in that you only get passwordless access to machine B from machine A, not from anywhere but it's still not particularly secure, I don't want a situation where someone who gets access to just one of my machines can then access all of them.
Hi Chris,
I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
Could scp not help you here? (sorry if I didn't quite understand!)
cheers,
John
On Thu, Nov 01, 2018 at 09:43:21AM +0000, John Cohen wrote:
Hi Chris,
I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
Could scp not help you here? (sorry if I didn't quite understand!)
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.
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.
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.
*to clarify, in your case you'd need to have an ssh server running on your laptop
On Thu, Nov 01, 2018 at 02:15:50PM +0000, John Cohen wrote:
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.
*to clarify, in your case you'd need to have an ssh server running on your laptop
I do, but see other issues.
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.
** 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:
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.
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.
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).
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).
** Chris Green cl@isbd.net [2018-11-01 19:08]:
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.
Ah, a problem I've looked at in the past. I've tended to manage with a command line browser like Elinks (Lynx, Links or Links2 being alternatives). Browsh looks interesting though, but I'm not sure whether it requires more in terms of graphics capability than you get with an ssh console (some give better graphics support in a local console without a full desktop).
Because I mix and match between various machines with mutt I can pretty much always wait until I'm on a local box to view an HTML mail (the ones without a text part are generally not urgent!). That said, I've just found this page which has some interesting information on it; based on the -R switch and additional configuration. It may prove useful, I plan to explore it when I get time:
Opening attachments on another machine from within mutt https://www.stderr.nl/Blog/Software/Mutt/MuttRemoteAttachments
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.
Yes you can, the default option is to open on a console and the tunnel sits on the back of that connection. I think there is a tweak to the default config to allow a -R to work as it is generally disabled; it is a while since I used it that way round. I often use the -L version though, with the console it opens supporting what I'm doing with the tunnel (generally sorting out a web server config on a remote network).
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!
Yes, not suitable in this situation, but handy for configuration and management. For me it is doing very nicely in automating things that I normally do with an ssh connection without the load of a client agent (helpful to reduce load on things like a Raspberry Pi or low power server), and without the need to change my way of working too drastically (as things like Puppet would given the differences in the way they work).
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).
** end quote [Chris Green]
On Fri, Nov 02, 2018 at 09:41:17AM +0000, Paul Tansom wrote:
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.
Ah, a problem I've looked at in the past. I've tended to manage with a command line browser like Elinks (Lynx, Links or Links2 being alternatives). Browsh looks interesting though, but I'm not sure whether it requires more in terms of graphics capability than you get with an ssh console (some give better graphics support in a local console without a full desktop).
For 99% of HTML mail I use lynx in mutt's pager, it's just the occasional one I want to view in Firefox where this becomes an issue.
Because I mix and match between various machines with mutt I can pretty much always wait until I'm on a local box to view an HTML mail (the ones without a text part are generally not urgent!). That said, I've just found this page which has some interesting information on it; based on the -R switch and additional configuration. It may prove useful, I plan to explore it when I get time:
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.
Yes you can, the default option is to open on a console and the tunnel sits on the back of that connection. I think there is a tweak to the default config to allow a -R to work as it is generally disabled; it is a while since I used it that way round. I often use the -L version though, with the console it opens supporting what I'm doing with the tunnel (generally sorting out a web server config on a remote network).
It's basically working now using the -R (well, actually RemoteForward in the config file). What's nice is that repeating the RemoteForward several times seems to cause no issues (this will happen with multiple ssh calls which I often do).
All I need to sort out now is how the script called from mutt (using .mailcap) sorts out whether the HTML E-Mail needs to be copied locally (i.e. I'm running mutt from my desktop screen) or it needs to be copied to the rmeote machine (I'm running mutt via ssh from my laptop).
Thanks everyone for all the help and suggestions. Just talking through all the possibilities is often a way to figure out something like this.
On Wed, Oct 31, 2018 at 06:56:50PM +0000, Chris Green wrote:
I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
I need the server machine to be able to do this from a script running on the server at some indeterminate time after the ssh connection has been made.
...
Does anyone have any ideas which might help?
If the script is running on a terminal then run screen on the laptop, use sz on the server and screen's zmodem catch support to automatically receive things.
J.
(You didn't ask for a *good* way, or a non-evil way...)
On Thu, Nov 01, 2018 at 02:24:35PM +0000, Jonathan McDowell wrote:
On Wed, Oct 31, 2018 at 06:56:50PM +0000, Chris Green wrote:
I am looking for a way that will allow my ssh 'server' machine (desktop running xubuntu 18.04 at home) to send a file back to the client machine (laptop running xubuntu 18.04 which may be anywhere including behind a firewall etc. and behind NAT).
I need the server machine to be able to do this from a script running on the server at some indeterminate time after the ssh connection has been made.
...
Does anyone have any ideas which might help?
If the script is running on a terminal then run screen on the laptop, use sz on the server and screen's zmodem catch support to automatically receive things.
Would this actually work? Where would sz on the server send the file to (as in machine address)? ... or does it (god forbid!) capture it as a zmodem stream sent to the terminal screen (on thinking about it this is the most likely answer).
-
Andrew Hutchings -
Chris Green -
John Cohen -
Jonathan McDowell -
Nev Young -
Paul Tansom