mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 09:27:59 +00:00
b4e1110892
Previously, the instant at which we send to the server a request to enable agent forwarding (the "auth-agent-req@openssh.com" channel request, or SSH1_CMSG_AGENT_REQUEST_FORWARDING) was also the instant at which we set a flag indicating that we're prepared to accept attempts from the server to open a channel to talk to the forwarded agent. If the server attempts that when we haven't sent a forwarding request, we treat it with suspicion, and reject it. But it turns out that at least one SSH server does this, for what seems to be a _somewhat_ sensible purpose, and OpenSSH accepts it. So, on the basis that the @openssh.com domain suffix makes them the arbiters of this part of the spec, I'm following their practice. I've removed the 'agent_fwd_enabled' flag from both connection layer implementations, together with the ConnectionLayer method that sets it; now agent-forwarding CHANNEL_OPENs are gated only on the questions of whether agent forwarding was permitted in the configuration and whether an agent actually exists to talk to, and not also whether we had previously sent a message to the server announcing it. (The change to this condition is also applied in the SSH-1 agent forwarding code, mostly for the sake of keeping things parallel where possible. I think it doesn't actually make a difference in SSH-1, because in SSH-1, it's not _possible_ for the server to try to open an agent channel before the main channel is set up, due to the entirely separate setup phase of the protocol.) The use case is a proxy host which makes a secondary SSH connection to a real destination host. A user has run into one of these recently, announcing a version banner of "SSH-2.0-FudoSSH", which relies on agent forwarding to authenticate the secondary connection. You connect to the proxy host and authenticate with a username string of the form "realusername#real.destination.host", and then, at the start of the connection protocol, the server immediately opens a channel back to your SSH agent which it uses to authenticate to the destination host. And it delays answering any CHANNEL_OPEN requests from the client until that's all done. For example (seen from the client's POV, although the server's CHANNEL_OPEN may well have been _sent_ up front rather than in response to the client's): client: SSH2_MSG_CHANNEL_OPEN "session" server: SSH2_MSG_CHANNEL_OPEN "auth-agent@openssh.com" client: SSH2_MSG_CHANNEL_OPEN_CONFIRMATION to the auth-agent request <- data is exchanged on the agent channel; proxy host uses that signature to log in to the destination host -> server: SSH2_MSG_CHANNEL_OPEN_CONFIRMATION to the session request With PuTTY, this wasn't working, because at the point when the server sends the auth-agent CHANNEL_OPEN, we had not yet had any opportunity to send auth-agent-req (because that has to wait until we've had a CHANNEL_OPEN_CONFIRMATION). So we were rejecting the server's CHANNEL_OPEN, which broke this workflow: client: SSH2_MSG_CHANNEL_OPEN "session" server: SSH2_MSG_CHANNEL_OPEN "auth-agent@openssh.com" client: SSH2_MSG_CHANNEL_OPEN_FAILURE to the auth-agent request (hey, I haven't told you you can do that yet!) server: SSH2_MSG_CHANNEL_OPEN_FAILURE to the session request (in that case, no shell session for you!) |
||
---|---|---|
charset | ||
contrib | ||
doc | ||
icons | ||
test | ||
unix | ||
windows | ||
.gitignore | ||
agentf.c | ||
aqsync.c | ||
be_all_s.c | ||
be_all.c | ||
be_misc.c | ||
be_none.c | ||
be_nos_s.c | ||
be_nossh.c | ||
be_ssh.c | ||
Buildscr | ||
Buildscr.cv | ||
callback.c | ||
cgtest.c | ||
CHECKLST.txt | ||
clicons.c | ||
cmdgen.c | ||
cmdline.c | ||
conf.c | ||
config.c | ||
configure.ac | ||
cproxy.c | ||
defs.h | ||
dialog.c | ||
dialog.h | ||
ecc.c | ||
ecc.h | ||
errsock.c | ||
fuzzterm.c | ||
import.c | ||
LATEST.VER | ||
ldisc.c | ||
ldisc.h | ||
LICENCE | ||
licence.pl | ||
logging.c | ||
mainchan.c | ||
marshal.c | ||
marshal.h | ||
memory.c | ||
millerrabin.c | ||
minibidi.c | ||
misc.c | ||
misc.h | ||
miscucs.c | ||
mkauto.sh | ||
mkfiles.pl | ||
mksrcarc.sh | ||
mkunxarc.sh | ||
mpint_i.h | ||
mpint.c | ||
mpint.h | ||
mpunsafe.c | ||
mpunsafe.h | ||
network.h | ||
nocmdline.c | ||
nocproxy.c | ||
nogss.c | ||
noprint.c | ||
noproxy.c | ||
norand.c | ||
noshare.c | ||
noterm.c | ||
notiming.c | ||
nullplug.c | ||
pageant.c | ||
pageant.h | ||
pgssapi.c | ||
pgssapi.h | ||
pinger.c | ||
pockle.c | ||
portfwd.c | ||
pproxy.c | ||
primecandidate.c | ||
proxy.c | ||
proxy.h | ||
pscp.c | ||
psftp.c | ||
psftp.h | ||
psftpcommon.c | ||
psocks.c | ||
psocks.h | ||
putty.h | ||
puttymem.h | ||
puttyps.h | ||
raw.c | ||
README | ||
Recipe | ||
release.pl | ||
resource.h | ||
rlogin.c | ||
scpserver.c | ||
sesschan.c | ||
sessprep.c | ||
settings.c | ||
sftp.c | ||
sftp.h | ||
sftpcommon.c | ||
sftpserver.c | ||
sign.sh | ||
smallprimes.c | ||
ssh1bpp.c | ||
ssh1censor.c | ||
ssh1connection-client.c | ||
ssh1connection-server.c | ||
ssh1connection.c | ||
ssh1connection.h | ||
ssh1login-server.c | ||
ssh1login.c | ||
ssh2bpp-bare.c | ||
ssh2bpp.c | ||
ssh2censor.c | ||
ssh2connection-client.c | ||
ssh2connection-server.c | ||
ssh2connection.c | ||
ssh2connection.h | ||
ssh2kex-client.c | ||
ssh2kex-server.c | ||
ssh2transhk.c | ||
ssh2transport.c | ||
ssh2transport.h | ||
ssh2userauth-server.c | ||
ssh2userauth.c | ||
ssh.c | ||
ssh.h | ||
sshaes.c | ||
ssharcf.c | ||
sshauxcrypt.c | ||
sshbcrypt.c | ||
sshblowf.c | ||
sshblowf.h | ||
sshbpp.h | ||
sshccp.c | ||
sshchan.h | ||
sshcommon.c | ||
sshcr.h | ||
sshcrc.c | ||
sshcrcda.c | ||
sshdes.c | ||
sshdh.c | ||
sshdss.c | ||
sshdssg.c | ||
sshecc.c | ||
sshecdsag.c | ||
sshgss.h | ||
sshgssc.c | ||
sshgssc.h | ||
sshhmac.c | ||
sshkeygen.h | ||
sshmac.c | ||
sshmd5.c | ||
sshnogss.c | ||
sshppl.h | ||
sshprime.c | ||
sshprng.c | ||
sshpubk.c | ||
sshrand.c | ||
sshrsa.c | ||
sshrsag.c | ||
sshserver.c | ||
sshserver.h | ||
sshsh256.c | ||
sshsh512.c | ||
sshsha3.c | ||
sshsha.c | ||
sshshare.c | ||
sshsignals.h | ||
sshttymodes.h | ||
sshutils.c | ||
sshverstring.c | ||
sshzlib.c | ||
storage.h | ||
stripctrl.c | ||
supdup.c | ||
telnet.c | ||
terminal.c | ||
terminal.h | ||
testback.c | ||
testcrypt.c | ||
testcrypt.h | ||
testsc.c | ||
testzlib.c | ||
time.c | ||
timing.c | ||
tree234.c | ||
tree234.h | ||
utils.c | ||
version.c | ||
version.h | ||
wcwidth.c | ||
wildcard.c | ||
x11fwd.c |
This is the README for the source archive of PuTTY, a free Windows and Unix Telnet and SSH client. If you want to rebuild PuTTY from source, we provide a variety of Makefiles and equivalents. (If you have fetched the source from Git, you'll have to generate the Makefiles yourself -- see below.) There are various compile-time directives that you can use to disable or modify certain features; it may be necessary to do this in some environments. They are documented in `Recipe', and in comments in many of the generated Makefiles. For building on Windows: - windows/Makefile.vc is for command-line builds on MS Visual C++ systems. Change into the `windows' subdirectory and type `nmake -f Makefile.vc' to build all the PuTTY binaries. As of 2017, we successfully compile PuTTY with both Visual Studio 7 (2003) and Visual Studio 14 (2015), so our guess is that it will probably build with versions in between those as well. (The binaries from Visual Studio 14 are only compatible with Windows XP and up. Binaries from Visual Studio 7 ought to work with anything from Windows 95 onward.) - Inside the windows/MSVC subdirectory are MS Visual Studio project files for doing GUI-based builds of the various PuTTY utilities. These have been tested on Visual Studio 7 and 10. You should be able to build each PuTTY utility by loading the corresponding .dsp file in Visual Studio. For example, MSVC/putty/putty.dsp builds PuTTY itself, MSVC/plink/plink.dsp builds Plink, and so on. - windows/Makefile.mgw is for MinGW / Cygwin installations. Type `make -f Makefile.mgw' while in the `windows' subdirectory to build all the PuTTY binaries. MinGW and friends can lag behind other toolchains in their support for the Windows API. Compile-time levers are provided to exclude some features; the defaults are set appropriately for the 'mingw-w64' cross-compiler provided with Ubuntu 14.04. If you are using an older toolchain, you may need to exclude more features; alternatively, you may find that upgrading to a recent version of the 'w32api' package helps. - windows/Makefile.lcc is for lcc-win32. Type `make -f Makefile.lcc' while in the `windows' subdirectory. (You will probably need to specify COMPAT=-DNO_MULTIMON.) - Inside the windows/DEVCPP subdirectory are Dev-C++ project files for doing GUI-based builds of the various PuTTY utilities. The PuTTY team actively use Makefile.vc (with VC7/10) and Makefile.mgw (with mingw32), so we'll probably notice problems with those toolchains fairly quickly. Please report any problems with the other toolchains mentioned above. For building on Unix: - unix/configure is for Unix and GTK. If you don't have GTK, you should still be able to build the command-line utilities (PSCP, PSFTP, Plink, PuTTYgen) using this script. To use it, change into the `unix' subdirectory, run `./configure' and then `make'. Or you can do the same in the top-level directory (we provide a little wrapper that invokes configure one level down), which is more like a normal Unix source archive but doesn't do so well at keeping the per-platform stuff in each platform's subdirectory; it's up to you. - unix/Makefile.gtk and unix/Makefile.ux are for non-autoconfigured builds. These makefiles expect you to change into the `unix' subdirectory, then run `make -f Makefile.gtk' or `make -f Makefile.ux' respectively. Makefile.gtk builds all the programs but relies on Gtk, whereas Makefile.ux builds only the command-line utilities and has no Gtk dependence. - For the graphical utilities, any of Gtk+-1.2, Gtk+-2.0, and Gtk+-3.0 should be supported. If you have more than one installed, you can manually specify which one you want by giving the option '--with-gtk=N' to the configure script where N is 1, 2, or 3. (The default is the newest available, of course.) In the absence of any Gtk version, the configure script will automatically construct a Makefile which builds only the command-line utilities; you can manually create this condition by giving configure the option '--without-gtk'. - pterm would like to be setuid or setgid, as appropriate, to permit it to write records of user logins to /var/run/utmp and /var/log/wtmp. (Of course it will not use this privilege for anything else, and in particular it will drop all privileges before starting up complex subsystems like GTK.) By default the makefile will not attempt to add privileges to the pterm executable at 'make install' time, but you can ask it to do so by running configure with the option '--enable-setuid=USER' or '--enable-setgid=GROUP'. - The Unix Makefiles have an `install' target. Note that by default it tries to install `man' pages; if you have fetched the source via Git then you will need to have built these using Halibut first - see below. - It's also possible to build the Windows version of PuTTY to run on Unix by using Winelib. To do this, change to the `windows' directory and run `make -f Makefile.mgw CC=winegcc RC=wrc'. All of the Makefiles are generated automatically from the file `Recipe' by the Perl script `mkfiles.pl' (except for the Unix one, which is generated by the `configure' script; mkfiles.pl only generates the input to automake). Additions and corrections to Recipe, mkfiles.pl and/or configure.ac are much more useful than additions and corrections to the actual Makefiles, Makefile.am or Makefile.in. The Unix `configure' script and its various requirements are generated by the shell script `mkauto.sh', which requires GNU Autoconf, GNU Automake, and Gtk; if you've got the source from Git rather than using one of our source snapshots, you'll need to run this yourself. The input file to Automake is generated by mkfiles.pl along with all the rest of the makefiles, so you will need to run mkfiles.pl and then mkauto.sh. Documentation (in various formats including Windows Help and Unix `man' pages) is built from the Halibut (`.but') files in the `doc' subdirectory using `doc/Makefile'. If you aren't using one of our source snapshots, you'll need to do this yourself. Halibut can be found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>. The PuTTY home web site is https://www.chiark.greenend.org.uk/~sgtatham/putty/ If you want to send bug reports or feature requests, please read the Feedback section of the web site before doing so. Sending one-line reports saying `it doesn't work' will waste your time as much as ours. See the file LICENCE for the licence conditions.