nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/proxy/sshproxy.c

780 lines
24 KiB
C
Raw Normal View History

Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
* sshproxy.c: implement a Socket type that talks to an entire
* subsidiary SSH connection (sometimes called a 'jump host').
*/
#include <stdio.h>
#include <assert.h>
#include "putty.h"
#include "ssh.h"
#include "network.h"
#include "storage.h"
Add exec/subsystem versions of SSH proxying. This is a simple tweak to the existing in-process SSH jump host support, where instead of opening a direct-tcpip channel to the destination host, we open a session channel and run a process in it to make the connection to the destination. So, where the existing jump host support replaced a local proxy command along the lines of "plink %proxyhost -nc %host %port", this one replaces "plink %proxyhost run-some-command". Also added a corresponding option to use a subsystem to make the connection. (Someone could configure an SSH server to support specific subsystem names for particular destinations, or a general schema of subsystem names that include the destination address in some standard format.) To avoid overflowing the already-full Proxy config panel with an extra subtype selector, I've put these in as additional top-level proxy types, so that instead of just PROXY_SSH we now have three PROXY_SSH_foo.
2022-04-22 13:12:15 +00:00
#include "proxy.h"
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
const bool ssh_proxy_supported = true;
typedef struct SshProxy {
char *errmsg;
Conf *conf;
LogContext *logctx;
Backend *backend;
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
LogPolicy *clientlp;
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
Seat *clientseat;
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
Interactor *clientitr;
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
SSH proxying: use CONF_proxy_password if available. I was just writing the documentation for the new proxy type, which caused me to realise that the thing I obviously wanted to write in the documentation was not actually true. Let's make it true, and then I can document it!
2021-12-30 11:47:58 +00:00
bool got_proxy_password, tried_proxy_password;
char *proxy_password;
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
ProxyStderrBuf psb;
Plug *plug;
bool frozen;
bufchain ssh_to_socket;
bool rcvd_eof_ssh_to_socket, sent_eof_ssh_to_socket;
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
bool conn_established;
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sshproxy: keep addr and free it on close. The caller of new_connection has relinquished ownership of the SockAddr it passes in. So the receiver of that SockAddr must remember to free it, or else we leak memory. (Additionally, this means SshProxy will be able to remember the address during its run, e.g. to use in calls to its Plug. But that's not implemented yet.)
2021-09-12 08:52:46 +00:00
SockAddr *addr;
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
int port;
sshproxy: keep addr and free it on close. The caller of new_connection has relinquished ownership of the SockAddr it passes in. So the receiver of that SockAddr must remember to free it, or else we leak memory. (Additionally, this means SshProxy will be able to remember the address during its run, e.g. to use in calls to its Plug. But that's not implemented yet.)
2021-09-12 08:52:46 +00:00
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/* Traits implemented: we're a Socket from the point of view of
* the client connection, and a Seat from the POV of the SSH
* backend we instantiate. */
Socket sock;
LogPolicy logpolicy;
Seat seat;
} SshProxy;
static Plug *sshproxy_plug(Socket *s, Plug *p)
{
SshProxy *sp = container_of(s, SshProxy, sock);
Plug *oldplug = sp->plug;
if (p)
sp->plug = p;
return oldplug;
}
static void sshproxy_close(Socket *s)
{
SshProxy *sp = container_of(s, SshProxy, sock);
sshproxy: keep addr and free it on close. The caller of new_connection has relinquished ownership of the SockAddr it passes in. So the receiver of that SockAddr must remember to free it, or else we leak memory. (Additionally, this means SshProxy will be able to remember the address during its run, e.g. to use in calls to its Plug. But that's not implemented yet.)
2021-09-12 08:52:46 +00:00
sk_addr_free(sp->addr);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sfree(sp->errmsg);
conf_free(sp->conf);
if (sp->backend)
backend_free(sp->backend);
if (sp->logctx)
log_free(sp->logctx);
SSH proxying: use CONF_proxy_password if available. I was just writing the documentation for the new proxy type, which caused me to realise that the thing I obviously wanted to write in the documentation was not actually true. Let's make it true, and then I can document it!
2021-12-30 11:47:58 +00:00
if (sp->proxy_password)
burnstr(sp->proxy_password);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
bufchain_clear(&sp->ssh_to_socket);
delete_callbacks_for_context(sp);
sfree(sp);
}
static size_t sshproxy_write(Socket *s, const void *data, size_t len)
{
SshProxy *sp = container_of(s, SshProxy, sock);
if (!sp->backend)
return 0;
Separate backend_send from backend_sendbuffer. On a similar theme of separating the query operation from the attempted change, backend_send() now no longer has the side effect of returning the current size of the send buffer. Instead, you have to call backend_sendbuffer() every time you want to know that.
2021-09-12 08:52:46 +00:00
backend_send(sp->backend, data, len);
return backend_sendbuffer(sp->backend);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static size_t sshproxy_write_oob(Socket *s, const void *data, size_t len)
{
/*
* oob data is treated as inband; nasty, but nothing really
* better we can do
*/
return sshproxy_write(s, data, len);
}
static void sshproxy_write_eof(Socket *s)
{
SshProxy *sp = container_of(s, SshProxy, sock);
if (!sp->backend)
return;
backend_special(sp->backend, SS_EOF, 0);
}
static void try_send_ssh_to_socket(void *ctx);
sshproxy: call backend_unthrottle on unfreeze. If an SSH proxy socket is frozen for long enough, and the SSH server continues to send, then sooner or later the proxy SSH connection will end up having to freeze its underlying physical socket too. When the proxy socket is later unfrozen, it needs to pass that unfreezing on in turn. The way this should happen is that when the SshProxy begins to clear the backlog of data passed to it from the proxy SSH connection via seat_stdout, it should call backend_unthrottle to inform that proxy connection that the backlog is clearing. But there was no backlog_unthrottle call in the whole of sshproxy.c. Now there is.
2022-03-30 17:15:43 +00:00
static void try_send_ssh_to_socket_cb(void *ctx)
{
SshProxy *sp = (SshProxy *)ctx;
try_send_ssh_to_socket(sp);
if (sp->backend)
backend_unthrottle(sp->backend, bufchain_size(&sp->ssh_to_socket));
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
static void sshproxy_set_frozen(Socket *s, bool is_frozen)
{
SshProxy *sp = container_of(s, SshProxy, sock);
sp->frozen = is_frozen;
if (!sp->frozen)
sshproxy: call backend_unthrottle on unfreeze. If an SSH proxy socket is frozen for long enough, and the SSH server continues to send, then sooner or later the proxy SSH connection will end up having to freeze its underlying physical socket too. When the proxy socket is later unfrozen, it needs to pass that unfreezing on in turn. The way this should happen is that when the SshProxy begins to clear the backlog of data passed to it from the proxy SSH connection via seat_stdout, it should call backend_unthrottle to inform that proxy connection that the backlog is clearing. But there was no backlog_unthrottle call in the whole of sshproxy.c. Now there is.
2022-03-30 17:15:43 +00:00
queue_toplevel_callback(try_send_ssh_to_socket_cb, sp);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static const char *sshproxy_socket_error(Socket *s)
{
SshProxy *sp = container_of(s, SshProxy, sock);
return sp->errmsg;
}
static const SocketVtable SshProxy_sock_vt = {
.plug = sshproxy_plug,
.close = sshproxy_close,
.write = sshproxy_write,
.write_oob = sshproxy_write_oob,
.write_eof = sshproxy_write_eof,
.set_frozen = sshproxy_set_frozen,
.socket_error = sshproxy_socket_error,
Centralise stub plug/socket functions. In the previous few commits I noticed some repeated work in the form of pointless empty implementations of Plug's log method, plus some existing (and some new) empty cases of Socket's endpoint_info. As a cleanup, I'm replacing as many as I can find with uses of a central null implementation in the stubs directory.
2024-06-29 11:07:59 +00:00
.endpoint_info = nullsock_endpoint_info,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
};
static void sshproxy_eventlog(LogPolicy *lp, const char *event)
{
SshProxy *sp = container_of(lp, SshProxy, logpolicy);
Pass the calling Socket to plug_log. This enables plug_log to run query methods on the socket in order to find out useful information to log. I don't expect it's sensible to do anything else with it.
2024-06-26 07:29:39 +00:00
log_proxy_stderr(sp->plug, &sp->sock, &sp->psb, event, strlen(event));
log_proxy_stderr(sp->plug, &sp->sock, &sp->psb, "\n", 1);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static int sshproxy_askappend(LogPolicy *lp, Filename *filename,
void (*callback)(void *ctx, int result),
void *ctx)
{
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
SshProxy *sp = container_of(lp, SshProxy, logpolicy);
/*
* If we have access to the outer LogPolicy, pass on this request
* to the end user.
*/
if (sp->clientlp)
return lp_askappend(sp->clientlp, filename, callback, ctx);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
* Otherwise, fall back to the safe noninteractive assumption.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
char *msg = dupprintf("Log file \"%s\" already exists; logging cancelled",
filename_to_str(filename));
sshproxy_eventlog(lp, msg);
sfree(msg);
return 0;
}
static void sshproxy_logging_error(LogPolicy *lp, const char *event)
{
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
SshProxy *sp = container_of(lp, SshProxy, logpolicy);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
* If we have access to the outer LogPolicy, pass on this request
* to it.
*/
if (sp->clientlp) {
lp_logging_error(sp->clientlp, event);
return;
}
/*
* Otherwise, the best we can do is to put it in the outer SSH
* connection's Event Log.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
char *msg = dupprintf("Logging error: %s", event);
sshproxy_eventlog(lp, msg);
sfree(msg);
}
static const LogPolicyVtable SshProxy_logpolicy_vt = {
.eventlog = sshproxy_eventlog,
.askappend = sshproxy_askappend,
.logging_error = sshproxy_logging_error,
.verbose = null_lp_verbose_no,
};
/*
* Function called when we encounter an error during connection setup that's
* likely to be the cause of terminating the proxy SSH connection. Putting it
* in the Event Log is useful on general principles; also putting it in
* sp->errmsg meaks that it will be passed back through plug_closing when the
* proxy SSH connection actually terminates, so that the end user will see
* what went wrong in the proxy connection.
*/
static void sshproxy_error(SshProxy *sp, const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
char *msg = dupvprintf(fmt, ap);
va_end(ap);
if (!sp->errmsg)
sp->errmsg = dupstr(msg);
sshproxy_eventlog(&sp->logpolicy, msg);
sfree(msg);
}
static void try_send_ssh_to_socket(void *ctx)
{
SshProxy *sp = (SshProxy *)ctx;
if (sp->frozen)
return;
while (bufchain_size(&sp->ssh_to_socket)) {
ptrlen pl = bufchain_prefix(&sp->ssh_to_socket);
plug_receive(sp->plug, 0, pl.ptr, pl.len);
bufchain_consume(&sp->ssh_to_socket, pl.len);
}
if (sp->rcvd_eof_ssh_to_socket &&
!sp->sent_eof_ssh_to_socket) {
sp->sent_eof_ssh_to_socket = true;
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
plug_closing_normal(sp->plug);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
}
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
static void sshproxy_notify_session_started(Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
SshProxy: reset trust status after setup completes. The next backend that tries to use the connection we're now proxying is going to expect the seat's trust status to be in trusted mode, because that's how things normally start up when a backend is initialised. So we should set it back to that state before handing on to that backend.
2021-09-16 16:21:03 +00:00
if (sp->clientseat)
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
interactor_return_seat(sp->clientitr);
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
sp->conn_established = true;
SshProxy: reset trust status after setup completes. The next backend that tries to use the connection we're now proxying is going to expect the seat's trust status to be in trusted mode, because that's how things normally start up when a backend is initialised. So we should set it back to that state before handing on to that backend.
2021-09-16 16:21:03 +00:00
Pass the calling Socket to plug_log. This enables plug_log to run query methods on the socket in order to find out useful information to log. I don't expect it's sensible to do anything else with it.
2024-06-26 07:29:39 +00:00
plug_log(sp->plug, &sp->sock, PLUGLOG_CONNECT_SUCCESS, sp->addr, sp->port,
NULL, 0);
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
}
seat_output: add an output type for SSH banners. (NFC) The jump host system ought really to be treating SSH authentication banners as a distinct thing from the standard-error session output, so that the former can be presented to the user in the same way as the auth banner for the main session. This change converts the 'bool is_stderr' parameter of seat_output() into an enumerated type with three values. For the moment, stderr and banners are treated the same, but the plan is for that to change.
2021-09-16 13:46:49 +00:00
static size_t sshproxy_output(Seat *seat, SeatOutputType type,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
const void *data, size_t len)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
SSH proxy: separate stdout from stderr. In the initial version of SSH proxying that only opened direct-tcpip channels, this wasn't important. But as of commit 6f7c52dccee36f6, we now support invoking a command or subsystem on the proxy SSH server, and those _can_ generate stderr data which we must now separate from stdout. Happily, we have a perfectly sensible thing to _do_ with it: the same thing we'd do with stderr coming from a local proxy subprocess, to wit, pass it to log_proxy_stderr so that it can appear in the terminal window (if configured to) and the Event Log.
2022-04-29 15:28:58 +00:00
switch (type) {
case SEAT_OUTPUT_STDOUT:
bufchain_add(&sp->ssh_to_socket, data, len);
try_send_ssh_to_socket(sp);
break;
case SEAT_OUTPUT_STDERR:
Pass the calling Socket to plug_log. This enables plug_log to run query methods on the socket in order to find out useful information to log. I don't expect it's sensible to do anything else with it.
2024-06-26 07:29:39 +00:00
log_proxy_stderr(sp->plug, &sp->sock, &sp->psb, data, len);
SSH proxy: separate stdout from stderr. In the initial version of SSH proxying that only opened direct-tcpip channels, this wasn't important. But as of commit 6f7c52dccee36f6, we now support invoking a command or subsystem on the proxy SSH server, and those _can_ generate stderr data which we must now separate from stdout. Happily, we have a perfectly sensible thing to _do_ with it: the same thing we'd do with stderr coming from a local proxy subprocess, to wit, pass it to log_proxy_stderr so that it can appear in the terminal window (if configured to) and the Event Log.
2022-04-29 15:28:58 +00:00
break;
}
Split seat_banner from seat_output. Previously, SSH authentication banners were displayed by calling the ordinary seat_output function, and passing it a special value in the SeatOutputType enumeration indicating an auth banner. The awkwardness of this was already showing a little in SshProxy's implementation of seat_output, where it had to check for that special value and do totally different things for SEAT_OUTPUT_AUTH_BANNER and everything else. Further work in that area is going to make it more and more awkward if I keep the two output systems unified. So let's split them up. Now, Seat has separate output() and banner() methods, which each implementation can override differently if it wants to. All the 'end user' Seat implementations use the centralised implementation function nullseat_banner_to_stderr(), which turns banner text straight back into SEAT_OUTPUT_STDERR and passes it on to seat_output. So I didn't have to tediously implement a boring version of this function in GTK, Windows GUI, consoles, file transfer etc.
2021-10-30 16:06:00 +00:00
return bufchain_size(&sp->ssh_to_socket);
}
Framework for announcing which Interactor is talking. All this Interactor business has been gradually working towards being able to inform the user _which_ network connection is currently presenting them with a password prompt (or whatever), in situations where more than one of them might be, such as an SSH connection being used as a proxy for another SSH connection when neither one has one-touch login configured. At some point, we have to arrange that any attempt to do a user interaction during connection setup - be it a password prompt, a host key confirmation dialog, or just displaying an SSH login banner - makes it clear which host it's come from. That's going to mean calling some kind of announcement function before doing any of those things. But there are several of those functions in the Seat API, and calls to them are scattered far and wide across the SSH backend. (And not even just there - the Rlogin backend also uses seat_get_userpass_input). How can we possibly make sure we don't forget a vital call site on some obscure little-tested code path, and leave the user confused in just that one case which nobody might notice for years? Today I thought of a trick to solve that problem. We can use the C type system to enforce it for us! The plan is: we invent a new struct type which contains nothing but a 'Seat *'. Then, for every Seat method which does a thing that ought to be clearly identified as relating to a particular Interactor, we adjust the API for that function to take the new struct type where it previously took a plain 'Seat *'. Or rather - doing less violence to the existing code - we only need to adjust the API of the dispatch functions inline in putty.h. How does that help? Because the way you _get_ one of these struct-wrapped Seat pointers is by calling interactor_announce() on your Interactor, which will in turn call interactor_get_seat(), and wrap the returned pointer into one of these structs. The effect is that whenever the SSH (or Rlogin) code wants to call one of those particular Seat methods, it _has_ to call interactor_announce() just beforehand, which (once I finish all of this) will make sure the user is aware of who is presenting the prompt or banner or whatever. And you can't forget to call it, because if you don't call it, then you just don't have a struct of the right type to give to the Seat method you wanted to call! (Of course, there's nothing stopping code from _deliberately_ taking a Seat * it already has and wrapping it into the new struct. In fact SshProxy has to do that, in order to forward these requests up the chain of Seats. But the point is that you can't do it _by accident_, just by forgetting to make a vital function call - when you do that, you _know_ you're doing it on purpose.) No functional change: the new interactor_announce() function exists, and the type-system trick ensures it's called in all the right places, but it doesn't actually _do_ anything yet.
2021-10-30 17:05:36 +00:00
static inline InteractionReadySeat wrap(Seat *seat)
{
sshproxy: improve a couple of comments. Removed the FIXMEs in various Seat passthrough functions that were there to remind me to say which SSH connection they referred to: that is now done by the interactor_announce mechanism, as of commit 215b9d17759ccbd. (Though not by modifying the actual passthrough functions, as it turned out, which is how I didn't find and remove the FIXMEs when I did all that.) Also, added a comment in wrap() explaining *why* it's allowed to (in fact, must) cheat by making an InteractionReadySeat without going through interactor_announce().
2021-11-06 11:31:40 +00:00
/*
* When we receive interaction requests from the proxy and want to
* pass them on to our client Seat, we have to present them to the
* latter in the form of an InteractionReadySeat. This forwarding
* scenario is the one case where we _mustn't_ get an
* InteractionReadySeat by calling interactor_announce(), because
* the point is that we're _not_ the originating Interactor, we're
* just forwarding the request from the real one, which has
* already announced itself.
*
* So, just here in the code, it really is the right thing to make
* an InteractionReadySeat out of a plain Seat * without an
* announcement.
*/
Framework for announcing which Interactor is talking. All this Interactor business has been gradually working towards being able to inform the user _which_ network connection is currently presenting them with a password prompt (or whatever), in situations where more than one of them might be, such as an SSH connection being used as a proxy for another SSH connection when neither one has one-touch login configured. At some point, we have to arrange that any attempt to do a user interaction during connection setup - be it a password prompt, a host key confirmation dialog, or just displaying an SSH login banner - makes it clear which host it's come from. That's going to mean calling some kind of announcement function before doing any of those things. But there are several of those functions in the Seat API, and calls to them are scattered far and wide across the SSH backend. (And not even just there - the Rlogin backend also uses seat_get_userpass_input). How can we possibly make sure we don't forget a vital call site on some obscure little-tested code path, and leave the user confused in just that one case which nobody might notice for years? Today I thought of a trick to solve that problem. We can use the C type system to enforce it for us! The plan is: we invent a new struct type which contains nothing but a 'Seat *'. Then, for every Seat method which does a thing that ought to be clearly identified as relating to a particular Interactor, we adjust the API for that function to take the new struct type where it previously took a plain 'Seat *'. Or rather - doing less violence to the existing code - we only need to adjust the API of the dispatch functions inline in putty.h. How does that help? Because the way you _get_ one of these struct-wrapped Seat pointers is by calling interactor_announce() on your Interactor, which will in turn call interactor_get_seat(), and wrap the returned pointer into one of these structs. The effect is that whenever the SSH (or Rlogin) code wants to call one of those particular Seat methods, it _has_ to call interactor_announce() just beforehand, which (once I finish all of this) will make sure the user is aware of who is presenting the prompt or banner or whatever. And you can't forget to call it, because if you don't call it, then you just don't have a struct of the right type to give to the Seat method you wanted to call! (Of course, there's nothing stopping code from _deliberately_ taking a Seat * it already has and wrapping it into the new struct. In fact SshProxy has to do that, in order to forward these requests up the chain of Seats. But the point is that you can't do it _by accident_, just by forgetting to make a vital function call - when you do that, you _know_ you're doing it on purpose.) No functional change: the new interactor_announce() function exists, and the type-system trick ensures it's called in all the right places, but it doesn't actually _do_ anything yet.
2021-10-30 17:05:36 +00:00
InteractionReadySeat iseat;
iseat.seat = seat;
return iseat;
}
Split seat_banner from seat_output. Previously, SSH authentication banners were displayed by calling the ordinary seat_output function, and passing it a special value in the SeatOutputType enumeration indicating an auth banner. The awkwardness of this was already showing a little in SshProxy's implementation of seat_output, where it had to check for that special value and do totally different things for SEAT_OUTPUT_AUTH_BANNER and everything else. Further work in that area is going to make it more and more awkward if I keep the two output systems unified. So let's split them up. Now, Seat has separate output() and banner() methods, which each implementation can override differently if it wants to. All the 'end user' Seat implementations use the centralised implementation function nullseat_banner_to_stderr(), which turns banner text straight back into SEAT_OUTPUT_STDERR and passes it on to seat_output. So I didn't have to tediously implement a boring version of this function in GTK, Windows GUI, consoles, file transfer etc.
2021-10-30 16:06:00 +00:00
static size_t sshproxy_banner(Seat *seat, const void *data, size_t len)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
if (sp->clientseat) {
/*
* If we have access to the outer Seat, pass the SSH login
* banner on to it.
*/
Framework for announcing which Interactor is talking. All this Interactor business has been gradually working towards being able to inform the user _which_ network connection is currently presenting them with a password prompt (or whatever), in situations where more than one of them might be, such as an SSH connection being used as a proxy for another SSH connection when neither one has one-touch login configured. At some point, we have to arrange that any attempt to do a user interaction during connection setup - be it a password prompt, a host key confirmation dialog, or just displaying an SSH login banner - makes it clear which host it's come from. That's going to mean calling some kind of announcement function before doing any of those things. But there are several of those functions in the Seat API, and calls to them are scattered far and wide across the SSH backend. (And not even just there - the Rlogin backend also uses seat_get_userpass_input). How can we possibly make sure we don't forget a vital call site on some obscure little-tested code path, and leave the user confused in just that one case which nobody might notice for years? Today I thought of a trick to solve that problem. We can use the C type system to enforce it for us! The plan is: we invent a new struct type which contains nothing but a 'Seat *'. Then, for every Seat method which does a thing that ought to be clearly identified as relating to a particular Interactor, we adjust the API for that function to take the new struct type where it previously took a plain 'Seat *'. Or rather - doing less violence to the existing code - we only need to adjust the API of the dispatch functions inline in putty.h. How does that help? Because the way you _get_ one of these struct-wrapped Seat pointers is by calling interactor_announce() on your Interactor, which will in turn call interactor_get_seat(), and wrap the returned pointer into one of these structs. The effect is that whenever the SSH (or Rlogin) code wants to call one of those particular Seat methods, it _has_ to call interactor_announce() just beforehand, which (once I finish all of this) will make sure the user is aware of who is presenting the prompt or banner or whatever. And you can't forget to call it, because if you don't call it, then you just don't have a struct of the right type to give to the Seat method you wanted to call! (Of course, there's nothing stopping code from _deliberately_ taking a Seat * it already has and wrapping it into the new struct. In fact SshProxy has to do that, in order to forward these requests up the chain of Seats. But the point is that you can't do it _by accident_, just by forgetting to make a vital function call - when you do that, you _know_ you're doing it on purpose.) No functional change: the new interactor_announce() function exists, and the type-system trick ensures it's called in all the right places, but it doesn't actually _do_ anything yet.
2021-10-30 17:05:36 +00:00
return seat_banner(wrap(sp->clientseat), data, len);
SshProxy: display auth banners from proxy connections. Now the banners (plus their surrounding antispoof prompts) have their own SeatOutputType, it's easy to distinguish them in sshproxy_output and do the right thing with them.
2021-09-16 16:20:16 +00:00
} else {
Split seat_banner from seat_output. Previously, SSH authentication banners were displayed by calling the ordinary seat_output function, and passing it a special value in the SeatOutputType enumeration indicating an auth banner. The awkwardness of this was already showing a little in SshProxy's implementation of seat_output, where it had to check for that special value and do totally different things for SEAT_OUTPUT_AUTH_BANNER and everything else. Further work in that area is going to make it more and more awkward if I keep the two output systems unified. So let's split them up. Now, Seat has separate output() and banner() methods, which each implementation can override differently if it wants to. All the 'end user' Seat implementations use the centralised implementation function nullseat_banner_to_stderr(), which turns banner text straight back into SEAT_OUTPUT_STDERR and passes it on to seat_output. So I didn't have to tediously implement a boring version of this function in GTK, Windows GUI, consoles, file transfer etc.
2021-10-30 16:06:00 +00:00
return 0;
SshProxy: display auth banners from proxy connections. Now the banners (plus their surrounding antispoof prompts) have their own SeatOutputType, it's easy to distinguish them in sshproxy_output and do the right thing with them.
2021-09-16 16:20:16 +00:00
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static bool sshproxy_eof(Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
sp->rcvd_eof_ssh_to_socket = true;
try_send_ssh_to_socket(sp);
return false;
}
New Seat callback, seat_sent(). This is used to notify the Seat that some data has been cleared from the backend's outgoing data buffer. In other words, it notifies the Seat that it might be worth calling backend_sendbuffer() again. We've never needed this before, because until now, Seats have always been the 'main program' part of the application, meaning they were also in control of the event loop. So they've been able to call backend_sendbuffer() proactively, every time they go round the event loop, instead of having to wait for a callback. But now, the SSH proxy is the first example of a Seat without privileged access to the event loop, so it has no way to find out that the backend's sendbuffer has got smaller. And without that, it can't pass that notification on to plug_sent, to unblock in turn whatever the proxied connection might have been waiting to send. In fact, before this commit, sshproxy.c never called plug_sent at all. As a result, large data uploads over an SSH jump host would hang forever as soon as the outgoing buffer filled up for the first time: the main backend (to which sshproxy.c was acting as a Socket) would carefully stop filling up the buffer, and then never receive the call to plug_sent that would cause it to start again. The new callback is ignored everywhere except in sshproxy.c. It might be a good idea to remove backend_sendbuffer() entirely and convert all previous uses of it into non-empty implementations of this callback, so that we've only got one system; but for the moment, I haven't done that.
2021-06-27 12:52:48 +00:00
static void sshproxy_sent(Seat *seat, size_t new_bufsize)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
plug_sent(sp->plug, new_bufsize);
}
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
static void sshproxy_send_close(SshProxy *sp)
{
if (sp->clientseat)
interactor_return_seat(sp->clientitr);
if (!sp->conn_established)
Pass the calling Socket to plug_log. This enables plug_log to run query methods on the socket in order to find out useful information to log. I don't expect it's sensible to do anything else with it.
2024-06-26 07:29:39 +00:00
plug_log(sp->plug, &sp->sock, PLUGLOG_CONNECT_FAILED, sp->addr,
sp->port, sp->errmsg, 0);
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
if (sp->errmsg)
plug_closing_error(sp->plug, sp->errmsg);
New plug_closing error type for 'user abort'. This is generated when setup of a network connection is cancelled by deliberate user action, namely, pressing ^C or ^D or the like at a get_userpass_input prompt presented during proxy setup. It's handled just like normal socket setup errors, except that it omits the call to seat_connection_fatal, on the grounds that in this one case of connection-setup failure, the user doesn't need to be _informed_ that the connection failed - they already know, because they failed it themself on purpose.
2021-11-06 13:31:09 +00:00
else if (!sp->conn_established && backend_exitcode(sp->backend) == 0)
plug_closing_user_abort(sp->plug);
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
else
plug_closing_normal(sp->plug);
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
}
static void sshproxy_notify_remote_disconnect_callback(void *vctx)
{
SshProxy *sp = (SshProxy *)vctx;
/* notify_remote_disconnect can be called redundantly, so first
* check if the backend really has become disconnected */
if (backend_connected(sp->backend))
return;
sshproxy_send_close(sp);
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
static void sshproxy_notify_remote_disconnect(Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
queue_toplevel_callback(sshproxy_notify_remote_disconnect_callback, sp);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static SeatPromptResult sshproxy_get_userpass_input(Seat *seat, prompts_t *p)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy: pass through userpass input prompts. This is the big payoff from the huge refactoring in the previous commit: now it's possible for proxy implementations to present their own interactive prompts via the seat_get_userpass_input system, because the input data that those prompts will need to consume is now always somewhere sensible (and hasn't, for example, already been put on to the main backend's input queue where the proxy can't get at it). Like the GUI dialog prompts, this isn't yet fully polished, because the login and password prompts are very unclear about which SSH server they're talking about. But at least you now _can_ log in manually with a username and password to two SSH servers in succession (if you know which server(s) you're expecting to see prompts from), and that was the really hard part.
2021-09-14 11:14:37 +00:00
SshProxy *sp = container_of(seat, SshProxy, seat);
SSH proxying: use CONF_proxy_password if available. I was just writing the documentation for the new proxy type, which caused me to realise that the thing I obviously wanted to write in the documentation was not actually true. Let's make it true, and then I can document it!
2021-12-30 11:47:58 +00:00
/*
* If we have a stored proxy_password, use that, via logic similar
* to cmdline_get_passwd_input: we only try it if we're given a
* prompts_t containing exactly one prompt, and that prompt is set
* to non-echoing.
*/
if (sp->got_proxy_password && !sp->tried_proxy_password &&
p->n_prompts == 1 && !p->prompts[0]->echo) {
prompt_set_result(p->prompts[0], sp->proxy_password);
burnstr(sp->proxy_password);
sp->proxy_password = NULL;
sp->tried_proxy_password = true;
return SPR_OK;
}
SshProxy: pass through userpass input prompts. This is the big payoff from the huge refactoring in the previous commit: now it's possible for proxy implementations to present their own interactive prompts via the seat_get_userpass_input system, because the input data that those prompts will need to consume is now always somewhere sensible (and hasn't, for example, already been put on to the main backend's input queue where the proxy can't get at it). Like the GUI dialog prompts, this isn't yet fully polished, because the login and password prompts are very unclear about which SSH server they're talking about. But at least you now _can_ log in manually with a username and password to two SSH servers in succession (if you know which server(s) you're expecting to see prompts from), and that was the really hard part.
2021-09-14 11:14:37 +00:00
if (sp->clientseat) {
/*
* If we have access to the outer Seat, pass this prompt
sshproxy: improve a couple of comments. Removed the FIXMEs in various Seat passthrough functions that were there to remind me to say which SSH connection they referred to: that is now done by the interactor_announce mechanism, as of commit 215b9d17759ccbd. (Though not by modifying the actual passthrough functions, as it turned out, which is how I didn't find and remove the FIXMEs when I did all that.) Also, added a comment in wrap() explaining *why* it's allowed to (in fact, must) cheat by making an InteractionReadySeat without going through interactor_announce().
2021-11-06 11:31:40 +00:00
* request on to it.
SshProxy: pass through userpass input prompts. This is the big payoff from the huge refactoring in the previous commit: now it's possible for proxy implementations to present their own interactive prompts via the seat_get_userpass_input system, because the input data that those prompts will need to consume is now always somewhere sensible (and hasn't, for example, already been put on to the main backend's input queue where the proxy can't get at it). Like the GUI dialog prompts, this isn't yet fully polished, because the login and password prompts are very unclear about which SSH server they're talking about. But at least you now _can_ log in manually with a username and password to two SSH servers in succession (if you know which server(s) you're expecting to see prompts from), and that was the really hard part.
2021-09-14 11:14:37 +00:00
*/
Framework for announcing which Interactor is talking. All this Interactor business has been gradually working towards being able to inform the user _which_ network connection is currently presenting them with a password prompt (or whatever), in situations where more than one of them might be, such as an SSH connection being used as a proxy for another SSH connection when neither one has one-touch login configured. At some point, we have to arrange that any attempt to do a user interaction during connection setup - be it a password prompt, a host key confirmation dialog, or just displaying an SSH login banner - makes it clear which host it's come from. That's going to mean calling some kind of announcement function before doing any of those things. But there are several of those functions in the Seat API, and calls to them are scattered far and wide across the SSH backend. (And not even just there - the Rlogin backend also uses seat_get_userpass_input). How can we possibly make sure we don't forget a vital call site on some obscure little-tested code path, and leave the user confused in just that one case which nobody might notice for years? Today I thought of a trick to solve that problem. We can use the C type system to enforce it for us! The plan is: we invent a new struct type which contains nothing but a 'Seat *'. Then, for every Seat method which does a thing that ought to be clearly identified as relating to a particular Interactor, we adjust the API for that function to take the new struct type where it previously took a plain 'Seat *'. Or rather - doing less violence to the existing code - we only need to adjust the API of the dispatch functions inline in putty.h. How does that help? Because the way you _get_ one of these struct-wrapped Seat pointers is by calling interactor_announce() on your Interactor, which will in turn call interactor_get_seat(), and wrap the returned pointer into one of these structs. The effect is that whenever the SSH (or Rlogin) code wants to call one of those particular Seat methods, it _has_ to call interactor_announce() just beforehand, which (once I finish all of this) will make sure the user is aware of who is presenting the prompt or banner or whatever. And you can't forget to call it, because if you don't call it, then you just don't have a struct of the right type to give to the Seat method you wanted to call! (Of course, there's nothing stopping code from _deliberately_ taking a Seat * it already has and wrapping it into the new struct. In fact SshProxy has to do that, in order to forward these requests up the chain of Seats. But the point is that you can't do it _by accident_, just by forgetting to make a vital function call - when you do that, you _know_ you're doing it on purpose.) No functional change: the new interactor_announce() function exists, and the type-system trick ensures it's called in all the right places, but it doesn't actually _do_ anything yet.
2021-10-30 17:05:36 +00:00
return seat_get_userpass_input(wrap(sp->clientseat), p);
SshProxy: pass through userpass input prompts. This is the big payoff from the huge refactoring in the previous commit: now it's possible for proxy implementations to present their own interactive prompts via the seat_get_userpass_input system, because the input data that those prompts will need to consume is now always somewhere sensible (and hasn't, for example, already been put on to the main backend's input queue where the proxy can't get at it). Like the GUI dialog prompts, this isn't yet fully polished, because the login and password prompts are very unclear about which SSH server they're talking about. But at least you now _can_ log in manually with a username and password to two SSH servers in succession (if you know which server(s) you're expecting to see prompts from), and that was the really hard part.
2021-09-14 11:14:37 +00:00
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
SshProxy: pass through userpass input prompts. This is the big payoff from the huge refactoring in the previous commit: now it's possible for proxy implementations to present their own interactive prompts via the seat_get_userpass_input system, because the input data that those prompts will need to consume is now always somewhere sensible (and hasn't, for example, already been put on to the main backend's input queue where the proxy can't get at it). Like the GUI dialog prompts, this isn't yet fully polished, because the login and password prompts are very unclear about which SSH server they're talking about. But at least you now _can_ log in manually with a username and password to two SSH servers in succession (if you know which server(s) you're expecting to see prompts from), and that was the really hard part.
2021-09-14 11:14:37 +00:00
* Otherwise, behave as if noninteractive (like plink -batch):
* reject all attempts to present a prompt to the user, and log in
* the Event Log to say why not.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
sshproxy_error(sp, "Unable to provide interactive authentication "
"requested by proxy SSH connection");
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_SW_ABORT("Noninteractive SSH proxy cannot perform "
"interactive authentication");
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static void sshproxy_connection_fatal_callback(void *vctx)
{
SshProxy *sp = (SshProxy *)vctx;
sshproxy: fix handling of connection closure. Now we always respond to backend disconnection or connection_fatal by calling plug_closing. And we always do it in a toplevel callback, so that when the Plug responds by calling our Socket close method (which frees us), nothing re-entrant happens. Also, the handling of notify_remote_disconnect is brought into line with the spec in putty.h, which says it can be sent redundantly (when already disconnected) or spuriously (when not even disconnected at all), so the toplevel callback queued by that method will check first. After this change, failures during connection_setup are now handled _mostly_ sensibly: if the proxy connection fails, then the main connection gets enough information to pass a sensible connection_fatal on to the real front end. This also fixes the assertion failure mentioned in the TODO comment, replacing it with a reasonably sensible connection_fatal() - although I still think that in that situation it might be better not to have a dialog box at all.
2021-11-06 11:48:33 +00:00
sshproxy_send_close(sp);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static void sshproxy_connection_fatal(Seat *seat, const char *message)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
if (!sp->errmsg) {
sp->errmsg = dupprintf(
"fatal error in proxy SSH connection: %s", message);
queue_toplevel_callback(sshproxy_connection_fatal_callback, sp);
}
}
New Seat method, seat_nonfatal(). This is like the seat-independent nonfatal(), but specifies a Seat, which allows the GUI dialog box to have the right terminal window as its parent (if there are multiple ones). Changed over all the nonfatal() calls in the code base that could be localised to a Seat, which means all the ones that come up if something goes horribly wrong in host key storage. To make that possible, I've added a 'seat' parameter to store_host_key(); it turns out that all its call sites had one available already.
2022-09-13 07:49:38 +00:00
static void sshproxy_nonfatal(Seat *seat, const char *message)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
if (sp->clientseat)
seat_nonfatal(sp->clientseat, "error in proxy SSH connection: %s",
message);
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static SeatPromptResult sshproxy_confirm_ssh_host_key(
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
Seat *seat, const char *host, int port, const char *keytype,
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
char *keystr, SeatDialogText *text, HelpCtx helpctx,
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy *sp = container_of(seat, SshProxy, seat);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
if (sp->clientseat) {
/*
* If we have access to the outer Seat, pass this prompt
sshproxy: improve a couple of comments. Removed the FIXMEs in various Seat passthrough functions that were there to remind me to say which SSH connection they referred to: that is now done by the interactor_announce mechanism, as of commit 215b9d17759ccbd. (Though not by modifying the actual passthrough functions, as it turned out, which is how I didn't find and remove the FIXMEs when I did all that.) Also, added a comment in wrap() explaining *why* it's allowed to (in fact, must) cheat by making an InteractionReadySeat without going through interactor_announce().
2021-11-06 11:31:40 +00:00
* request on to it.
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
*/
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
return seat_confirm_ssh_host_key(
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
wrap(sp->clientseat), host, port, keytype, keystr, text,
helpctx, callback, ctx);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
* Otherwise, behave as if we're in batch mode, i.e. take the safe
* option in the absence of interactive confirmation, i.e. abort
* the connection.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_SW_ABORT("Noninteractive SSH proxy cannot confirm host key");
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
static void sshproxy_format_seatdialogtext(strbuf *sb, SeatDialogText *text)
{
for (SeatDialogTextItem *item = text->items,
*end = item+text->nitems; item < end; item++) {
switch (item->type) {
case SDT_SCARY_HEADING:
case SDT_PARA:
case SDT_DISPLAY:
put_stringz(sb, item->text);
put_byte(sb, '\n');
break;
case SDT_BATCH_ABORT:
put_stringz(sb, item->text);
put_byte(sb, '\n');
goto endloop;
default:
break;
}
}
endloop:
while (strbuf_chomp(sb, '\n'));
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static SeatPromptResult sshproxy_confirm_weak_crypto_primitive(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
Seat *seat, SeatDialogText *text,
Formatting: normalise back to 4-space indentation. In several pieces of development recently I've run across the occasional code block in the middle of a function which suddenly switched to 2-space indent from this code base's usual 4. I decided I was tired of it, so I ran the whole code base through a re-indenter, which made a huge mess, and then manually sifted out the changes that actually made sense from that pass. Indeed, this caught quite a few large sections with 2-space indent level, a couple with 8, and a handful of even weirder things like 3 spaces or 12. This commit fixes them all.
2022-08-03 19:48:46 +00:00
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy *sp = container_of(seat, SshProxy, seat);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
if (sp->clientseat) {
/*
* If we have access to the outer Seat, pass this prompt
sshproxy: improve a couple of comments. Removed the FIXMEs in various Seat passthrough functions that were there to remind me to say which SSH connection they referred to: that is now done by the interactor_announce mechanism, as of commit 215b9d17759ccbd. (Though not by modifying the actual passthrough functions, as it turned out, which is how I didn't find and remove the FIXMEs when I did all that.) Also, added a comment in wrap() explaining *why* it's allowed to (in fact, must) cheat by making an InteractionReadySeat without going through interactor_announce().
2021-11-06 11:31:40 +00:00
* request on to it.
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
*/
return seat_confirm_weak_crypto_primitive(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
wrap(sp->clientseat), text, callback, ctx);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
* Otherwise, behave as if we're in batch mode: take the safest
* option.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
strbuf *sb = strbuf_new();
sshproxy_format_seatdialogtext(sb, text);
sshproxy_error(sp, sb->s);
strbuf_free(sb);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_SW_ABORT("Noninteractive SSH proxy cannot confirm "
"weak crypto primitive");
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
static SeatPromptResult sshproxy_confirm_weak_cached_hostkey(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
Seat *seat, SeatDialogText *text,
Formatting: normalise back to 4-space indentation. In several pieces of development recently I've run across the occasional code block in the middle of a function which suddenly switched to 2-space indent from this code base's usual 4. I decided I was tired of it, so I ran the whole code base through a re-indenter, which made a huge mess, and then manually sifted out the changes that actually made sense from that pass. Indeed, this caught quite a few large sections with 2-space indent level, a couple with 8, and a handful of even weirder things like 3 spaces or 12. This commit fixes them all.
2022-08-03 19:48:46 +00:00
void (*callback)(void *ctx, SeatPromptResult result), void *ctx)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy *sp = container_of(seat, SshProxy, seat);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
if (sp->clientseat) {
/*
* If we have access to the outer Seat, pass this prompt
sshproxy: improve a couple of comments. Removed the FIXMEs in various Seat passthrough functions that were there to remind me to say which SSH connection they referred to: that is now done by the interactor_announce mechanism, as of commit 215b9d17759ccbd. (Though not by modifying the actual passthrough functions, as it turned out, which is how I didn't find and remove the FIXMEs when I did all that.) Also, added a comment in wrap() explaining *why* it's allowed to (in fact, must) cheat by making an InteractionReadySeat without going through interactor_announce().
2021-11-06 11:31:40 +00:00
* request on to it.
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
*/
return seat_confirm_weak_cached_hostkey(
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
wrap(sp->clientseat), text, callback, ctx);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
* Otherwise, behave as if we're in batch mode: take the safest
* option.
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
*/
Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once.
2023-11-22 08:57:54 +00:00
strbuf *sb = strbuf_new();
sshproxy_format_seatdialogtext(sb, text);
sshproxy_error(sp, sb->s);
strbuf_free(sb);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
return SPR_SW_ABORT("Noninteractive SSH proxy cannot confirm "
"weak cached host key");
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
static const SeatDialogPromptDescriptions *sshproxy_prompt_descriptions(
Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
/* If we have a client seat, return their prompt descriptions, so
* that prompts passed on to them will make sense. */
if (sp->clientseat)
return seat_prompt_descriptions(sp->clientseat);
/* Otherwise, it doesn't matter what we return, so do the easiest thing. */
return nullseat_prompt_descriptions(NULL);
}
SshProxy: pass some more functions to the client seat. Now that we're actually using it for messages, we also need to pass its interactivity setting through to the subsidiary SSH backend, because otherwise that won't know whether to display particular messages. Same goes for constructing a StripCtrl for SSH auth banners (which wants to be done the same way between primary and proxy SSH connections), and so on.
2021-09-16 16:18:49 +00:00
static StripCtrlChars *sshproxy_stripctrl_new(
Seat *seat, BinarySink *bs_out, SeatInteractionContext sic)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
if (sp->clientseat)
return seat_stripctrl_new(sp->clientseat, bs_out, sic);
else
return NULL;
}
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
static void sshproxy_set_trust_status(Seat *seat, bool trusted)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy: pass some more functions to the client seat. Now that we're actually using it for messages, we also need to pass its interactivity setting through to the subsidiary SSH backend, because otherwise that won't know whether to display particular messages. Same goes for constructing a StripCtrl for SSH auth banners (which wants to be done the same way between primary and proxy SSH connections), and so on.
2021-09-16 16:18:49 +00:00
SshProxy *sp = container_of(seat, SshProxy, seat);
if (sp->clientseat)
seat_set_trust_status(sp->clientseat, trusted);
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
}
static bool sshproxy_can_set_trust_status(Seat *seat)
{
SshProxy: pass some more functions to the client seat. Now that we're actually using it for messages, we also need to pass its interactivity setting through to the subsidiary SSH backend, because otherwise that won't know whether to display particular messages. Same goes for constructing a StripCtrl for SSH auth banners (which wants to be done the same way between primary and proxy SSH connections), and so on.
2021-09-16 16:18:49 +00:00
SshProxy *sp = container_of(seat, SshProxy, seat);
return sp->clientseat && seat_can_set_trust_status(sp->clientseat);
}
static bool sshproxy_verbose(Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
return sp->clientseat && seat_verbose(sp->clientseat);
}
static bool sshproxy_interactive(Seat *seat)
{
SshProxy *sp = container_of(seat, SshProxy, seat);
return sp->clientseat && seat_interactive(sp->clientseat);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
}
static const SeatVtable SshProxy_seat_vt = {
.output = sshproxy_output,
.eof = sshproxy_eof,
New Seat callback, seat_sent(). This is used to notify the Seat that some data has been cleared from the backend's outgoing data buffer. In other words, it notifies the Seat that it might be worth calling backend_sendbuffer() again. We've never needed this before, because until now, Seats have always been the 'main program' part of the application, meaning they were also in control of the event loop. So they've been able to call backend_sendbuffer() proactively, every time they go round the event loop, instead of having to wait for a callback. But now, the SSH proxy is the first example of a Seat without privileged access to the event loop, so it has no way to find out that the backend's sendbuffer has got smaller. And without that, it can't pass that notification on to plug_sent, to unblock in turn whatever the proxied connection might have been waiting to send. In fact, before this commit, sshproxy.c never called plug_sent at all. As a result, large data uploads over an SSH jump host would hang forever as soon as the outgoing buffer filled up for the first time: the main backend (to which sshproxy.c was acting as a Socket) would carefully stop filling up the buffer, and then never receive the call to plug_sent that would cause it to start again. The new callback is ignored everywhere except in sshproxy.c. It might be a good idea to remove backend_sendbuffer() entirely and convert all previous uses of it into non-empty implementations of this callback, so that we've only got one system; but for the moment, I haven't done that.
2021-06-27 12:52:48 +00:00
.sent = sshproxy_sent,
Split seat_banner from seat_output. Previously, SSH authentication banners were displayed by calling the ordinary seat_output function, and passing it a special value in the SeatOutputType enumeration indicating an auth banner. The awkwardness of this was already showing a little in SshProxy's implementation of seat_output, where it had to check for that special value and do totally different things for SEAT_OUTPUT_AUTH_BANNER and everything else. Further work in that area is going to make it more and more awkward if I keep the two output systems unified. So let's split them up. Now, Seat has separate output() and banner() methods, which each implementation can override differently if it wants to. All the 'end user' Seat implementations use the centralised implementation function nullseat_banner_to_stderr(), which turns banner text straight back into SEAT_OUTPUT_STDERR and passes it on to seat_output. So I didn't have to tediously implement a boring version of this function in GTK, Windows GUI, consoles, file transfer etc.
2021-10-30 16:06:00 +00:00
.banner = sshproxy_banner,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.get_userpass_input = sshproxy_get_userpass_input,
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
.notify_session_started = sshproxy_notify_session_started,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.notify_remote_exit = nullseat_notify_remote_exit,
.notify_remote_disconnect = sshproxy_notify_remote_disconnect,
.connection_fatal = sshproxy_connection_fatal,
New Seat method, seat_nonfatal(). This is like the seat-independent nonfatal(), but specifies a Seat, which allows the GUI dialog box to have the right terminal window as its parent (if there are multiple ones). Changed over all the nonfatal() calls in the code base that could be localised to a Seat, which means all the ones that come up if something goes horribly wrong in host key storage. To make that possible, I've added a 'seat' parameter to store_host_key(); it turns out that all its call sites had one available already.
2022-09-13 07:49:38 +00:00
.nonfatal = sshproxy_nonfatal,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.update_specials_menu = nullseat_update_specials_menu,
.get_ttymode = nullseat_get_ttymode,
.set_busy_status = nullseat_set_busy_status,
Reorganise host key checking and confirmation. Previously, checking the host key against the persistent cache managed by the storage.h API was done as part of the seat_verify_ssh_host_key method, i.e. separately by each Seat. Now that check is done by verify_ssh_host_key(), which is a new function in ssh/common.c that centralises all the parts of host key checking that don't need an interactive prompt. It subsumes the previous verify_ssh_manual_host_key() that checked against the Conf, and it does the check against the storage API that each Seat was previously doing separately. If it can't confirm or definitively reject the host key by itself, _then_ it calls out to the Seat, once an interactive prompt is definitely needed. The main point of doing this is so that when SshProxy forwards a Seat call from the proxy SSH connection to the primary Seat, it won't print an announcement of which connection is involved unless it's actually going to do something interactive. (Not that we're printing those announcements _yet_ anyway, but this is a piece of groundwork that works towards doing so.) But while I'm at it, I've also taken the opportunity to clean things up a bit by renaming functions sensibly. Previously we had three very similarly named functions verify_ssh_manual_host_key(), SeatVtable's 'verify_ssh_host_key' method, and verify_host_key() in storage.h. Now the Seat method is called 'confirm' rather than 'verify' (since its job is now always to print an interactive prompt, so it looks more like the other confirm_foo methods), and the storage.h function is called check_stored_host_key(), which goes better with store_host_key and avoids having too many functions with similar names. And the 'manual' function is subsumed into the new centralised code, so there's now just *one* host key function with 'verify' in the name. Several functions are reindented in this commit. Best viewed with whitespace changes ignored.
2021-10-25 17:12:17 +00:00
.confirm_ssh_host_key = sshproxy_confirm_ssh_host_key,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.confirm_weak_crypto_primitive = sshproxy_confirm_weak_crypto_primitive,
.confirm_weak_cached_hostkey = sshproxy_confirm_weak_cached_hostkey,
Centralise most details of host-key prompting. The text of the host key warnings was replicated in three places: the Windows rc file, the GTK dialog setup function, and the console.c shared between both platforms' CLI tools. Now it lives in just one place, namely ssh/common.c where the rest of the centralised host-key checking is done, so it'll be easier to adjust the wording in future. This comes with some extra automation. Paragraph wrapping is no longer done by hand in any version of these prompts. (Previously we let GTK do the wrapping on GTK, but on Windows the resource file contained a bunch of pre-wrapped LTEXT lines, and console.c had pre-wrapped terminal messages.) And the dialog heights in Windows are determined automatically based on the amount of stuff in the window. The main idea of all this is that it'll be easier to set up more elaborate kinds of host key prompt that deal with certificates (if, e.g., a server sends us a certified host key which we don't trust the CA for). But there are side benefits of this refactoring too: each tool now reliably inserts its own appname in the prompts, and also, on Windows the entire prompt text is copy-pastable. Details of implementation: there's a new type SeatDialogText which holds a set of (type, string) pairs describing the contents of a prompt. Type codes distinguish ordinary text paragraphs, paragraphs to be displayed prominently (like key fingerprints), the extra-bold scary title at the top of the 'host key changed' version of the dialog, and the various information that lives in the subsidiary 'more info' box. ssh/common.c constructs this, and passes it to the Seat to present the actual prompt. In order to deal with the different UI for answering the prompt, I've added an extra Seat method 'prompt_descriptions' which returns some snippets of text to interpolate into the messages. ssh/common.c calls that while it's still constructing the text, and incorporates the resulting snippets into the SeatDialogText. For the moment, this refactoring only affects the host key prompts. The warnings about outmoded crypto are still done the old-fashioned way; they probably ought to be similarly refactored to use this new SeatDialogText system, but it's not immediately critical for the purpose I have right now.
2022-07-07 16:25:15 +00:00
.prompt_descriptions = sshproxy_prompt_descriptions,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.is_utf8 = nullseat_is_never_utf8,
.echoedit_update = nullseat_echoedit_update,
.get_x_display = nullseat_get_x_display,
.get_windowid = nullseat_get_windowid,
.get_window_pixel_size = nullseat_get_window_pixel_size,
SshProxy: pass some more functions to the client seat. Now that we're actually using it for messages, we also need to pass its interactivity setting through to the subsidiary SSH backend, because otherwise that won't know whether to display particular messages. Same goes for constructing a StripCtrl for SSH auth banners (which wants to be done the same way between primary and proxy SSH connections), and so on.
2021-09-16 16:18:49 +00:00
.stripctrl_new = sshproxy_stripctrl_new,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.set_trust_status = sshproxy_set_trust_status,
Divide seat_set_trust_status into query and update. This complicates the API in one sense (more separate functions), but in another sense, simplifies it (each function does something simpler). When I start putting one Seat in front of another during SSH proxying, the latter will be more important - in particular, it means you can find out _whether_ a seat can support changing trust status without having to actually attempt a destructive modification.
2021-09-12 08:52:46 +00:00
.can_set_trust_status = sshproxy_can_set_trust_status,
New Seat query, has_mixed_input_stream(). (TL;DR: to suppress redundant 'Press Return to begin session' prompts in between hops of a jump-host configuration, in Plink.) This new query method directly asks the Seat the question: is the same stream of input used to provide responses to interactive login prompts, and the session input provided after login concludes? It's used to suppress the last-ditch anti-spoofing defence in Plink of interactively asking 'Access granted. Press Return to begin session', on the basis that any such spoofing attack works by confusing the user about what's a legit login prompt before the session begins and what's sent by the server after the main session begins - so if those two things take input from different places, the user can't be confused. This doesn't change the existing behaviour of Plink, which was already suppressing the antispoof prompt in cases where its standard input was redirected from something other than a terminal. But previously it was doing it within the can_set_trust_status() seat query, and I've now moved it out into a separate query function. The reason why these need to be separate is for SshProxy, which needs to give an unusual combination of answers when run inside Plink. For can_set_trust_status(), it needs to return whatever the parent Seat returns, so that all the login prompts for a string of proxy connections in session will be antispoofed the same way. But you only want that final 'Access granted' prompt to happen _once_, after all the proxy connection setup phases are done, because up until then you're still in the safe hands of PuTTY itself presenting an unbroken sequence of legit login prompts (even if they come from a succession of different servers). Hence, SshProxy unconditionally returns 'no' to the query of whether it has a single mixed input stream, because indeed, it never does - for purposes of session input it behaves like an always-redirected Plink, no matter what kind of real Seat it ends up sending its pre-session login prompts to.
2021-11-06 14:33:03 +00:00
.has_mixed_input_stream = nullseat_has_mixed_input_stream_no,
SshProxy: pass some more functions to the client seat. Now that we're actually using it for messages, we also need to pass its interactivity setting through to the subsidiary SSH backend, because otherwise that won't know whether to display particular messages. Same goes for constructing a StripCtrl for SSH auth banners (which wants to be done the same way between primary and proxy SSH connections), and so on.
2021-09-16 16:18:49 +00:00
.verbose = sshproxy_verbose,
.interactive = sshproxy_interactive,
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
.get_cursor_position = nullseat_get_cursor_position,
};
Socket *sshproxy_new_connection(SockAddr *addr, const char *hostname,
int port, bool privport,
bool oobinline, bool nodelay, bool keepalive,
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
Plug *plug, Conf *clientconf,
Pass an Interactor to new_connection(). Thanks to the previous commit, this new parameter can replace two of the existing ones: instead of passing a LogPolicy and a Seat, we now pass just an Interactor, from which any proxy implementation can extract the LogPolicy and the Seat anyway if they need it.
2021-10-30 16:36:52 +00:00
Interactor *clientitr)
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
{
SshProxy *sp = snew(SshProxy);
memset(sp, 0, sizeof(*sp));
sp->sock.vt = &SshProxy_sock_vt;
sp->logpolicy.vt = &SshProxy_logpolicy_vt;
sp->seat.vt = &SshProxy_seat_vt;
sp->plug = plug;
psb_init(&sp->psb);
bufchain_init(&sp->ssh_to_socket);
sshproxy: keep addr and free it on close. The caller of new_connection has relinquished ownership of the SockAddr it passes in. So the receiver of that SockAddr must remember to free it, or else we leak memory. (Additionally, this means SshProxy will be able to remember the address during its run, e.g. to use in calls to its Plug. But that's not implemented yet.)
2021-09-12 08:52:46 +00:00
sp->addr = addr;
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
sp->port = port;
sshproxy: keep addr and free it on close. The caller of new_connection has relinquished ownership of the SockAddr it passes in. So the receiver of that SockAddr must remember to free it, or else we leak memory. (Additionally, this means SshProxy will be able to remember the address during its run, e.g. to use in calls to its Plug. But that's not implemented yet.)
2021-09-12 08:52:46 +00:00
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sp->conf = conf_new();
/* Try to treat proxy_hostname as the title of a saved session. If
* that fails, set up a default Conf of our own treating it as a
* hostname. */
const char *proxy_hostname = conf_get_str(clientconf, CONF_proxy_host);
if (do_defaults(proxy_hostname, sp->conf)) {
if (!conf_launchable(sp->conf)) {
sp->errmsg = dupprintf("saved session '%s' is not launchable",
proxy_hostname);
return &sp->sock;
}
} else {
do_defaults(NULL, sp->conf);
/* In hostname mode, we default to PROT_SSH. This is more useful than
* the obvious approach of defaulting to the protocol defined in
* Default Settings, because only SSH (ok, and bare ssh-connection)
* can be used for this kind of proxy. */
conf_set_int(sp->conf, CONF_protocol, PROT_SSH);
conf_set_str(sp->conf, CONF_host, proxy_hostname);
conf_set_int(sp->conf, CONF_port,
conf_get_int(clientconf, CONF_proxy_port));
}
const char *proxy_username = conf_get_str(clientconf, CONF_proxy_username);
if (*proxy_username)
conf_set_str(sp->conf, CONF_username, proxy_username);
SSH proxying: use CONF_proxy_password if available. I was just writing the documentation for the new proxy type, which caused me to realise that the thing I obviously wanted to write in the documentation was not actually true. Let's make it true, and then I can document it!
2021-12-30 11:47:58 +00:00
const char *proxy_password = conf_get_str(clientconf, CONF_proxy_password);
if (*proxy_password) {
sp->proxy_password = dupstr(proxy_password);
sp->got_proxy_password = true;
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
const struct BackendVtable *backvt = backend_vt_from_proto(
conf_get_int(sp->conf, CONF_protocol));
/*
* We don't actually need an _SSH_ session specifically: it's also
* OK to use PROT_SSHCONN, because really, the criterion is
* whether setting CONF_ssh_nc_host will do anything useful. So
* our check is for whether the backend sets the flag promising
* that it does.
*/
sshproxy.c: add missing NULL check. If you try to use a saved session for SSH proxying which specifies a protocol that is not SSH or bare-SSH-connection, you get a clean error return from the proxy setup code - *provided* it's at least a protocol known to this particular build of PuTTY. If it's one so outlandish that backend_vt_from_proto returns NULL, there'd have been a crash. I don't think any such protocol currently exists, but if in the next version of PuTTY some additional protocol becomes supported, it will trip this error in the current version. Spotted by Coverity.
2022-01-29 18:03:33 +00:00
if (!backvt || !(backvt->flags & BACKEND_SUPPORTS_NC_HOST)) {
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sp->errmsg = dupprintf("saved session '%s' is not an SSH session",
proxy_hostname);
return &sp->sock;
}
New Seat method, notify_session_started(). This is called by the backend to notify the Seat that the connection has progressed to the point where the main session channel (i.e. the thing that would typically correspond to the client's stdin/stdout) has been successfully set up. The only Seat that implements this method nontrivially is the one in SshProxy, which uses it as an indication that the proxied connection to the remote host has succeeded, and sends the PLUGLOG_CONNECT_SUCCESS notification to its own Plug. Hence, the only backends that need to implement it at the moment are the two SSH-shaped backends (SSH proper and bare-connection / psusan). For other backends, it's not always obvious what 'main session channel' would even mean, or whether it means anything very useful; so I've also introduced a backend flag indicating whether the backend is expecting to call that method at all, so as not to have to spend pointless effort on defining an arbitrary meaning for it in other contexts. So a lot of this patch is just introducing the new method and putting its trivial do-nothing implementation into all the existing Seat methods. The interesting parts happen in ssh/mainchan.c (which actually calls it), and sshproxy.c (which does something useful in response).
2021-09-12 10:48:42 +00:00
/*
* We also expect that the backend will announce a willingness to
* notify us that the session has started. Any backend providing
* NC_HOST should also provide this.
*/
assert(backvt->flags & BACKEND_NOTIFIES_SESSION_START &&
"Backend provides NC_HOST without SESSION_START!");
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
/*
* Turn off SSH features we definitely don't want. It would be
* awkward and counterintuitive to have the proxy SSH connection
* become a connection-sharing upstream (but it's fine to have it
* be a downstream, if that's configured). And we don't want to
* open X forwardings, agent forwardings or (other) port
* forwardings as a side effect of this one operation.
*/
conf_set_bool(sp->conf, CONF_ssh_connection_sharing_upstream, false);
conf_set_bool(sp->conf, CONF_x11_forward, false);
conf_set_bool(sp->conf, CONF_agentfwd, false);
for (const char *subkey;
(subkey = conf_get_str_nthstrkey(sp->conf, CONF_portfwd, 0)) != NULL;)
conf_del_str_str(sp->conf, CONF_portfwd, subkey);
/*
* We'll only be running one channel through this connection
* (since we've just turned off all the other things we might have
* done with it), so we can configure it as simple.
*/
conf_set_bool(sp->conf, CONF_ssh_simple, true);
Add exec/subsystem versions of SSH proxying. This is a simple tweak to the existing in-process SSH jump host support, where instead of opening a direct-tcpip channel to the destination host, we open a session channel and run a process in it to make the connection to the destination. So, where the existing jump host support replaced a local proxy command along the lines of "plink %proxyhost -nc %host %port", this one replaces "plink %proxyhost run-some-command". Also added a corresponding option to use a subsystem to make the connection. (Someone could configure an SSH server to support specific subsystem names for particular destinations, or a general schema of subsystem names that include the destination address in some standard format.) To avoid overflowing the already-full Proxy config panel with an extra subtype selector, I've put these in as additional top-level proxy types, so that instead of just PROXY_SSH we now have three PROXY_SSH_foo.
2022-04-22 13:12:15 +00:00
int proxy_type = conf_get_int(clientconf, CONF_proxy_type);
switch (proxy_type) {
case PROXY_SSH_TCPIP:
/*
* Configure the main channel of this SSH session to be a
* direct-tcpip connection to the destination host/port.
*/
conf_set_str(sp->conf, CONF_ssh_nc_host, hostname);
conf_set_int(sp->conf, CONF_ssh_nc_port, port);
break;
case PROXY_SSH_SUBSYSTEM:
case PROXY_SSH_EXEC: {
Conf *cmd_conf = conf_copy(clientconf);
/*
* Unlike the Telnet and Local proxy types, we don't use the
* proxy username and password fields in the formatted
* command, because if we use them at all, it's for
* authenticating to the proxy SSH server.
*/
conf_set_str(cmd_conf, CONF_proxy_username, "");
conf_set_str(cmd_conf, CONF_proxy_password, "");
char *cmd = format_telnet_command(sp->addr, sp->port, cmd_conf, NULL);
conf_free(cmd_conf);
conf_set_str(sp->conf, CONF_remote_cmd, cmd);
sfree(cmd);
conf_set_bool(sp->conf, CONF_nopty, true);
if (proxy_type == PROXY_SSH_SUBSYSTEM)
conf_set_bool(sp->conf, CONF_ssh_subsys, true);
break;
}
default:
unreachable("bad SSH proxy type");
}
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sshproxy.c: remember to call prepare_session(). prepare_session() is the function that takes a Conf in the form it was loaded from the configuration, and normalises it into the form that backends can make sense of easily. In particular, if CONF_host contains something like "user@hostname", this is the place where the "user@" is stripped off the hostname field and moved into CONF_username where the backend will expect to find it. Therefore, you're _always_ supposed to call prepare_session() before launching a backend from a Conf you (potentially) got from a saved session. But the SSH proxy code forgot to. As a result, if you had a saved session with "user@hostname" in the hostname field, it would work fine to launch that session directly in PuTTY, but trying to use the same saved session as an SSH proxy would fail mysteriously after trying to pass "user@hostname" to getaddrinfo() and getting nothing useful back. (On Windows, the error message is especially opaque: an invalid string of that kind generates an error code that we weren't even tranlsating. And even if we _do_ translate it, it wouldn't be very meaningful, because the error in question is WSANO_RECOVERY, which FormatMessage renders as "A non-recoverable error occurred during a database lookup." I guess the error in question was that Windows couldn't even figure out how to translate that string into the format of a DNS request message!)
2022-04-29 15:41:18 +00:00
/*
* Do the usual normalisation of things in the Conf like a "user@"
* prefix on the hostname field.
*/
prepare_session(sp->conf);
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
sp->logctx = log_init(&sp->logpolicy, sp->conf);
char *error, *realhost;
error = backend_init(backvt, &sp->seat, &sp->backend, sp->logctx, sp->conf,
conf_get_str(sp->conf, CONF_host),
conf_get_int(sp->conf, CONF_port),
&realhost, nodelay,
conf_get_bool(sp->conf, CONF_tcp_keepalives));
if (error) {
sp->errmsg = dupprintf("unable to open SSH proxy connection: %s",
error);
return &sp->sock;
}
sfree(realhost);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
/*
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
* If we've been given an Interactor by the caller, set ourselves
* up to work with it.
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
*/
Pass an Interactor to new_connection(). Thanks to the previous commit, this new parameter can replace two of the existing ones: instead of passing a LogPolicy and a Seat, we now pass just an Interactor, from which any proxy implementation can extract the LogPolicy and the Seat anyway if they need it.
2021-10-30 16:36:52 +00:00
if (clientitr) {
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
sp->clientitr = clientitr;
Actually print announcements of Interactors' identity. Finally, the payoff from all of this refactoring: now, when a proxy prompts interactively during connection setup, you get a message in advance telling you which Interactor is originating the following messages. To achieve this, I've arranged to link Interactors together into a list, so that any Interactor created by a proxy has a 'parent' pointer pointing to the Interactor its client passed to new_connection(). This allows interactor_announce() to follow the links back up the chain and count them, so that it knows whether it's a primary connection, or a proxy, or a proxy-for-a-proxy, or more generally an nth-order proxy, and can include that in its announcement. And secondly, once interactor_announce() reaches the top of the chain, it can use that as a storage location agreed on by all Interactors in the whole setup, to tell each other which one of them was the last to do anything interactive. Then, whenever there's a change of Interactor, a message can be printed to indicate it to the user; and when the same Interactor does multiple things in succession, you don't get a slew of pointless messages in between them all.
2021-10-30 17:08:02 +00:00
interactor_set_child(sp->clientitr, sp->backend->interactor);
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
Pass an Interactor to new_connection(). Thanks to the previous commit, this new parameter can replace two of the existing ones: instead of passing a LogPolicy and a Seat, we now pass just an Interactor, from which any proxy implementation can extract the LogPolicy and the Seat anyway if they need it.
2021-10-30 16:36:52 +00:00
sp->clientlp = interactor_logpolicy(clientitr);
Move TempSeat creation/destruction into Interactor. Previously, SshProxy dealt with creating a TempSeat to wrap the one it was borrowing from its client, and then each client in turn dealt with detecting when it had had its seat borrowed and finishing up with the TempSeat. The latter involved a lot of code duplication; the former didn't involve code duplication _yet_ (since SshProxy was the only thing doing this job), but would have once we started wanting to do interactive password prompting for other types of network proxy. Now all of that functionality is centralised into two new Interactor helper functions: interactor_borrow_seat and interactor_return_seat.
2021-10-30 16:45:38 +00:00
/*
* We can only borrow the client's Seat if our own backend
* will tell us when to give it back. (SSH-based backends
* _should_ do that, but we check the flag here anyway.)
*/
if (backvt->flags & BACKEND_NOTIFIES_SESSION_START)
sp->clientseat = interactor_borrow_seat(clientitr);
sshproxy: borrow a Seat for host key and crypto dialogs. This puts the previous commit's framework to practical use. Now the main new_connection() passes its Seat ** through to the SshProxy setup function, which (if the stars align) will actually use it: stash it, return a TempSeat wrapper on it for the main backend to use in the interim, and pass through the GUI dialog prompts for host key confirmation and weak-crypto warnings. This is unfinished at the UI end: those dialog prompts will now need to be much clearer about which SSH server they're talking to (since now there could be two involved), and I haven't made that change yet. I haven't attempted to deal with get_userpass_input yet, though. That's much harder, and I'm still working on it.
2021-09-13 15:30:59 +00:00
}
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
Initial support for in-process proxy SSH connections. This introduces a new entry to the radio-button list of proxy types, in which the 'Proxy host' box is taken to be the name of an SSH server or saved session. We make an entire subsidiary SSH connection to that host, open a direct-tcpip channel through it, and use that as the connection over which to run the primary network connection. The result is basically the same as if you used a local proxy subprocess, with a command along the lines of 'plink -batch %proxyhost -nc %host:%port'. But it's all done in-process, by having an SshProxy object implement the Socket trait to talk to the main connection, and implement Seat and LogPolicy to talk to its subsidiary SSH backend. All the refactoring in recent years has got us to the point where we can do that without both SSH instances fighting over some global variable or unique piece of infrastructure. From an end user perspective, doing SSH proxying in-process like this is a little bit easier to set up: it doesn't require you to bake the full pathname of Plink into your saved session (or to have it on the system PATH), and the SshProxy setup function automatically turns off SSH features that would be inappropriate in this context, such as additional port forwardings, or acting as a connection-sharing upstream. And it has minor advantages like getting the Event Log for the subsidiary connection interleaved in the main Event Log, as if it were stderr output from a proxy subcommand, without having to deliberately configure the subsidiary Plink into verbose mode. However, this is an initial implementation only, and it doesn't yet support the _big_ payoff for doing this in-process, which (I hope) will be the ability to handle interactive prompts from the subsidiary SSH connection via the same user interface as the primary one. For example, you might need to answer two password prompts in succession, or (the first time you use a session configured this way) confirm the host keys for both proxy and destination SSH servers. Comments in the new source file discuss some design thoughts on filling in this gap. For the moment, if the proxy SSH connection encounters any situation where an interactive prompt is needed, it will make the safe assumption, the same way 'plink -batch' would do. So it's at least no _worse_ than the existing technique of putting the proxy connection in a subprocess.
2021-05-22 11:51:23 +00:00
return &sp->sock;
}
Reference in New Issue Copy Permalink