today reported an SSH2_MSG_UNIMPLEMENTED from a Cisco router which
looks as if it was triggered by SSH2_MSG_IGNORE, so I'm
experimentally putting this flag in. Currently must be manually
enabled, though if it turns out to solve the user's problem then
I'll probably add at least one version string...
[Edited commit message: actually, I also committed in error a piece
of experimental code as part of this checkin. Serve me right for not
running 'svn diff' first.]
[originally from svn r8926]
which we close the socket without destroying the channel. John
Peterson reports periodic crashes under heavy load which appear to
be fixed by this, though I don't know the exact circumstances
induced by that load.
[originally from svn r8871]
out, but are now just ignored.
(We should make more effort to prevent duplicates before they get as far as
ssh_setup_portfwd() -- it's currently trivially easy to enter them in the
GUI and on the command line, let alone both -- but there's bound to be someone
with a saved session containing dupes out there by now, and anyway there are
duplicates we can't detect before getting this far, for instance
"1234:localhost:22" vs "1234:localhost:ssh".)
[originally from svn r8623]
some servers (Debian in particular seems prone to this) send a k-i packet with
no prompts and nothing to display. We were printing an extra "Using
keyboard-interactive authentication" message in this case. (Introduced by me
in r8172, I think.)
[originally from svn r8492]
[r8172 == 211fdb9f46]
s->gss_sndtok in r8326. I'm not sure it was strictly necessary, since
even if there's no send token, gss_init_sec_context() is meant to explicitly
make it empty, but it wasn't an intentional change.
[originally from svn r8337]
[r8326 == 81dafd906e]
under SSH-2, don't risk looking at the length field of an incoming packet
until we've successfully MAC'ed the packet.
This requires a change to the MAC mechanics so that we can calculate MACs
incrementally, and output a MAC for the packet so far while still being
able to add more data to the packet later.
[originally from svn r8334]
ourselves, but on Unix then assumed it was compatible with the system's
gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix
we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep
something similar to the existing behaviour on Windows. This requires
renaming a couple of the fields in Ssh_gss_buf, and hence fixing all
the references.
Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal).
Not tested on Windows because neither mingw32 nor winegcc worked out of the
box for me. I think the Windows changes are all syntactic, though, so
if this compiles it should work no worse than before.
[originally from svn r8326]
if we have no better ideas, with UI shamelessly stolen from Quest PuTTY.
Off by default, which effectively reverts the change to using the local
username by default that came in with GSSAPI support in r8138. Anyone wanting
seamless single sign-on will need to set the new option. (The previous
default behaviour was getting in the way in ad-hoc scenarios.)
Note that the PSCP and Unix-Plink behaviour of using the local username by
default have remained unchanged throughout; they are not affected by the new
option. Not sure if that's the Right Thing.
[originally from svn r8324]
[r8138 == de5dd9d65c]
strings more rigorously, and then we look up the local X authority
data in .Xauthority _ourself_ rather than delegating to an external
xauth program. This is (negligibly) more efficient on Unix, assuming
I haven't got it wrong in some subtle way, but its major benefit is
that we can now support X authority lookups on Windows as well
provided the user points us at an appropriate X authority file in
the standard format. A new Windows-specific config option has been
added for this purpose.
[originally from svn r8305]
both directions. We had a bug report yesterday about a Cisco router
sending SSH2_MSG_UNIMPLEMENTED and it wasn't clear for which packet;
logging the sequence numbers should make such problems much easier
to diagnose.
(In fact this logging fix wouldn't have helped in yesterday's case,
because the router also didn't bother to fill in the sequence number
field in the SSH2_MSG_UNIMPLEMENTED packet! This is a precautionary
measure against the next one of these problems.)
[originally from svn r8295]
no actual prompts, we weren't displaying the former, which was wrong. We
should now (although I haven't found a server to test it against).
[originally from svn r8172]
to manually tweak the host name and port number under which the SSH
host key is read and written.
I've put it in the cross-platform Connection panel. Partly under the
flimsy pretext that other backends _can_ use it if they so wish (and
in fact it overrides the host name for title-bar purposes in all
network backends, though it has no other effect in anything but
SSH); but mostly because the SSH panel was too full already :-)
[originally from svn r8033]
We could explicitly re-enable %n, but we only use it in one place, so take
the path of least resistance and remove that single instance. This stops
dupvprintf() getting stuck in a loop (a behaviour that's caused by a workaround
for a broken libc).
<http://msdn.microsoft.com/en-us/library/ms175782(VS.80).aspx>
[originally from svn r8030]
advertise so that the server can't exceed our maximum packet size.
Enable it for "1.36_sshlib GlobalSCAPE" which apparently sends oversize
packets otherwise.
[originally from svn r7804]
as well. This won't be triggered in the usual case, but it's useful
if the remote end ignores our window, or if we're in "simple" mode and
setting the window far larger than is necessary.
[originally from svn r7756]
spurious SSH_MSG_CHANNEL_FAILUREs, treat them as the protocol errors
they are and forcibly disconnect. Inspired by recent traffic on
comp.security.ssh.
[originally from svn r7752]
a single function which also handles checking that channels exist and
are properly open. This should make PuTTY a little less tolerant of
servers that send bogus messages.
[originally from svn r7751]
performance. The theory behind this is fairly simple, though the
implementation turns out to be a little trickier than it looks.
The basic idea is that when the connection isn't being limited by our ability
to process data, we want to ensure that the window size _as seen by the server_
never drops to zero. Measuring the server's view of the window size is done
by arranging for it to acknowledge every SSH_MSG_CHANNEL_WINDOW_ADJUST, or
rather an SSH_MSG_CHANNEL_REQUEST sent just before it. That way we can tell
when it its outgoing data stream it received the window adjustment, and
thus how small the server's view of the window got.
At present, we only ever increase the window size. In theory, we could
arrange to reduce it again if the server's view of it seemed to be persistently
too large, but my experiments suggest that getting this right will be tricky.
[originally from svn r7735]
for it. It's possible that this obsoletes BUG_CHOKES_ON_RSA. Certainly
the one SSH-1.5-Cisco-1.25 server I found was correctly not advertising RSA
auth. For now, leave it in, because I'm not feeling entirely confident.
[originally from svn r7726]
because it can ever be negative, but because we'll be comparing it with
another int. This way, C's promotion rules don't bite us and we should
stand slightly more chance of coping with broken servers that overrun our
window.
[originally from svn r7683]
and tweak ssh2_set_window() so it can cope with that. Also arrange to send
a private channel message in simple mode to tell the server that it can safely
use a large window too.
[originally from svn r7679]
channel, arrange to set the SSH-2 window size to something very
large. This prevents the connection stalling when the window fills
up, and means that PSCP receives data _much_ faster.
[originally from svn r7672]
used up, rather than over half. That this increases the throughput of PSCP
by 50% indicates just how broken our window handling is.
[originally from svn r7667]
arrange to handle usefully the case where the server sends us more data
than it's allowed to. There's no danger of overflow, since the maximum is
OUR_V2_WINSIZE and the minimum is -OUR_V2_MAXPKT (at least if the server is
nice).
[originally from svn r7661]
instead of a bitfield for both. This doesn't gain much here, but it should
make it easier to make things other than logging use the context.
[originally from svn r7647]
This allows us to send data in ssh_init(), albeit at the expense of its not
being properly logged, so arrange to send the version string then if that's
sensible, which should reduce the number of round-trips required to bring
up an SSH-2 connection.
[originally from svn r7646]
the SSH-2-only case, we can send it as soon as we connect rather than waiting
for the server's one. Unfortunately, actually doing so will take a little
more effort -- there are subtleties to do with having a working log context
at the right moment that need to be sorted out.
[originally from svn r7645]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
remember to put an empty string in it rather than sending a completely
empty packet. This should help with those servers (notably RomSShell)
that actually check the contents of SSH_MSG_IGNORE.
[originally from svn r7236]
will close the window even in `close window only on clean exit'
mode. Also, while I'm here, arrange a suitable exit code for
"exit-signal".
[originally from svn r7121]
ability to easily re-enable the r5122 behaviour, in case we need to
conditionally switch between the two at a later date.
[originally from svn r7073]
[r5122 == 8a20515844]
[this svn revision also touched putty-wishlist]
(Since we choose to compile with -Werror, this is particularly important.)
I haven't yet checked that the resulting source actually compiles cleanly with
GCC 4, hence not marking `gcc4-warnings' as fixed just yet.
[originally from svn r7041]
BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent
of whether BUG_CHOKES_ON_SSH1_IGNORE is set.
This is invisible in the default configuration, as all servers marked as having
the second bug have the first one too, but it would allow one to manually
configure PuTTY to cope with a SSH-1 server that got upset by ignore messages
during authentication, but was fine with their use as keepalives.
[originally from svn r6876]
in an SSH connection _in addition_ to the decrypted packets. This
will hopefully come in useful for debugging wire data corruption
issues: you can strace the server, enable this mode in the client,
and compare the sent and received data.
I'd _like_ to have this mode also log Diffie-Hellman private
exponents, session IDs, encryption and MAC keys, so that the
resulting log file could be used to independently verify the
correctness of all cryptographic operations performed by PuTTY.
However, I haven't been able to convince myself that the security
implications are acceptable. (It doesn't matter that this
information would permit an attacker to decrypt the session, because
the _already_ decrypted session is stored alongside it in the log
file. And I'm not planning, under any circumstances, to log users'
private keys. But gaining access to the log file while the session
was still running would permit an attacker to _hijack_ the session,
and that's the iffy bit.)
[originally from svn r6835]
there): `plink host -nc host2:port' causes the SSH connection's main
channel to be replaced with a direct-tcpip connection to the
specified destination. This feature is mainly designed for use as a
local proxy: setting your local proxy command to `plink %proxyhost
-nc %host:%port' lets you tunnel SSH over SSH with a minimum of
fuss. Works on all platforms.
[originally from svn r6823]
it's NULL. Since we already have one back end (uxpty) which doesn't
in fact talk to a network socket, and may well have more soon, I'm
replacing this TCP/IP-centric function with a nice neutral
`connected' function returning a boolean. Nothing else about its
semantics has currently changed.
[originally from svn r6810]
session termination. `Close window only on clean exit' was not
working properly on Unix in the absence of this:
notify_remote_exit() was being called and ssh_return_exitcode was
returning zero, causing gtk_main_quit() to be called, _before_
connection_fatal() happened.
[originally from svn r6801]
Pageant for local authentication. (This is a `don't use Pageant for
authentication at session startup' button rather than a `pretend
Pageant doesn't exist' button: that is, agent forwarding is
independent of this option.)
[originally from svn r6572]
to be from IP "client-side-connection". Claiming "0.0.0.0" instead seems to
work. Spotted by Brant Thomsen.
[originally from svn r6477]
[this svn revision also touched putty-wishlist]
that the SSH-2 server is happy with. Fixed, and since I'm here, fix
`pubkeyfile-and-pageant' as well (for SSH-1 and SSH-2).
Also, in SSH-2, we now reexamine "methods that can continue" for every
Pageant key offer, which is technically more correct although it seems
unlikely that it was causing any real problems.
(It's not entirely pretty, but neither was the old code. We could probably
do with some sort of abstraction for public/private keys to avoid carting
lots of fiddly bits of data around.)
[originally from svn r6459]
[r6437 == 8719f92c14]
[this svn revision also touched putty-wishlist]
(Much easier since r6437, and actually works to boot.)
[originally from svn r6445]
[r6437 == 8719f92c14]
[this svn revision also touched putty-wishlist]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
packets over about 256 bytes would be logged with 12 bytes of preceding
garbage. (But the rest of the packet was logged in its entirety. This
holds for packets where (int(len/256)%2)==1, with an appropriate fudge
factor applied to `len'.) Ahem.
[originally from svn r6429]
[r5642 == c09d885b27]
patched OpenSSH server. This is controlled by the same user settings
as diffie-hellman-group-exchange-sha1, which may not be optimal, especially
given that they're both referred to as dh-gex-sha1 in saved sessions.
[originally from svn r6272]
storing a SHA-1 hash of the client and server version strings, store the
strings themselves so we can feed them through the appropriate hash when
we know what it is.
[originally from svn r6241]
processed and incoming data being processed out of order, which I suspect is
the cause of `ssh1-fwd-trouble' as noted by Gevan Dutton. I'm not able to
test the failure case, but it doesn't seem to have obviously broken anything
in the cases I have tested, anyway.
[originally from svn r6221]
marks a version string. It's a bit vague about the definition of a line,
but I think it's reasonable to assume that they'll end with LF. Change
do_ssh_init() to ignore "SSH-" anywhere else. This makes the existing state
machine overkill, so replace it with something a little more readable.
[originally from svn r6138]
do_ssh2_transport() was returning the wrong value for rekeys after the first.
This apparent error was introduced in r4901, but we can't see any reason for
the change to have been made. If it turns out to be a mistake to revert it,
I'm sure we'll find out.
Here for posterity is Simon's analysis:
| A lot of the return values from do_ssh2_transport appear to be vestigial: it
| used to be that a zero return from do_ssh2_transport meant it had handled the
| packet internally, and a 1 return meant the packet wasn't a transport-layer
| one and needed to pass on to do_ssh2_authconn. Since r4901, however, the
| layer discrimination is done based on the message type ranges, and the only
| remaining dependency on the return value from do_ssh2_transport is a special
| case in ssh2_protocol which detects the first 1 return and makes the
| initialisation call to do_ssh2_authconn.
|
| Therefore, the gratuitous 1 return on every key exchange as a result of the
| confusing if statement is simply ignored in ssh2_protocol (because
| ssh->protocol_initial_phase_done is already TRUE). So the remaining question
| was, why does the _lack_ of that 1 return not cause a problem, if the if's
| sense is indeed reversed?
|
| The answer is that 1 is still returned, just not by the crReturn inside the
| if statement. It's returned by the next crReturn, just after
| wait_for_rekey(). Which suggests that in fact, the if statement has the
| correct sense, but the crReturn inside it has the wrong value - it should be
| returning _zero_, to indicate that every NEWKEYS after the first one is
| uninteresting to the authconn code, and on the very first run through that
| doesn't happen and the NEWKEYS gets all the way to the crReturn(1) later on.
[originally from svn r5986]
[r4901 == a4ba026838]
enforce the following:
* Packet must have at least one byte of payload and four bytes of padding.
* Total packet length must not exceed 35000 bytes compressed.
* Total packet length including length field must be a multiple of cipher
block size (or eight bytes).
The feebleness of our old checks was noticed by Ben Rudiak-Gould.
[originally from svn r5981]
and add the ability to treat a local disconnection as "unclean" -- notably, if
we can't agree any authentication methods to even try; someone was complaining
that the PuTTY window by default just disappears for no apparent reason in this
circumstance.
Also, use appropriate disconnect codes for those SSH2_MSG_DISCONNECT messages
that we do send.
I don't think I've seriously broken any user-visible behaviour, but the way
that connection-close distinctions are transmitted to the front-end is shaky
(or so it seems to me), so there may be non-ideal changes on some platforms.
[originally from svn r5824]
hopefully solve `drop-banner'. I haven't been able to test the failure case,
but the behaviour with OpenSSH appears no worse.
[originally from svn r5772]
[this svn revision also touched putty-wishlist]
there are servers which could in principle operate in this mode, although I
don't know if any do in practice. (Hence, I haven't been able to test it.)
[originally from svn r5748]
[this svn revision also touched putty-wishlist]
server, which led to stalemate if the server did the same. PuTTY now sends
KEXINIT proactively as soon as it's worked out that it's talking SSH-2.
[originally from svn r5685]
default preferred cipher), add code to inject SSH_MSG_IGNOREs to randomise
the IV when using CBC-mode ciphers. Each cipher has a flag to indicate
whether it needs this workaround, and the SSH packet output maze has gained
some extra complexity to implement it.
[originally from svn r5659]
Unix Plink sends everything sensible it can find, and it's fully configurable
from the GUI.
I'm not entirely sure about the precise set of modes that Unix Plink should
look at; informed tweaks are welcome.
Also the Mac bits are guesses (but trivial).
[originally from svn r5653]
[this svn revision also touched putty-wishlist]
end, after the REQUIRED "hmac-sha1".) This has been present since SSH-2
support was introduced (r569).
[originally from svn r5643]
[r569 == 35205e5cb7]
I've added this to support `terminal-modes', but since this unifies some
SSH-1 and SSH-2 packet construction code, it saves a few hundred bytes.
Bonus.
[originally from svn r5642]
comp.security.ssh contains a Dr Watson log which looks to me as if
`unclean-close-crash' occurred due to a rekey timer going off after
the session had closed. Hence, ssh2_timer() now avoids doing
anything if the session is already closed, and also ssh_do_close()
proactively calls expire_timer_context(). Between those I think they
ought to solve the problem.
[originally from svn r5564]
ssh2_try_send() to no longer be run after receiving WINDOW_ADJUSTs.
I believe this is likely to have been the cause of recent PSCP
hanging issues.
[originally from svn r5517]
[r4909 == 02b0474f57]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
prompts, to make it more obvious if a server is attempting to spoof a local
passphrase prompt.
I believe an alert user could have spotted this in all cases in SSH-2,
although perhaps not in SSH-1. (But they'd have to have enabled
TIS/CryptoCard.)
[originally from svn r5450]
Port forwardings are set up before initialising the last few details
of the main shell session, so ssh->state can reasonably hold values
other than SSH_STATE_SESSION and SSH_STATE_CLOSED during calls to
sshfwd_*.
[originally from svn r5446]
connection_fatal(), since the latter is entitled to destroy the
backend so `ssh' may no longer be valid once it returns.
For the Unix port, switch exit(0) to gtk_main_quit() in
notify_remote_exit(), so that we don't exit before the subsequent
connection_fatal()!
[originally from svn r5445]
cfg.remote_cmd is to be used, rather than actually pointing at
cfg.remote_cmd. This change restores the ability to structure-copy
Configs without breaking them. (Though of course this is only a
temporary solution: really what wants doing is to fix
`config-struct'.)
[originally from svn r5335]
now returns an integer: 0 means cancel the SSH connection and 1
means continue with it. Additionally, they can return -1, which
means `front end has set an asynchronous alert box in motion, please
wait to be called back with the result', and each one is passed a
callback function pointer and context for this purpose.
I have not yet done the same to askappend() yet, because it will
take a certain amount of reorganisation of logging.c.
Importantly, this checkin means the host key dialog box now works on
OS X.
[originally from svn r5330]
changing its mouse pointer. Currently this is only used in the (slightly-
arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer
hiding while PuTTY is busy, but preserve pointer-hiding state.
Not yet implemented on the Mac.
Also switch to frobbing window-class cursor in Windows rather than relying on
SetCursor().
[originally from svn r5303]
for which we don't yet have a remote number, and instead add a flag to indicate
this fact. Fixes bug ssh-remoteid-minusone.
[originally from svn r5171]
tested since none of the common key-exchange protocols starts with a packet
from the server, so I don't have a server that implements this.
[originally from svn r5162]
only send it when it will significantly increase the server's idea of our
window. This avoids the slew of one-byte WINDOW_ADJUSTs that an interactive
shell typically generates.
[originally from svn r5121]
to see the server slam the TCP connection shut (i.e. almost never,
unless it's just sent us an SSH_MSG_DISCONNECT), and treat an
unexpected closure as a non-clean session termination. Previously
any server-initiated connection closure was being treated as a clean
exit, which was a hangover from the good old Telnet-only days.
[originally from svn r5098]
[this svn revision also touched putty-wishlist]
deal with rekeys at all: they totally ignore mid-session KEXINIT
sent by the client. Hence, a new bug entry so we don't try it.
[originally from svn r5092]
exchange. Without doing this, after we have done one specific-group
DH exchange (group1 or group14), ssh2_pkt_type _always_ translates
30 and 31 as KEXDH_INIT and KEXDH_REPLY, making a subsequent
group-exchange kex look rather strange in an SSH packet log.
[originally from svn r5081]
INFO_REQUESTs, and for some reason Debian OpenSSH is sending INFO_REQUESTs
containing no prompts after a normal password authentication, so this
should fix Shai's problem.
[originally from svn r5078]
[r5068 == 297ee2573e]
[this svn revision also touched putty-wishlist]
SSH connection when we're in the middle of asking the user a
dialog-box-type question. Fixes `unix-kex-packet', which has just
bitten me when connecting to one of the work Suns.
[originally from svn r5071]
[this svn revision also touched putty-wishlist]
long as the server offers it, rather than only once, unless the server responds
to our initial USERAUTH_REQUEST("keyboard-interactive") with FAILURE, in which
case we give up on it entirely.
[originally from svn r5068]
[this svn revision also touched putty-wishlist]
mid-session in SSH2: this forces an immediate rekey to activate the
new settings. I'm not sure exactly what this will be useful for
(except possibly it might make comparative performance testing
easier?), but it has wonderful James Bond value for being able to
switch to a more secure cipher before doing anything sensitive :-)
If, that is, you weren't using the most secure one to begin with...
[originally from svn r5051]
to be destroying old ones _before_ creating new ones, so that we can
reuse a port for a new purpose without colliding with ourselves.
Also fixed port forwarding, which my IPv6 checkin had completely
funted :-)
[originally from svn r5049]
of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
IPv6-unrelated changes, which convert ints into unsigned in a few
key places in ssh.c. Looks harmless at worst, possibly terribly
useful, so I think we'll have these no matter what the real IPv6
stuff is up to!
[originally from svn r5038]
bit is working out when to reschedule the next rekey for when the
timeout or data limit changes; sometimes it will be _right now_
because we're already over the new limit.
Still to do: the Kex panel should not appear in mid-session if we
are using SSHv1.
[originally from svn r5031]
Change Settings, the port forwarding setup function is run again,
and tags all existing port forwardings as `do not keep'. Then it
iterates through the config in the normal way; when it encounters a
port forwarding which is already in the tree, it tags it `keep'
rather than setting it up from scratch. Finally, it goes through the
tree and removes any that haven't been labelled `keep'. Hence,
editing the list of forwardings in Change Settings has the effect of
cancelling any forwardings you remove, and adding any new ones.
The SSH panel now appears in the reconfig box, and is empty apart
from a message explaining that it has to be there for subpanels of
it to exist. Better wording for this message would be welcome.
[originally from svn r5030]
routine which is common between SSH1 and SSH2. Since this routine is
not part of the coroutine system, this means it can't sit and wait
to get its various success/failure responses back. Hence, I've
introduced a system of queued packet handlers, each of which waits
for exactly one of a pair of messages (SSH1_SMSG_{SUCCESS,FAILURE}
or SSH2_MSG_REQUEST_{SUCCESS,FAILURE}), handles it when it arrives,
and automatically de-registers itself. Hence the port-forwarding
setup code can be called once, and then subsequent packets related
to it will automatically be handled as they arrive.
The real purpose of all this is that the infrastructure is now there
for me to arrange mid-session configurability of port forwarding.
However, a side benefit is that fewer round trips are involved in
session startup. I'd quite like to move more of the connection setup
(X forwarding, agent forwarding, pty allocation etc) to using the
new queued handler mechanism for this reason.
[originally from svn r5029]
(which will gain more content anon).
Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never
did find a way of automatically detecting this alleged server bug, and in any
case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW).
Also generalise askcipher() to a new askalg() (thus touching all the
front-ends).
I've made some attempt to document what SSH key exchange is and why you care,
but it could use some review for clarity (and outright lies).
[originally from svn r5022]
should stop ssh_do_close() accessing freed ssh->channels when invoked later
from ssh_free(). Spotted by Fred Sauer.
(Perhaps this is the cause of the crashes people have been reporting on
abnormal closures such as `Software caused connection abort'? I've not been
able to test this.)
[originally from svn r4946]
timing.c, and hence takes its own responsibility for calling
noise_regular() at regular intervals. Again, this means it will be
called consistently in _all_ the SSH-speaking tools, not just those
in which I remembered to call it!
[originally from svn r4913]
SSH2, is now handled by the packet dispatch table. Dispatch table
entries are enabled as soon as possible, so that if anyone tries to
(for example) start using a forwarded port before the main shell
session setup has finished, things should work sensibly.
The SSH code is now a hybrid of coroutine-based sequential logic and
table-driven event dispatch, each where it makes the most sense. I'm
rather pleased with it.
Should fix: ext-data-at-start, portfwd-at-start.
[originally from svn r4909]
[this svn revision also touched putty-wishlist]
data transfer in either direction (whichever comes first), or at
explicit client request (nice idea Jacob). Have tested by lowering
the limits, and it all seems solid enough; in particular, this has
also allowed me to test the behaviour when connection-level data is
received during rekey, and that looks fine too (at least it does
_now_ :-).
[originally from svn r4908]
[this svn revision also touched putty-wishlist]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
ssh1_protocol() and ssh2_protocol() are now high-level functions
which see _every_ SSH packet and decide which lower-level function
to pass it to. Also, they each support a dispatch table of simple
handler functions for message types which can arrive at any time.
Results are:
- ignore, debug and disconnect messages are now handled by the
dispatch table rather than being warts in the rdpkt functions
- SSH2_MSG_WINDOW_ADJUST is handled by the dispatch table, which
means that do_ssh2_authconn doesn't have to explicitly
special-case it absolutely every time it waits for a response to
its latest channel request
- the top-level SSH2 protocol function chooses whether messages get
funnelled to the transport layer or the auth/conn layer based on
the message number ranges defined in the SSH architecture draft -
so things that should go to auth/conn go there even in the middle
of a rekey (although a special case is that nothing goes to
auth/conn until initial kex has finished). This should fix the
other half of ssh2-kex-data.
[originally from svn r4901]
can keep several of them in parallel. In particular, this allows us
to queue outgoing packets during repeat key exchange, to be actually
sent after the rekey completes.
(This doesn't fully fix ssh2-kex-data; also required is the ability
to handle _incoming_ connection-layer packets during rekey without
exploding.)
[originally from svn r4899]
structure have been retired. Now all Packet structures are
dynamically allocated. Each rdpkt function allocates one, and it's
freed after being used; and the packet construction functions
allocate them too, and they're freed by the send functions.
`pktin' and `pktout' were ugly. They were _morally_ still global
variables; even though they were replicated per SSH session to
comply with the Mac no-globals requirement, they weren't really in
the _spirit_ of `dynamically allocate your data'.
As a side effect of this change, the `pktout_blanks' and
`pktout_nblanks' fields in the Ssh structure have been moved into
the Packet structure.
[originally from svn r4898]
prompt for keyboard-interactive. I suspect we should do the same with that
method (especially given the apparent number of systems that use it for
regular password auth), but in the absence of systems to test against I've
not actually made the change. (I'm worried that the `partial success' field
might not be set correctly in a multi-stage authentication, for instance.)
[originally from svn r4850]
authentication state, a failed `password' authentication in SSH-2 was
sending us back to trying `none' and `keyboard-interactive' each time
round, which uses up OpenSSH's quota of authentication attempts rather
quickly. Added a check for `cfg.change_username' to the logic which
sends us back to the start.
[originally from svn r4849]
pointed out that Plink would attempt to use a zero-length username iff
a remote command was specified (because the FLAG_INTERACTIVE test was
erroneously combined with the no-username test).
I don't think this will break non-interactive use; in the cases which
behave differently, Plink would be attempting to use the empty
username, which was almost certainly wrong, whereas now it will give a
prompt (which can be avoided with -batch as usual).
(Although perhaps we should attempt to use a local username as a guess for
the remote username, as PSCP does? I've not done this.)
[originally from svn r4831]
Also, I'm pretty sure that adding a source address to a remote SSH-2 forwarding
can never have worked, since we added an address string to the packet twice in
that case. OpenSSH 3.4p1 certainly doesn't like it (`Server has disabled port
forwarding' debug message). Fixed (and OpenSSH is happier now).
[originally from svn r4727]
mechanics means that each SSH-2 remote tunnel will sfree() something
random and thus have a chance of crashing or doing something else
bad, although it won't otherwise affect execution. Introduced in
1.319 [r4529] (some of my improved diagnostics). One day I'll make a
checkin to ssh.c without forgetting about the coroutines...
[originally from svn r4725]
[r4529 == 27193c4bf0]
fixing `vuln-ssh2-debug', by missing out a field. In most cases
(always_display = 0) we would log a zero-length or truncated message.
(Also add a prototype for ssh2_pkt_getbool().)
[originally from svn r4718]
This is disgustingly huge because old versions of OpenSSH got the message
format wrong, so we have to infer which format is in use. Tested with
Debian stable OpenSSH (3.4p1), with `uint32' packet, and lshd, which uses
the correct `string' packet, and also let me test "core dumped" and the
explanatory message.
[originally from svn r4653]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
down. (A side effect of fixing this is that ssh->mainchain is set to NULL
when it closes, which might avoid other sorts of trouble.)
While we're here, don't bother offering SSH1_MSG_IGNORE if we believe the
remote will barf on it.
[originally from svn r4650]
into the Connection panel, and implemented support for the SSH2
"env" request. (I haven't yet found a server which accepts this
request, so although I've visually checked the packet log and it
looks OK, I haven't yet been able to do a full end-to-end test.)
Also, the `pty' backend reads this data and does a series of
`putenv' commands before launching the shell or application.
This is mostly because in last week's UTF-8 faffings I got
thoroughly sick of typing `export LANG=en_GB.UTF-8' every time I
started a new testing pterm, and it suddenly occurred to me that
this would be precisely the sort of thing you'd want to have pterm
set up for you, particularly since you can configure it alongside
the translation settings and so you can ensure they match up
properly.
[originally from svn r4645]
PuTTY / Plink not to run a remote shell/command at all. Supported in
the GUI configuration and via the (OpenSSH-like) -N command-line
option.
No effort is currently made to arrange `nice' UI properties. If you
do this in GUI PuTTY, a full-size terminal window will still be
created, and will sit there with almost nothing in it throughout
your session. If you do it in Plink, Plink will not accept any kind
of request to terminate gracefully; you'll have to ^C or kill it.
Nonetheless, even this little will be useful to some people...
[originally from svn r4614]
by default (although they can be included). There's also an option to remove
session data, which is good both for privacy and for reducing the size of
logfiles.
[originally from svn r4593]
