Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
/*
|
|
|
|
* Server side of key exchange for the SSH-2 transport protocol (RFC 4253).
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
#include "putty.h"
|
|
|
|
#include "ssh.h"
|
|
|
|
#include "sshbpp.h"
|
|
|
|
#include "sshppl.h"
|
|
|
|
#include "sshcr.h"
|
|
|
|
#include "storage.h"
|
|
|
|
#include "ssh2transport.h"
|
|
|
|
|
|
|
|
void ssh2_transport_provide_hostkeys(PacketProtocolLayer *ppl,
|
|
|
|
ssh_key *const *hostkeys, int nhostkeys)
|
|
|
|
{
|
|
|
|
struct ssh2_transport_state *s =
|
|
|
|
container_of(ppl, struct ssh2_transport_state, ppl);
|
|
|
|
|
|
|
|
s->hostkeys = hostkeys;
|
|
|
|
s->nhostkeys = nhostkeys;
|
|
|
|
}
|
|
|
|
|
|
|
|
static strbuf *finalise_and_sign_exhash(struct ssh2_transport_state *s)
|
|
|
|
{
|
|
|
|
strbuf *sb;
|
|
|
|
ssh2transport_finalise_exhash(s);
|
|
|
|
sb = strbuf_new();
|
2018-11-19 20:24:37 +00:00
|
|
|
ssh_key_sign(s->hkey, s->exchange_hash, s->kex_alg->hash->hlen, 0,
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
BinarySink_UPCAST(sb));
|
|
|
|
return sb;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void no_progress(void *param, int action, int phase, int iprogress)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssh2kex_coroutine(struct ssh2_transport_state *s)
|
|
|
|
{
|
|
|
|
PacketProtocolLayer *ppl = &s->ppl; /* for ppl_logevent */
|
|
|
|
PktIn *pktin;
|
|
|
|
PktOut *pktout;
|
|
|
|
|
|
|
|
crBegin(s->crStateKex);
|
|
|
|
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < s->nhostkeys; i++)
|
|
|
|
if (ssh_key_alg(s->hostkeys[i]) == s->hostkey_alg) {
|
|
|
|
s->hkey = s->hostkeys[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
assert(s->hkey);
|
|
|
|
}
|
|
|
|
|
|
|
|
s->hostkeyblob->len = 0;
|
|
|
|
ssh_key_public_blob(s->hkey, BinarySink_UPCAST(s->hostkeyblob));
|
|
|
|
s->hostkeydata = ptrlen_from_strbuf(s->hostkeyblob);
|
|
|
|
|
|
|
|
put_stringpl(s->exhash, s->hostkeydata);
|
|
|
|
|
|
|
|
if (s->kex_alg->main_type == KEXTYPE_DH) {
|
|
|
|
/*
|
|
|
|
* If we're doing Diffie-Hellman group exchange, start by
|
|
|
|
* waiting for the group request.
|
|
|
|
*/
|
|
|
|
if (dh_is_gex(s->kex_alg)) {
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
ppl_logevent("Doing Diffie-Hellman group exchange");
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
s->ppl.bpp->pls->kctx = SSH2_PKTCTX_DHGEX;
|
|
|
|
|
|
|
|
crMaybeWaitUntilV((pktin = ssh2_transport_pop(s)) != NULL);
|
|
|
|
if (pktin->type != SSH2_MSG_KEX_DH_GEX_REQUEST &&
|
|
|
|
pktin->type != SSH2_MSG_KEX_DH_GEX_REQUEST_OLD) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Received unexpected packet when "
|
|
|
|
"expecting Diffie-Hellman group exchange "
|
|
|
|
"request, type %d (%s)", pktin->type,
|
|
|
|
ssh2_pkt_type(s->ppl.bpp->pls->kctx,
|
|
|
|
s->ppl.bpp->pls->actx,
|
|
|
|
pktin->type));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pktin->type != SSH2_MSG_KEX_DH_GEX_REQUEST_OLD) {
|
2018-10-29 19:50:29 +00:00
|
|
|
s->dh_got_size_bounds = true;
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
s->dh_min_size = get_uint32(pktin);
|
|
|
|
s->pbits = get_uint32(pktin);
|
|
|
|
s->dh_max_size = get_uint32(pktin);
|
|
|
|
} else {
|
2018-10-29 19:50:29 +00:00
|
|
|
s->dh_got_size_bounds = false;
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
s->pbits = get_uint32(pktin);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a hopeless strategy for making a secure DH
|
|
|
|
* group! It's good enough for testing a client against,
|
|
|
|
* but not for serious use.
|
|
|
|
*/
|
|
|
|
s->p = primegen(s->pbits, 2, 2, NULL, 1, no_progress, NULL, 1);
|
|
|
|
s->g = bignum_from_long(2);
|
|
|
|
s->dh_ctx = dh_setup_gex(s->p, s->g);
|
|
|
|
s->kex_init_value = SSH2_MSG_KEX_DH_GEX_INIT;
|
|
|
|
s->kex_reply_value = SSH2_MSG_KEX_DH_GEX_REPLY;
|
|
|
|
|
|
|
|
pktout = ssh_bpp_new_pktout(s->ppl.bpp, SSH2_MSG_KEX_DH_GEX_GROUP);
|
|
|
|
put_mp_ssh2(pktout, s->p);
|
|
|
|
put_mp_ssh2(pktout, s->g);
|
|
|
|
pq_push(s->ppl.out_pq, pktout);
|
|
|
|
} else {
|
|
|
|
s->ppl.bpp->pls->kctx = SSH2_PKTCTX_DHGROUP;
|
|
|
|
s->dh_ctx = dh_setup_group(s->kex_alg);
|
|
|
|
s->kex_init_value = SSH2_MSG_KEXDH_INIT;
|
|
|
|
s->kex_reply_value = SSH2_MSG_KEXDH_REPLY;
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
ppl_logevent("Using Diffie-Hellman with standard group \"%s\"",
|
|
|
|
s->kex_alg->groupname);
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
}
|
|
|
|
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
ppl_logevent("Doing Diffie-Hellman key exchange with hash %s",
|
|
|
|
s->kex_alg->hash->text_name);
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate e for Diffie-Hellman.
|
|
|
|
*/
|
|
|
|
s->e = dh_create_e(s->dh_ctx, s->nbits * 2);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait to receive f.
|
|
|
|
*/
|
|
|
|
crMaybeWaitUntilV((pktin = ssh2_transport_pop(s)) != NULL);
|
|
|
|
if (pktin->type != s->kex_init_value) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Received unexpected packet when "
|
|
|
|
"expecting Diffie-Hellman initial packet, "
|
|
|
|
"type %d (%s)", pktin->type,
|
|
|
|
ssh2_pkt_type(s->ppl.bpp->pls->kctx,
|
|
|
|
s->ppl.bpp->pls->actx,
|
|
|
|
pktin->type));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
s->f = get_mp_ssh2(pktin);
|
|
|
|
if (get_err(pktin)) {
|
|
|
|
ssh_proto_error(s->ppl.ssh,
|
|
|
|
"Unable to parse Diffie-Hellman initial packet");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
const char *err = dh_validate_f(s->dh_ctx, s->f);
|
|
|
|
if (err) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Diffie-Hellman initial packet "
|
|
|
|
"failed validation: %s", err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
s->K = dh_find_K(s->dh_ctx, s->f);
|
|
|
|
|
|
|
|
if (dh_is_gex(s->kex_alg)) {
|
|
|
|
if (s->dh_got_size_bounds)
|
|
|
|
put_uint32(s->exhash, s->dh_min_size);
|
|
|
|
put_uint32(s->exhash, s->pbits);
|
|
|
|
if (s->dh_got_size_bounds)
|
|
|
|
put_uint32(s->exhash, s->dh_max_size);
|
|
|
|
put_mp_ssh2(s->exhash, s->p);
|
|
|
|
put_mp_ssh2(s->exhash, s->g);
|
|
|
|
}
|
|
|
|
put_mp_ssh2(s->exhash, s->f);
|
|
|
|
put_mp_ssh2(s->exhash, s->e);
|
|
|
|
|
|
|
|
pktout = ssh_bpp_new_pktout(s->ppl.bpp, s->kex_reply_value);
|
|
|
|
put_stringpl(pktout, s->hostkeydata);
|
|
|
|
put_mp_ssh2(pktout, s->e);
|
|
|
|
put_stringsb(pktout, finalise_and_sign_exhash(s));
|
|
|
|
pq_push(s->ppl.out_pq, pktout);
|
|
|
|
|
|
|
|
dh_cleanup(s->dh_ctx);
|
|
|
|
s->dh_ctx = NULL;
|
|
|
|
freebn(s->f); s->f = NULL;
|
|
|
|
if (dh_is_gex(s->kex_alg)) {
|
|
|
|
freebn(s->g); s->g = NULL;
|
|
|
|
freebn(s->p); s->p = NULL;
|
|
|
|
}
|
|
|
|
} else if (s->kex_alg->main_type == KEXTYPE_ECDH) {
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
ppl_logevent("Doing ECDH key exchange with curve %s and hash %s",
|
|
|
|
ssh_ecdhkex_curve_textname(s->kex_alg),
|
|
|
|
s->kex_alg->hash->text_name);
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
s->ppl.bpp->pls->kctx = SSH2_PKTCTX_ECDHKEX;
|
|
|
|
|
|
|
|
s->ecdh_key = ssh_ecdhkex_newkey(s->kex_alg);
|
|
|
|
if (!s->ecdh_key) {
|
|
|
|
ssh_sw_abort(s->ppl.ssh, "Unable to generate key for ECDH");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
crMaybeWaitUntilV((pktin = ssh2_transport_pop(s)) != NULL);
|
|
|
|
if (pktin->type != SSH2_MSG_KEX_ECDH_INIT) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Received unexpected packet when "
|
|
|
|
"expecting ECDH initial packet, type %d (%s)",
|
|
|
|
pktin->type,
|
|
|
|
ssh2_pkt_type(s->ppl.bpp->pls->kctx,
|
|
|
|
s->ppl.bpp->pls->actx,
|
|
|
|
pktin->type));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
ptrlen keydata = get_string(pktin);
|
|
|
|
put_stringpl(s->exhash, keydata);
|
|
|
|
|
|
|
|
s->K = ssh_ecdhkex_getkey(s->ecdh_key, keydata.ptr, keydata.len);
|
|
|
|
if (!get_err(pktin) && !s->K) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Received invalid elliptic curve "
|
|
|
|
"point in ECDH initial packet");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pktout = ssh_bpp_new_pktout(s->ppl.bpp, SSH2_MSG_KEX_ECDH_REPLY);
|
|
|
|
put_stringpl(pktout, s->hostkeydata);
|
|
|
|
{
|
|
|
|
strbuf *pubpoint = strbuf_new();
|
|
|
|
ssh_ecdhkex_getpublic(s->ecdh_key, BinarySink_UPCAST(pubpoint));
|
|
|
|
put_string(s->exhash, pubpoint->u, pubpoint->len);
|
|
|
|
put_stringsb(pktout, pubpoint);
|
|
|
|
}
|
|
|
|
put_stringsb(pktout, finalise_and_sign_exhash(s));
|
|
|
|
pq_push(s->ppl.out_pq, pktout);
|
|
|
|
|
|
|
|
ssh_ecdhkex_freekey(s->ecdh_key);
|
|
|
|
s->ecdh_key = NULL;
|
|
|
|
} else if (s->kex_alg->main_type == KEXTYPE_GSS) {
|
|
|
|
ssh_sw_abort(s->ppl.ssh, "GSS key exchange not supported in server");
|
|
|
|
} else {
|
|
|
|
assert(s->kex_alg->main_type == KEXTYPE_RSA);
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
ppl_logevent("Doing RSA key exchange with hash %s",
|
|
|
|
s->kex_alg->hash->text_name);
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
s->ppl.bpp->pls->kctx = SSH2_PKTCTX_RSAKEX;
|
|
|
|
|
|
|
|
{
|
|
|
|
const struct ssh_rsa_kex_extra *extra =
|
|
|
|
(const struct ssh_rsa_kex_extra *)s->kex_alg->extra;
|
|
|
|
|
|
|
|
s->rsa_kex_key = snew(struct RSAKey);
|
|
|
|
rsa_generate(s->rsa_kex_key, extra->minklen, no_progress, NULL);
|
|
|
|
s->rsa_kex_key->comment = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
pktout = ssh_bpp_new_pktout(s->ppl.bpp, SSH2_MSG_KEXRSA_PUBKEY);
|
|
|
|
put_stringpl(pktout, s->hostkeydata);
|
|
|
|
{
|
|
|
|
strbuf *pubblob = strbuf_new();
|
|
|
|
ssh_key_public_blob(&s->rsa_kex_key->sshk,
|
|
|
|
BinarySink_UPCAST(pubblob));
|
|
|
|
put_string(s->exhash, pubblob->u, pubblob->len);
|
|
|
|
put_stringsb(pktout, pubblob);
|
|
|
|
}
|
|
|
|
pq_push(s->ppl.out_pq, pktout);
|
|
|
|
|
|
|
|
crMaybeWaitUntilV((pktin = ssh2_transport_pop(s)) != NULL);
|
|
|
|
if (pktin->type != SSH2_MSG_KEXRSA_SECRET) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Received unexpected packet when "
|
|
|
|
"expecting RSA kex secret, type %d (%s)",
|
|
|
|
pktin->type,
|
|
|
|
ssh2_pkt_type(s->ppl.bpp->pls->kctx,
|
|
|
|
s->ppl.bpp->pls->actx,
|
|
|
|
pktin->type));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
ptrlen encrypted_secret = get_string(pktin);
|
|
|
|
put_stringpl(s->exhash, encrypted_secret);
|
|
|
|
s->K = ssh_rsakex_decrypt(
|
|
|
|
s->kex_alg->hash, encrypted_secret, s->rsa_kex_key);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!s->K) {
|
|
|
|
ssh_proto_error(s->ppl.ssh, "Unable to decrypt RSA kex secret");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ssh_rsakex_freekey(s->rsa_kex_key);
|
|
|
|
s->rsa_kex_key = NULL;
|
|
|
|
|
|
|
|
pktout = ssh_bpp_new_pktout(s->ppl.bpp, SSH2_MSG_KEXRSA_DONE);
|
|
|
|
put_stringsb(pktout, finalise_and_sign_exhash(s));
|
|
|
|
pq_push(s->ppl.out_pq, pktout);
|
|
|
|
}
|
|
|
|
|
|
|
|
crFinishV;
|
|
|
|
}
|