SCP via pscp and via PuTTY's "Remote Command" option
yawnmoth
this:
So, basically, to get a file via SCP you run "scp -f filename" on the
server. If I try to do that, however, via PuTTY's "Remote Command"
option (as opposed to through pscp) I get this:
The problem I have is this. The second log has PuTTY requesting a
pseudo-terminal (as discussed in RFC4254#section-6.2) whereas the
first log doesn't. Why the difference? Both are using 'exec' as
discussed in RFC4254#section-6.5.
Also, in the first log "scp: warning: Executing scp1" is sent as a
SSH2_MSG_CHANNEL_EXTENDED_DATA packet whereas in the first log it's
sent as a SSH2_MSG_CHANNEL_DATA packet. Why the difference?
I also note how the first log sends out what I'm going to have to call
null packets after every response. Why?
Finally, while the first log has the server sending a
SSH2_MSG_CHANNEL_CLOSE message the second log does not. Indeed, the
second log seems to result in PuTTY perpetually blocking, waiting for
further packets from the server that never arrive.
Simon Tatham
> The problem I have is this. The second log has PuTTY requesting a
> pseudo-terminal (as discussed in RFC4254#section-6.2) whereas the
> first log doesn't. Why the difference?
Because PuTTY is a terminal emulator, so it assumes that if you're
invoking a program through it then you probably wanted to run that
program in a terminal device, so its default is to request a pty.
You can configure it not to, if you prefer that for a given session.
> Also, in the first log "scp: warning: Executing scp1" is sent as a
> SSH2_MSG_CHANNEL_EXTENDED_DATA packet whereas in the first log it's
> sent as a SSH2_MSG_CHANNEL_DATA packet. Why the difference?
Because the Unix pty device folds stdout and stderr together. If you
(successfully) request a pty from a Unix SSH server, you will never
see EXTENDED_DATA on that channel, because the server has no way to
tell which of the terminal output it receives came via stdout and
which via stderr.
(I say 'Unix' there only because that's the one I know for sure. I'd
guess this to be true of other OSes that have ptys.)
> I also note how the first log sends out what I'm going to have to call
> null packets after every response. Why?
Why are you 'going to have to call' them null packets, when you have
a log which would allow you to describe them precisely? What message
type? What content?
> Finally, while the first log has the server sending a
> SSH2_MSG_CHANNEL_CLOSE message the second log does not. Indeed, the
> second log seems to result in PuTTY perpetually blocking, waiting for
> further packets from the server that never arrive.
Probably another side effect of the SSH server using a pty device in
one case and not in the other. Close detection is a bit weird in ptys.
--
Simon Tatham "That all men should be brothers is a
<ana...@pobox.com> dream of people who have no brothers."
Simon Tatham
>> I also note how the first log sends out what I'm going to have to call
>> null packets after every response. Why?
Simon Tatham <ana...@pobox.com> wrote:
> Why are you 'going to have to call' them null packets, when you have
> a log which would allow you to describe them precisely? What message
> type? What content?
Sorry; I'd forgotten that you'd actually posted links to the logs.
Right, you mean the SSH2_MSG_IGNOREs sent by the server after each
CHANNEL_DATA from the client?
I expect those are a traffic analysis defence. In a tty session,
text typed by the user is normally echoed straight back by the
server, so that every outgoing CHANNEL_DATA is immediately followed
by an incoming one. But sometimes that echo is turned off -
particularly, when the user types a password. So if somebody were
watching the encrypted traffic in an SSH session, they could look
for a sequence of short client-to-server CHANNEL_DATAs which had no
immediate response packet, and then they'd be able to guess that
those represented a password - so they'd at least know the length of
the password, and might be able to infer something from the
inter-keystroke timing. So servers adopted a defence in which any
incoming CHANNEL_DATA that _isn't_ sent to a tty device with the
echo mode enabled is immediately responded to with an IGNORE
message, which a traffic analyser not privy to the session key can't
distinguish from a keystroke echo.
--
Simon Tatham "My heart bleeds.
<ana...@pobox.com> (That's how it works.)" -- Gareth Taylor
yawnmoth
> > yawnmoth <terra1...@yahoo.com> wrote:
> >> I also note how the first log sends out what I'm going to have to call
> >> null packets after every response. Why?
>
> Simon Tatham <ana...@pobox.com> wrote:
>
> > Why are you 'going to have to call' them null packets, when you have
> > a log which would allow you to describe them precisely? What message
> > type? What content?
>
> Sorry; I'd forgotten that you'd actually posted links to the logs.
> Right, you mean the SSH2_MSG_IGNOREs sent by the server after each
> CHANNEL_DATA from the client?
I actually meant these packets (and I should have elaborated further,
you're right - sorry about that):
Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
00000000 00 00 00 00 00 00 00 01 00 .........
They're sent by pscp after every incoming SSH2_MSG_CHANNEL_DATA
packet. They seem to be required as without them scp doesn't seem to
work without them but the fact that they're required just seems odd to
me.
Anyway, thanks for your explanations thus far - they've been helpful!
Simon Tatham
> I actually meant these packets (and I should have elaborated further,
> you're right - sorry about that):
>
> Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
> 00000000 00 00 00 00 00 00 00 01 00 .........
That's not an empty packet, though - that's a packet containing a
single zero byte as payload, which is (if I remember rightly) an
integral part of the BSD-style-scp protocol.
--
Simon Tatham "A cynic is a person who smells flowers and
<ana...@pobox.com> immediately looks around for a coffin."
yawnmoth
> yawnmoth <terra1...@yahoo.com> wrote:
> > I actually meant these packets (and I should have elaborated further,
> > you're right - sorry about that):
>
> > Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
> > 00000000 00 00 00 00 00 00 00 01 00 .........
>
> That's not an empty packet, though - that's a packet containing a
> single zero byte as payload, which is (if I remember rightly) an
> integral part of the BSD-style-scp protocol.
Hmmm - it just seems strange to me that any program ran by the 'exec'
channel request could be affected by data sent via stdin /
SSH2_MSG_CHANNEL_DATA. If you try to call 'ftp' via the 'exec'
channel request and then send, via stdin, 'bye', that doesn't make a
difference as the 'ftp' program will never see 'bye'. Indeed, if you
wanted it to see 'bye' it seems like you should be invoking an
interactive shell via the 'shell' channel request.
And yet with scp, stdin isn't ignored, even with the 'exec' channel
request?