Transferring file to local machine when SSHing into a foreign box

Dotan Cohen dotancohen at gmail.com
Mon May 14 23:30:42 EST 2012


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


More information about the openssh-unix-dev mailing list