The instructions in this article should work, but they're more complicated than necessary maybe. If you don't have `scp`, you can usually just do something like this:

    ssh HOST cat remote_file > local_file

NRClark, I mention in the first two paragraphs of my blog post that the SSH gateway in between forbids execution of remote commands without a login shell, so your solution is not going to work in this environment.

My solution in these cases:

    ssh HOST tar cjf - /path/to/folder | tar xjf -

Basically I ask `ssh` to execute `tar` on the remote host to create a compressed archive. `ssh` will output the archive contents on the local host; this data is then passed on to a local `tar` for extraction.

Silviot, I mention in my blog post that the SSH gateway in between forbids execution of remote commands without a login shell, so your solution is not going to work in such an environment.

This seems like a CTF trick. If I were faced with this problem, I would do an SSH local port forward, and then just `wget` the file, hosted locally with `python -m SimpleHTTPServer`.

Djent, I mentioned in my blog post that there is an SSH gateway in between that blocks port forwarding, so your solution is not going to work.

For example, say, I run the following command:

    ssh -L 9000:127.0.0.1:8000 HOST

Now when I visit `http://127.0.0.1:9000/` on my local system, I get a "connection reset by peer" error. At the same time, on the terminal where I have set up the port forward with the ssh command above, I get this error:

    open failed: unknown channel type

The SSH gateway forbids port forwarding as well.

Honestly, I find it distasteful to have to spend time working around somebody's incompetence at securing systems.

Doing it on your time means you delay delivering on your project and you let whoever did this get away with wasting everybody elses time.

Susam, Your patience in (re-)explaining this constraint to everyone in this thread who thinks you don't know your way around standard Unix tools is impressive. :-)

> Honestly, I find it distasteful to have to spend time working around somebody's incompetence at securing systems.

> Doing it on your time means you delay delivering on your project and you let whoever did this get away with wasting everybody elses time.

Lmilcin,

While it may be distasteful, what's the alternative? Refusing on principle to use a system configured in a way you don't like is way more likely to hurt you than it is to hurt anyone else, especially the person who configured the system.

Even if you are doing work for someone else (which, I think, is not indicated in the post), so that that person will be affected by your principled refusal, there's no guarantee that they're the ones who misconfigured the environment in which you're operating.

Really nice article. I never thought such things can be done. A use case that I can think of is logging SSH sessions and see what I've done with them.