The usual authorisation method used for this is called MIT-MAGIC-COOKIE-1. This is a simple password-style protocol: the X client sends some cookie data to the server, and the server checks that it matches the real cookie. The cookie data is sent over an unencrypted X11 connection; so if you allow a client on a third machine to access the virtual X server, then the cookie will be sent in the clear.
PuTTY offers the alternative protocol XDM-AUTHORIZATION-1. This is a cryptographically authenticated protocol: the data sent by the X client is different every time, and it depends on the IP address and port of the client's end of the connection and is also stamped with the current time. So an eavesdropper who captures an XDM-AUTHORIZATION-1 string cannot immediately re-use it for their own X connection.
PuTTY's support for XDM-AUTHORIZATION-1 is a somewhat experimental feature, and may encounter several problems:
•Some X clients probably do not even support XDM-AUTHORIZATION-1, so they will not know what to do with the data PuTTY has provided.
•This authentication mechanism will only work in SSH-2. In SSH-1, the SSH server does not tell the client the source address of a forwarded connection in a machine-readable format, so it's impossible to verify the XDM-AUTHORIZATION-1 data.
•You may find this feature causes problems with some SSH servers, which will not clean up XDM-AUTHORIZATION-1 data after a session, so that if you then connect to the same server using a client which only does MIT-MAGIC-COOKIE-1 and are allocated the same remote display number, you might find that out-of-date authentication data is still present on your server and your X connections fail.
PuTTY's default is MIT-MAGIC-COOKIE-1. If you change it, you should be sure you know what you're doing.
4.24.2 X authority file for local display
If you are using X11 forwarding, the local X server to which your forwarded connections are eventually directed may itself require authorisation.
Some Windows X servers do not require this: they do authorisation by simpler means, such as accepting any connection from the local machine but not from anywhere else. However, if your X server does require authorisation, then PuTTY needs to know what authorisation is required.
One way in which this data might be made available is for the X server to store it somewhere in a file which has the same format as the Unix .Xauthority file. If this is how your Windows X server works, then you can tell PuTTY where to find this file by configuring this option. By default, PuTTY will not attempt to find any authorisation for your local display.
4.25 The Tunnels panel
The Tunnels panel allows you to configure tunnelling of arbitrary connection types through an SSH connection.
Port forwarding allows you to tunnel other types of network connection down an SSH session. See
section 3.5
for a general
discussion of port forwarding and how it works.
The port forwarding section in the Tunnels panel shows a list of all the port forwardings that PuTTY will try to set up when it connects to the server. By default no port forwardings are set up, so this list is empty.
To add a port forwarding:
•Set one of the ‘Local’ or ‘Remote’ radio buttons, depending on whether you want to forward a local port to a remote destination (‘Local’) or forward a remote port to a local destination (‘Remote’). Alternatively, select ‘Dynamic’ if you want PuTTY to provide a local SOCKS 4/4A/5 proxy on a local port (note that this proxy only supports TCP connections; the SSH protocol does not support forwarding UDP).
•Enter a source port number into the ‘Source port’ box. For local forwardings, PuTTY will listen on this port of your PC. For remote forwardings, your SSH server will listen on this port of the remote machine. Note that most servers will not allow you to listen on port numbers less than 1024.
•If you have selected ‘Local’ or ‘Remote’ (this step is not needed with ‘Dynamic’), enter a hostname and port number separated by a colon, in the ‘Destination’ box. Connections received on the source port will be directed to this destination. For example, to connect to a POP-3 server, you might enter popserver.example.com:110. (If you need to enter a literal IPv6 address, enclose it in square brackets, for instance ‘[::1]:2200’.)