causes password login to occur on a server that supports password-
through-k-i. Of course when we use the new preference list mechanism
for selecting the order of authentications this will all become much
more sane, but for the moment I've put publickey back up to the top
and things seem to be happier.
[originally from svn r1220]
CHANNEL_OPEN_FAILURE messages, which occur when the remote side is
unable to open a forwarded network connection we have requested. (It
seems they _don't_ show up if you get something mundane like
Connection Refused - the channel is cheerfully opened and
immediately slammed shut - but they do if you try to connect to a
host that doesn't even exist. Try forwarding a port to
frogwibbler:4800 and see what you get.)
[originally from svn r1213]
scp1 if it can't. Currently not very tested - I checked it in as
soon as it completed a successful recursive copy in both directions.
Also, one known bug: you can't specify a remote wildcard, because by
the nature of SFTP we'll need to implement the wildcard engine on
the client side. I do intend to do this (and use the same wildcard
engine in PSFTP as well) but I haven't got round to it yet.
[originally from svn r1208]
by me to make the drag list behaviour slightly more intuitive.
WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH.
[originally from svn r1199]
by ceasing to listen on input channels if the corresponding output
channel isn't accepting data. Has had basic check-I-didn't-actually-
break-anything-too-badly testing, but hasn't been genuinely tested
in stress conditions (because concocting stress conditions is non-
trivial).
[originally from svn r1198]
keyboard-interactive authentication. UNTESTED except that I checked
it compiles. Will ask for testing from the user who complained.
[originally from svn r1195]
attempt keyboard-interactive authentication. We can yell about it if
we make a creditable attempt and are rejected, but if the server
just refuses to even consider it then the user won't really want to
know (and if they do there's the Event Log).
[originally from svn r1180]
Only currently works on SSH1; SSH2 should be doable but it's late
and I have other things to do tonight. The Cool Guy award for this
one goes to Nicolas Barry, for doing most of the work and actually
understanding the code he was adding to.
[originally from svn r1176]
function (woohoo!), improved that function so it provides an ASCII
dump as well as hex (whee!), removed all remaining spurious \r in
debug statements (ooh!), and made enabling of packet debugging in
SSH a matter of one ifdef rather than lots (phew!).
[originally from svn r1091]
spawn another command after starting Pageant. Also, if Pageant is
already running, `pageant keyfile' and `pageant -c command' will do
the Right Thing, that is, add the key to the _first_ Pageant and/or
run a command and then exit. The only time you now get the `Pageant
is already running' error is if you try to start the second copy
with no arguments.
NB the affected files in this checkin are rather wide-ranging
because I renamed the not really SSH1-specific
`ssh1_bignum_bitcount' function to just `bignum_bitcount'.
[originally from svn r1044]
could have got away with upping it to 256, but I didn't want a repeat
of the chaos when some server accidentally breaks that limit too...)
[originally from svn r1019]
with public key' message in SSH2 (it already doesn't in SSH1). It
shouldn't show the login banner either, since its output is probably
redirected to something which will choke on it.
[originally from svn r1011]
remote command from a local file. Advantage: you can have more than
one line in it, so you can remotely run what's effectively a small
script.
[originally from svn r1010]
primary (shell session) channel, rather than the one they were aimed
at. This _despite_ me having deliberately gone and looked the channel
ID up in the B-tree - I was ignoring the result by accident :-/
X forwarding should now work in SSH2 even on non-trivial clients (ie
things other than xdpyinfo).
[originally from svn r1007]
PROTOFLAG_SCREEN_NUMBER, without which OpenSSH 2.5.1 was objecting to
my gratuitous inclusion of a screen number in the SSH1 X forwarding
request. Ahem.
[originally from svn r1006]
printing them _before_ the username prompt. This apparently isn't very
serious because OpenSSH doesn't _send_ it before the username prompt,
but only in response to USERAUTH_REQUEST "none". Good job we do that!
[originally from svn r1005]
sensibly, as a release or a snapshot or a local build. With any luck
this should make bug reporting easier to handle, because anyone who
sends their Event Log should automatically include the version :-)
[originally from svn r1003]
