Comments on File Transfer with SSH, Tee, and Base64

Post Comment

NRClark said:

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
17 Sep 2020 15:25 GMT (#1 of 10 comments)

Susam Pal said:

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.

17 Sep 2020 15:27 GMT (#2 of 10 comments)

Silviot said:

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.

17 Sep 2020 15:34 GMT (#3 of 10 comments)

Susam Pal said:

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.

17 Sep 2020 15:35 GMT (#4 of 10 comments)

Djent said:

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.

17 Sep 2020 15:35 GMT (#5 of 10 comments)

Susam Pal said:

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.

17 Sep 2020 15:36 GMT (#6 of 10 comments)

Lmilcin said:

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.

17 Sep 2020 15:55 GMT (#7 of 10 comments)

JadeNB said:

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. :-)

17 Sep 2020 16:13 GMT (#8 of 10 comments)

JadeNB said:

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.

17 Sep 2020 16:19 GMT (#9 of 10 comments)

Hai Vu said:

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.

23 Sep 2020 11:09 GMT (#10 of 10 comments)
Post Comment