openssh unix dev - Apr 2012 - 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

Dotan Cohen <dotancohen at gmail.com> 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.no

On Mon, Apr 30, 2012 at 18:39, Dag-Erling Sm?rgrav <des at des.no>
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

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.muc.de
fax: +49-89-35655025                        gert at
net.informatik.tu-muenchen.de

On Mon, May 14, 2012 at 10:02 AM, John Olsson M
<john.m.olsson at ericsson.com> 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

On 14/05/12 09:02, John Olsson M 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)...
>
> /John
If you have shell in the server, and are able to run the cp2local
command, you could presumably also run cat <file> and copy files that
way. So not really a security hole.
But you raise a good point in that opening a sftp connection in the same
ssh session may not be equivalent to the view through the shell.
Maybe cp2local should simply pass the descriptor to a unix socket (or
equivalent, the cp2local connection would be obsiously implementation
defined).