Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

Transferring file to local machine when SSHing into a foreign box

 

 

First page Previous page 1 2 Next page Last page  View All OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


dotancohen at gmail

Apr 30, 2012, 6:55 AM

Post #1 of 34 (2536 views)
Permalink
Transferring file to local machine when SSHing into a foreign box

One can log into a remote shell via SSH, and one can use an FTP
application to log in via SFTP using the same credentials over SSH.
Why then, can one not initiate a file transfer from the remote host to
the local host when logged into a shell via SSH?

I know that I could use scp or rsync to move the files, but the
requires authenticating which is not something that I can always do
from the host. From my limited understanding the existing SSH
connection is all that should be needed, as SSH has file transfer
capability.

Apparently quite a few people are interested in this feature, here is
one example from many that can be found of people requesting this
functionality:
http://stackoverflow.com/questions/440524/ssh-a-way-to-transfer-files-without-opening-a-separate-sftp-session

Would it be appropriate for me to file a feature request on the
OpenSSH bugzilla, considering that I am not able to write the code to
implement the feature?

Thanks.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


des at des

Apr 30, 2012, 8:39 AM

Post #2 of 34 (2483 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Dotan Cohen <dotancohen [at] gmail> writes:
> One can log into a remote shell via SSH, and one can use an FTP
> application to log in via SFTP using the same credentials over SSH.
> Why then, can one not initiate a file transfer from the remote host to
> the local host when logged into a shell via SSH?

man ssh_config, search for ControlMaster.

DES
--
Dag-Erling Smørgrav - des [at] des
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

Apr 30, 2012, 11:49 AM

Post #3 of 34 (2470 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Mon, Apr 30, 2012 at 18:39, Dag-Erling Smørgrav <des [at] des> wrote:
> man ssh_config, search for ControlMaster.
>

Thank you Dag!

The ControlMaster option allows for the reuse of a session, but does
not provide any nice "cpLocal" command for easily moving files from
the remote machine to local (or vice versa).

Rereading my original post, I see that I did not explicitly state that
such an easy command was my goal. I often SSH into different machines
and many of those I cannot modify with aliases and such. However, a
facility for easily transferring files from / to these machines would
be very nice.

Thanks.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

May 8, 2012, 2:38 PM

Post #4 of 34 (2449 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On 30/04/12 20:49, Dotan Cohen wrote:
> On Mon, Apr 30, 2012 at 18:39, Dag-Erling Smørgrav <des [at] des> wrote:
>> man ssh_config, search for ControlMaster.
> Thank you Dag!
>
> The ControlMaster option allows for the reuse of a session, but does
> not provide any nice "cpLocal" command for easily moving files from
> the remote machine to local (or vice versa).
If you have a master connection, you can open another terminal in local
and do a sftp/rsync from that, which would go through that connection.


> Rereading my original post, I see that I did not explicitly state that
> such an easy command was my goal. I often SSH into different machines
> and many of those I cannot modify with aliases and such. However, a
> facility for easily transferring files from / to these machines would
> be very nice.
How do you expect such command to work?
You could reconfigure your current connection adding a tunnel, and then
use that for transfering the files, but you'd still need a local daemon
(eg. ftpd) where to drop them.


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

May 8, 2012, 3:10 PM

Post #5 of 34 (2457 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Dotan Cohen wrote:
> The ControlMaster option allows for the reuse of a session, but does
> not provide any nice "cpLocal" command for easily moving files from
> the remote machine to local (or vice versa).

It allows sftp on your local machine to reuse a session to a remote
machine.


But in the other direction things are a lot more complicated:

1. Your local machine runs an SSH client.
2. Your remote machine runs the SSH server.

The SSH protocol allows the SSH server to spontaneously open a
channel back to the SSH client, so cpLocal could somehow signal
the SSH server to open such a channel, but the problem is that your
SSH client has no idea what to do with this new channel.

The SFTP protocol is well-specified, but it is only specified in the
context of an SSH client requesting an SSH server to start the sftp
subsystem in a channel which the client just opened.

While it is legal in the SSH protocol for the SSH server to try to
open an sftp channel to the SSH client, the SSH client does not
really know how to accomodate this wish. I think you agree that it
is also undesirable from a security point of view.


I'll reply with a counter-question:

How would you like the user-interface on the client side to work for
the cpLocal feature?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 12, 2012, 10:45 AM

Post #6 of 34 (2433 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Wed, May 9, 2012 at 12:38 AM, Ángel González <keisial [at] gmail> wrote:
>> Rereading my original post, I see that I did not explicitly state that
>> such an easy command was my goal. I often SSH into different machines
>> and many of those I cannot modify with aliases and such. However, a
>> facility for easily transferring files from / to these machines would
>> be very nice.
>
> How do you expect such command to work?
>

I imagine something like this:
The user would run a command such as the following:
remoteServer$ cp2local someFile.c
The SSH server on the remote host would then push the file to the SSH
client running locally just as if scp had been used, but it would
reuse the existing connection. The local SSH client would then write
the file just as it would have had scp been used.



> You could reconfigure your current connection adding a tunnel, and then
> use that for transfering the files, but you'd still need a local daemon
> (eg. ftpd) where to drop them.

I am sure that you recognise the added complexity for the user by way
of the workaround that you mention. From a technical point of view,
OpenSSH already has the components necessary to make this a simple
procedure.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


bert.wesarg at googlemail

May 12, 2012, 2:05 PM

Post #7 of 34 (2449 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sat, May 12, 2012 at 7:45 PM, Dotan Cohen <dotancohen [at] gmail> wrote:
> On Wed, May 9, 2012 at 12:38 AM, Ángel González <keisial [at] gmail> wrote:
>> You could reconfigure your current connection adding a tunnel, and then
>> use that for transfering the files, but you'd still need a local daemon
>> (eg. ftpd) where to drop them.
>
> I am sure that you recognise the added complexity for the user by way
> of the workaround that you mention. From a technical point of view,
> OpenSSH already has the components necessary to make this a simple
> procedure.

It's not. Because SSH does not monitor what commands you execute in
the remote shell and the shell does not know that it's a remote shell.
Your SSH client just sends your locally typed key strokes to the
remote terminal. Maybe the command line activated via ~C (see the
escape char option in ssh(1)) could be used to initiate file
transfers.

Bert
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

May 12, 2012, 3:45 PM

Post #8 of 34 (2447 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On 12/05/12 19:45, Dotan Cohen wrote:
> I imagine something like this: The user would run a command such as
> the following: remoteServer$ cp2local someFile.c The SSH server on the
> remote host would then push the file to the SSH client running locally
> just as if scp had been used, but it would reuse the existing
> connection. The local SSH client would then write the file just as it
> would have had scp been used.
The big problem with that approach is that you're trusting your
credentials to the remote side.
If I ssh from A to B, and B is compromised, it shouldn't be able to
compromise A.
Can you provide an alternative usage without that hole?

It may be an issue to be solved in a client, which allowed you to switch
between console and file view (sftp).

>> You could reconfigure your current connection adding a tunnel, and then
>> use that for transfering the files, but you'd still need a local daemon
>> (eg. ftpd) where to drop them.
> I am sure that you recognise the added complexity for the user by way
> of the workaround that you mention. From a technical point of view,
> OpenSSH already has the components necessary to make this a simple
> procedure.
Sure. I was throwing out some ideas which could, perhaps, turn out to be
useful (eg. for doing it in a script).
Regards

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 13, 2012, 12:49 AM

Post #9 of 34 (2435 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sun, May 13, 2012 at 12:05 AM, Bert Wesarg
<bert.wesarg [at] googlemail> wrote:
>> I am sure that you recognise the added complexity for the user by way
>> of the workaround that you mention. From a technical point of view,
>> OpenSSH already has the components necessary to make this a simple
>> procedure.
>
> It's not. Because SSH does not monitor what commands you execute in
> the remote shell and the shell does not know that it's a remote shell.
>

I am not suggesting that the local SSH client monitor what is being
typed into the shell. Rather, the SSH server on the remote host would
have a command cpLocal that would wrap scp with all the needed
connection information. If the user is not connected via SSH then
cpLocal could throw an error.



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 13, 2012, 12:52 AM

Post #10 of 34 (2436 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sun, May 13, 2012 at 1:45 AM, Ángel González <keisial [at] gmail> wrote:
> The big problem with that approach is that you're trusting your
> credentials to the remote side.
> If I ssh from A to B, and B is compromised, it shouldn't be able to
> compromise A.
> Can you provide an alternative usage without that hole?
>

Sure: just reuse the existing connection. Just like how sftp works.


> It may be an issue to be solved in a client, which allowed you to switch
> between console and file view (sftp).
>

That would be nice.


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

May 13, 2012, 3:06 AM

Post #11 of 34 (2447 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On 13/05/12 09:52, Dotan Cohen wrote:
> On Sun, May 13, 2012 at 1:45 AM, Ángel González <keisial [at] gmail> wrote:
>> The big problem with that approach is that you're trusting your
>> credentials to the remote side.
>> If I ssh from A to B, and B is compromised, it shouldn't be able to
>> compromise A.
>> Can you provide an alternative usage without that hole?
> Sure: just reuse the existing connection. Just like how sftp works.
???
If a command such as the proposed cp2local is able to write arbitrary
files in the local end*, it allows such compromise.

* For instance, a profile file run by your shell each time you log in, see
CVE-2010-2252.


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 13, 2012, 3:41 AM

Post #12 of 34 (2439 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sun, May 13, 2012 at 1:06 PM, Ángel González <keisial [at] gmail> wrote:
> If a command such as the proposed cp2local is able to write arbitrary
> files in the local end*, it allows such compromise.
>

I understand that you feel that allowing the remote server to write
(not execute) arbitrary files to the local machine is a security risk.
I also assume that you do not feel that scp being able to write
arbitrary files to the local machine is not a security risk because it
requires the explicit typing of a username and password, or better yet
of a keypair. Please confirm or deny if my assumption is correct.

I counter that the proposed cp2Local is no more of a security risk
than scp because it _also_ requires the user of a username/password or
keypair to explicitly express intent (establishing the initial SSH
connection). Assuming the worst-case scenario that this feature is
enabled and the user SSHes into a compromised box, the user will be
only downloading unwanted, malicious files to his local machine, he
will not be executing them automatically. This is no different than
visiting a webpage. In fact, this is safer: web browsers _can_ run
arbitrary code in the form of Javascript.

You could argue that the web browser downloads to a cache, whereas
cpLocal would download to $HOME. Therefore have it downlaod to a
different directory, Free Desktop has conventions for this, see this
Stack Overflow discussion:
http://unix.stackexchange.com/a/15238/9760

In short, I recognise the problem of allowing the remote machine
access to write to your local machine. However, this has been a
problem with many other technologies (www, email, ftp, etc.) and it is
a solved issue in the general sense. That is, best practices and
damage-mitigation strategies have already been established.

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


gert at greenie

May 13, 2012, 4:06 AM

Post #13 of 34 (2435 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Hi,

On Sun, May 13, 2012 at 01:41:31PM +0300, Dotan Cohen wrote:
> I counter that the proposed cp2Local is no more of a security risk
> than scp because it _also_ requires the user of a username/password or
> keypair to explicitly express intent (establishing the initial SSH
> connection). Assuming the worst-case scenario that this feature is
> enabled and the user SSHes into a compromised box, the user will be
> only downloading unwanted, malicious files to his local machine, he
> will not be executing them automatically. This is no different than
> visiting a webpage. In fact, this is safer: web browsers _can_ run
> arbitrary code in the form of Javascript.

"unwanted, malicious files" could be .ssh/authorized_keys, .shosts,
.profile / .bashrc, etc. - which might not be executed right away, but
will give the attacker interesting options to attack the original client
machine.

[..]
> In short, I recognise the problem of allowing the remote machine
> access to write to your local machine. However, this has been a
> problem with many other technologies (www, email, ftp, etc.) and it is
> a solved issue in the general sense. That is, best practices and
> damage-mitigation strategies have already been established.

Actually, none of these technologies allow downloading arbitrary files
to the client machine, using server-controlled file names, just by
logging into a malicious server.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

May 13, 2012, 6:47 AM

Post #14 of 34 (2439 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On 13/05/12 12:41, Dotan Cohen wrote:
> On Sun, May 13, 2012 at 1:06 PM, Ángel González <keisial [at] gmail> wrote:
>> If a command such as the proposed cp2local is able to write arbitrary
>> files in the local end*, it allows such compromise.
>>
> I understand that you feel that allowing the remote server to write
> (not execute) arbitrary files to the local machine is a security risk.
Yes

> I also assume that you do not feel that scp being able to write
> arbitrary files to the local machine is not a security risk because it
> requires the explicit typing of a username and password, or better yet
> of a keypair. Please confirm or deny if my assumption is correct.
No. It is not a security risk because the user explicitely and
unambiguously provides the target filename.


> I counter that the proposed cp2Local is no more of a security risk
> than scp because it _also_ requires the user of a username/password or
> keypair to explicitly express intent (establishing the initial SSH
> connection).
Connecting to a malicious host != downloading files.

> Assuming the worst-case scenario that this feature is
> enabled and the user SSHes into a compromised box, the user will be
> only downloading unwanted, malicious files to his local machine,
...and potentially getting valuable data overwritten
> he will not be executing them automatically.
Unless the arbitrary name the file is saved as, is one which lead to
other programs to automatically execute it.

> This is no different than visiting a webpage. In fact, this is safer: web browsers _can_ run
> arbitrary code in the form of Javascript.
JavaScript runs in a sandbox and can't modify your files.
A better analogy would be a document macro.

You open the document. But that doesn't mean you want to allow its macro
to spread to all your documents and email new copies to your contact book.


> You could argue that the web browser downloads to a cache, whereas
> cpLocal would download to $HOME. Therefore have it downlaod to a
> different directory, Free Desktop has conventions for this, see this
> Stack Overflow discussion:
> http://unix.stackexchange.com/a/15238/9760
I usually wouldn't want to get it to a Download folder. However, that
would indeed solve the security issue.

I assume you change your request to a
cp2local <file>
command, which copies <file> into $HOME/Downloads
(or another folder configured in ssh_config), and the user is
responsible for moving it from there to wherever they want in the local
folder?


> In short, I recognise the problem of allowing the remote machine
> access to write to your local machine. However, this has been a
> problem with many other technologies (www, email, ftp, etc.) and it is
> a solved issue in the general sense. That is, best practices and
> damage-mitigation strategies have already been established.
The CVE that I provided (the web server being able to control the
destination filename), was fixed in wget by disabling that feature by
default :)


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 13, 2012, 6:59 AM

Post #15 of 34 (2438 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sun, May 13, 2012 at 2:06 PM, Gert Doering <gert [at] greenie> wrote:
> "unwanted, malicious files" could be .ssh/authorized_keys, .shosts,
> .profile / .bashrc, etc. - which might not be executed right away, but
> will give the attacker interesting options to attack the original client
> machine.
>

Let's assume that a compromised machine pushes a malicious file called
authorized_keys. It gets put in the user's Downloads directory, or in
the case of a misconfigured configuration gets put in $HOME. Now what?
The user would have to explicitly place that file in another location
for it to do any harm.


>> In short, I recognise the problem of allowing the remote machine
>> access to write to your local machine. However, this has been a
>> problem with many other technologies (www, email, ftp, etc.) and it is
>> a solved issue in the general sense. That is, best practices and
>> damage-mitigation strategies have already been established.
>
> Actually, none of these technologies allow downloading arbitrary files
> to the client machine, using server-controlled file names, just by
> logging into a malicious server.
>

I see the point about the file names. Actually, web browsers _do_
allow arbitrary file names by using an unrecognised (by the browser)
MIME type, though by default in that case the user must accept the
download. If the problem is the server-specified filename, then
perhaps a client-side confirmation is appropriate. How do you propose
that work, from a UI perspective?


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 13, 2012, 7:32 AM

Post #16 of 34 (2445 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Sun, May 13, 2012 at 4:47 PM, Ángel González <keisial [at] gmail> wrote:
>> I understand that you feel that allowing the remote server to write
>> (not execute) arbitrary files to the local machine is a security risk.
> Yes
>
>> I also assume that you do not feel that scp being able to write
>> arbitrary files to the local machine is not a security risk because it
>> requires the explicit typing of a username and password, or better yet
>> of a keypair. Please confirm or deny if my assumption is correct.
> No. It is not a security risk because the user explicitely and
> unambiguously provides the target filename.
>

I see. I address the filename issue in a reply to Gert. By analogy
with the web browser (which under certain condition prompts the user
to save a file in a "main" directory with a server-choosen filename),
there could be a client-side prompt to confirm / deny the cpLocal
command which was run on the host.


>> I counter that the proposed cp2Local is no more of a security risk
>> than scp because it _also_ requires the user of a username/password or
>> keypair to explicitly express intent (establishing the initial SSH
>> connection).
> Connecting to a malicious host != downloading files.
>

Correct, but downloading files is the only new functionality that we
are discussing. All other attack vectors are identical to current SSH
(without the feature under discussion).


>> Assuming the worst-case scenario that this feature is
>> enabled and the user SSHes into a compromised box, the user will be
>> only downloading unwanted, malicious files to his local machine,
>
> ...and potentially getting valuable data overwritten

Then the prompt will mitigate this, just as the web browser
file-download prompt.


>> he will not be executing them automatically.
>
> Unless the arbitrary name the file is saved as, is one which lead to
> other programs to automatically execute it.
>

Again, this is no more of a risk than downloading files with the web browser.


>> This is no different than visiting a webpage. In fact, this is safer: web browsers _can_ run
>> arbitrary code in the form of Javascript.
>
> JavaScript runs in a sandbox and can't modify your files.
> A better analogy would be a document macro.
>

Fine, then.


> You open the document. But that doesn't mean you want to allow its macro
> to spread to all your documents and email new copies to your contact book.
>

How is that any more of a concern if the file is acquired via scp vs.
being downloaded in a web browser?


>> You could argue that the web browser downloads to a cache, whereas
>> cpLocal would download to $HOME. Therefore have it downlaod to a
>> different directory, Free Desktop has conventions for this, see this
>> Stack Overflow discussion:
>> http://unix.stackexchange.com/a/15238/9760
> I usually wouldn't want to get it to a Download folder. However, that
> would indeed solve the security issue.
>
> I assume you change your request to a
>  cp2local <file>
> command, which copies <file> into $HOME/Downloads
>  (or another folder configured in ssh_config), and the user is
> responsible for moving it from there to wherever they want in the local
> folder?
>

That would be terrific.


>> In short, I recognise the problem of allowing the remote machine
>> access to write to your local machine. However, this has been a
>> problem with many other technologies (www, email, ftp, etc.) and it is
>> a solved issue in the general sense. That is, best practices and
>> damage-mitigation strategies have already been established.
> The CVE that I provided (the web server being able to control the
> destination filename), was fixed in wget by disabling that feature by
> default :)
>
>

Actually, modelling the defaults and options on the wget defaults and
options would be terrific. However, in this case there is no URL, and
the file has to have _some_ name, so I suggest that the server
"suggest" a filename and that the prompts allow it to be overwritten.

Are you familiar with VIM's little popup windows on the bottom of the
screen, such as when typing :marks or :ls with multiple buffers? I do
know know what that feature is called, so I'll refer to it as a
VIM-popup here.

As we have described it, the cpLocal feature would work something like this:

me [at] loca:~$ ls
file1 file2
me [at] loca:~$ ssh anotherMe [at] remot
anotherMe [at] remot:~$ ls
document1 document2
anotherMe [at] remot:~$ cpLocal document1

---------------------------------- <-- Here opens a "VIM-window" (see above)
| me [at] loca: Download document1? |
| [y/N/r/l]? | <-- 'r' is Rename, 'l' is Choose Location

anotherMe [at] remot:~$ exit
me [at] loca:~$ ls
document1 file1 file2
me [at] loca:~$


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


john.m.olsson at ericsson

May 14, 2012, 12:02 AM

Post #17 of 34 (2451 views)
Permalink
RE: Transferring file to local machine when SSHing into a foreign box [In reply to]

Hi,


> I imagine something like this:
> The user would run a command such as the following:
> remoteServer$ cp2local someFile.c
> The SSH server on the remote host would then push the file to the
> SSH client running locally just as if scp had been used, but it
> would reuse the existing connection. The local SSH client would
> then write the file just as it would have had scp been used.

You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).

What would a path to a local file look like in this context?

I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via SFTP (since it is chrooted)...


/John
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 14, 2012, 2:55 AM

Post #18 of 34 (2437 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Mon, May 14, 2012 at 10:02 AM, John Olsson M
<john.m.olsson [at] ericsson> wrote:
> You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on
> the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another
> chrooted directory than the SSH subsystem).
>
> What would a path to a local file look like in this context?
>

The feature would obviously not be available in the SFTP context. For
one thing, the feature requires a remote server script / command
cpLocal which initiates the transfer and in SFTP there is no access to
scripts / commands.


> I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via
> SFTP (since it is chrooted)...
>

If the user has access to read a file in a BASH shell then what is to
prevent him from copying the text of that file right from his
terminal? In fact, that is exactly what I have been doing and is quite
the reason for suggesting the download feature.



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


sdaoden at googlemail

May 14, 2012, 3:23 AM

Post #19 of 34 (2436 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

John Olsson M <john.m.olsson [at] ericsson> wrote:

| > I imagine something like this:
| > The user would run a command such as the following:
| > remoteServer$ cp2local someFile.c
| > The SSH server on the remote host would then push the file to the
| > SSH client running locally just as if scp had been used, but it
| > would reuse the existing connection. The local SSH client would
| > then write the file just as it would have had scp been used.
|
| You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).
|
| What would a path to a local file look like in this context?
|
| I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via SFTP (since it is chrooted)...

As i understood him (unfortunately i've dropped the mail after
i've got the impression this will not make it anyway, sorry!) he
thought about something like

myself [at] local-hos$ ssh myself [at] host-over-ss
myself [at] host-over-ss$ ~Copy_file path_on_local-host path(_on_host-over-ssh)

Why should this open a security hole, given that
myself [at] host-over-ss has proper permissions for
path_on_host-over-ssh? E.g., the session can do

myself [at] host-over-ss$ echo $(date) > path(_on_host-over-ssh)

The problem i see however is that there will be no filename
completion for at least path_on_local-host.

| /John

--steffen
Forza Figa!
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


john.m.olsson at ericsson

May 14, 2012, 3:33 AM

Post #20 of 34 (2450 views)
Permalink
RE: Transferring file to local machine when SSHing into a foreign box [In reply to]

> If the user has access to read a file in a BASH shell then
> what is to prevent him from copying the text of that file
> right from his terminal? In fact, that is exactly what I
> have been doing and is quite the reason for suggesting the
> download feature.

You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.

This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).

The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.


If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?

I'm just raising this issue, since not all nodes that offer SSH access looks and behave the same way. Not everything is a Bash shell. :)


/John

-----Original Message-----
From: Dotan Cohen [mailto:dotancohen [at] gmail]
Sent: den 14 maj 2012 11:56
To: John Olsson M
Cc: ngel Gonzlez; openssh-unix-dev [at] mindrot
Subject: Re: Transferring file to local machine when SSHing into a foreign box

On Mon, May 14, 2012 at 10:02 AM, John Olsson M <john.m.olsson [at] ericsson> wrote:
> You also need to consider the case where the user is *not* running a
> normal (like TCSH, Bash, ZSH, ...) shell on the server and where the
> file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).
>
> What would a path to a local file look like in this context?
>

The feature would obviously not be available in the SFTP context. For one thing, the feature requires a remote server script / command cpLocal which initiates the transfer and in SFTP there is no access to scripts / commands.


> I see this as a security hole since you suddenly get acess to files
> via SSH which you do not get access to via SFTP (since it is chrooted)...
>

If the user has access to read a file in a BASH shell then what is to prevent him from copying the text of that file right from his terminal? In fact, that is exactly what I have been doing and is quite the reason for suggesting the download feature.



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


gert at greenie

May 14, 2012, 4:23 AM

Post #21 of 34 (2438 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Hi,

On Mon, May 14, 2012 at 12:23:30PM +0200, Steffen Daode Nurpmeso wrote:
> myself [at] local-hos$ ssh myself [at] host-over-ss
> myself [at] host-over-ss$ ~Copy_file path_on_local-host path(_on_host-over-ssh)
>
> Why should this open a security hole, given that
> myself [at] host-over-ss has proper permissions for
> path_on_host-over-ssh?

If you're just talking about from-local-to-remote, one thing that comes
to mind is "an evil remote host stealing your local files without your
doing".

So while I can understand the convenience factor of this, making it
properly secure (like "only operate out of a well-defined quarantaine
folder on local-host, and do not permit absolute or relative path names
with '..' in them") are likely ging to make this inconvenient enough
to then not-use it...

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

May 14, 2012, 6:02 AM

Post #22 of 34 (2451 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Dotan Cohen wrote:
> I understand that you feel that allowing the remote server to write
> (not execute) arbitrary files to the local machine is a security risk.

Correct. It's completely unacceptable in the general case.


> I also assume that you do not feel that scp being able to write
> arbitrary files to the local machine is not a security risk because it
> requires the explicit typing of a username and password, or better yet
> of a keypair. Please confirm or deny if my assumption is correct.

Incorrect. What you clearly do not understand is that scp being
invoked is an explicit action taken on the client, whereas something
happening automatically on the client in response to something being
invoked on the server is quite different.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

May 14, 2012, 6:26 AM

Post #23 of 34 (2437 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

Dotan Cohen wrote:
> As we have described it, the cpLocal feature would work something
> like this:
>
> me [at] loca:~$ ls
> file1 file2
> me [at] loca:~$ ssh anotherMe [at] remot
> anotherMe [at] remot:~$ ls
> document1 document2
> anotherMe [at] remot:~$ cpLocal document1
>
> ---------------------------------- <-- Here opens a "VIM-window" (see above)
> | me [at] loca: Download document1? |
> | [y/N/r/l]? | <-- 'r' is Rename, 'l' is Choose Location
>
> anotherMe [at] remot:~$ exit
> me [at] loca:~$ ls
> document1 file1 file2
> me [at] loca:~$

Thanks for answering my question about user interface. Unfortunately
it seems that you are not so aware of how the systems you use
actually work, and your proposal further does not address the very
important concerns about a remote system being able to control a
local client.

What you call the "VIM-popup" can not be created by the local SSH
client because it is not operating the terminal in a windowed mode.

You would have to study a bit of systems programming and with
particular focus on how applications can interact with their
controlling terminal to have a good background for finding a good
yet viable solution to this user interface problem.

And as I mentioned the above has a rather severe security problem.
The above can be abused by a remote server to make the logged-in
session unusable. Re-using your analogy with web browsers, think of
having a prompt enabled about approving cookies while navigating to
yahoo.com or cnn.com or some other site with lots of cookies and
banners. The client effectively becomes useless due to all the
prompts.

Now, the ~C command line was mentioned. This can be used to realize a
feature similar to what you ask for, but with some differences, and a
few technical problems to solve:

* difference: file transfer requests must always be initiated manually
on the client in the ~C command line.
* problem: the client command line does not know the cwd of the
remote shell, meaning that relative paths can not be used, which is
somehow the whole point of this proposal.

A further variant on this is where on the remote system a file
transfer is prepared with the semantics of the proposed cp2local
command, but no transfer begins until an explicit ~C command (or
perhaps ~D for download) is entered on the client to actually perform
the transfer. There will be no notification from the client that a
transfer is pending, because in fact nothing is pending, the transfer
has only been prepared on the remote side, and will still be
initiated only by the client, just that on the remote server there is
now the marker running which identifies what should be transfered.

A technical problem still remains; how all this should work in terms
of the SSH protocol and what exactly the marker command (cp2local)
does.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 14, 2012, 6:30 AM

Post #24 of 34 (2451 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Mon, May 14, 2012 at 1:33 PM, John Olsson M
<john.m.olsson [at] ericsson> wrote:
>> If the user has access to read a file in a BASH shell then
>> what is to prevent him from copying the text of that file
>> right from his terminal? In fact, that is exactly what I
>> have been doing and is quite the reason for suggesting the
>> download feature.
>
> You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.
>

So the feature does not have to be exposed under those connection
conditions. Only expose the feature when connecting to a shell
instance.


> This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).
>

So this interface doesn't even need the feature. Terrific. I don't
understand what the problem is.


> The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.
>

If the administrator of the machine provides the user with read access
to a file via BASH or any other shell in SSH, then the user can
provide himself with the contents of the file. Their currently is no
straightforward method, but there exist painstaking methods and if
that is not considered a security hole (copy-pasta from console) then
the proposed method is neither a security hole. In other words, the
proposed method exposes no information that is not already exposed.


> If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?
>

How is this any different than the user typing "vim /etc/password" in
a shell via SSH and then copying the contents of the file from his
terminal?


> I'm just raising this issue, since not all nodes that offer SSH access looks and behave the same way. Not everything is a Bash shell. :)
>

I appreciate that you raise the issue! I expect that there will be
contingencies that I do not think of, and it is better to work them
out right now. I thank you for providing your input, _especially_ when
it mentions things that I have not thought of.


Also, presumably there will be configuration options to disable this
feature, something like "PermitCpLocal".

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dotancohen at gmail

May 14, 2012, 6:38 AM

Post #25 of 34 (2447 views)
Permalink
Re: Transferring file to local machine when SSHing into a foreign box [In reply to]

On Mon, May 14, 2012 at 2:23 PM, Gert Doering <gert [at] greenie> wrote:
> If you're just talking about from-local-to-remote, one thing that comes
> to mind is "an evil remote host stealing your local files without your
> doing".
>
> So while I can understand the convenience factor of this, making it
> properly secure (like "only operate out of a well-defined quarantaine
> folder on local-host, and do not permit absolute or relative path names
> with '..' in them") are likely ging to make this inconvenient enough
> to then not-use it...
>

Actually, I personally am most interested in the remote-to-local bit
and that is all that has been discussed so far.

I agree that the local-to-remote feature would be nice as well, but
with the necessity that the remote side is initiating, I agree that it
could be problematic. How about only initiating a transfer on the
remote side, but having the local side decide which file. Like this:

me [at] loca:~$ ls
file1 file2
me [at] loca:~$ ssh anotherMe [at] remot
anotherMe [at] remot:~$ ls
document1 document2
anotherMe [at] remot:~$ cpFromLocal
------------------------------------ <-- Here opens a "VIM-window"
(see previous message)
| me [at] loca: Please browse to file |
| $ ls |
| file1 file2 |
| $ send file1 |

anotherMe [at] remot:~$ ls
document1 document2 file1
anotherMe [at] remot:~$ exit
me [at] loca:~$ ls
file1 file2
me [at] loca:~$



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

First page Previous page 1 2 Next page Last page  View All OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.