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
pre-0.83
putty-source/unix/uppity.c

974 lines
32 KiB
C
Raw Permalink Normal View History

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
/*
* SSH server for Unix: main program.
*
* ======================================================================
*
* This server is NOT SECURE!
*
* 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.
*
* It has no interaction with the OS's authentication system: the
* authentications it will accept are configurable by command-line
* option, and once you authenticate, it will run the connection
* protocol - including all subprocesses and shells - under the same
* Unix user id you started it under.
*
* It really is only suitable for testing the actual SSH protocol.
* Don't use it for anything more serious!
*
* ======================================================================
*/
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
#include <stdarg.h>
#include <signal.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <pwd.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include "putty.h"
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
#include "mpint.h"
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
#include "ssh.h"
Move the SSH implementation into its own subdirectory. This clears up another large pile of clutter at the top level, and in the process, allows me to rename source files to things that don't all have that annoying 'ssh' prefix at the top.
2021-04-22 16:58:40 +00:00
#include "ssh/server.h"
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
void modalfatalbox(const char *p, ...)
{
va_list ap;
fprintf(stderr, "FATAL ERROR: ");
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
fputc('\n', stderr);
exit(1);
}
void nonfatal(const char *p, ...)
{
va_list ap;
fprintf(stderr, "ERROR: ");
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
fputc('\n', stderr);
}
char *platform_default_s(const char *name)
{
return NULL;
}
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
bool platform_default_b(const char *name, bool def)
{
return def;
}
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
int platform_default_i(const char *name, int def)
{
return def;
}
FontSpec *platform_default_fontspec(const char *name)
{
Add platform-independent fontspec_new_default() function. Constructing a FontSpec in platform-independent code is awkward, because you can't call fontspec_new() outside the platform subdirs (since its prototype varies per platform). But sometimes you just need _some_ valid FontSpec, e.g. to put in a Conf that will be used in some place where you don't actually care about font settings, such as a purely CLI program. Both Unix and Windows _have_ an idiom for this, but they're different, because their FontSpec constructors have different prototypes. The existing CLI tools have always had per-platform main source files, so they just use the locally appropriate method of constructing a boring don't-care FontSpec. But if you want a _platform-independent_ main source file, such as you might find in a test program, then that's rather awkward. Better to have a platform-independent API for making a default FontSpec.
2023-02-18 13:43:50 +00:00
return fontspec_new_default();
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
}
Filename *platform_default_filename(const char *name)
{
return filename_from_str("");
}
char *x_get_default(const char *key)
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL; /* this is a stub */
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
}
void old_keyfile_warning(void) { }
void timer_change_notify(unsigned long next)
{
}
char *platform_get_x_display(void) { return NULL; }
psusan: fix assertion failure in SFTP server. Uppity's built-in SFTP server makes up its file handle identifiers using random_read(). But when that server is reused in psusan, which doesn't have the random number generator enabled, you get an assertion failure.
2020-11-04 21:50:47 +00:00
void make_unix_sftp_filehandle_key(void *data, size_t size)
{
random_read(data, size);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool verbose;
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
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
struct server_config;
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
struct AuthPolicyShared {
struct AuthPolicy_ssh1_pubkey *ssh1keys;
struct AuthPolicy_ssh2_pubkey *ssh2keys;
};
struct AuthPolicy {
struct AuthPolicyShared *shared;
int kbdint_state;
};
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
struct server_instance {
unsigned id;
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
AuthPolicy ap;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
LogPolicy logpolicy;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
struct server_config *cfg;
};
struct server_config {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
unsigned config_id;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
Conf *conf;
const SshServerConfig *ssc;
ssh_key **hostkeys;
int nhostkeys;
RSAKey *hostkey1;
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
unsigned auth_methods;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
struct AuthPolicyShared *ap_shared;
Socket *listening_socket;
Plug listening_plug;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
};
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
static unsigned next_id = 0;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
static void log_to_stderr(unsigned id, const char *msg)
{
if (id != (unsigned)-1)
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
fprintf(stderr, "conn#%u: ", id);
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
fputs(msg, stderr);
fputc('\n', stderr);
fflush(stderr);
}
static void server_eventlog(LogPolicy *lp, const char *event)
{
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
struct server_instance *inst = container_of(
lp, struct server_instance, logpolicy);
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
if (verbose)
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
log_to_stderr(inst->id, event);
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
}
static void server_logging_error(LogPolicy *lp, const char *event)
{
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
struct server_instance *inst = container_of(
lp, struct server_instance, logpolicy);
log_to_stderr(inst->id, event); /* unconditional */
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
}
static int server_askappend(
LogPolicy *lp, Filename *filename,
void (*callback)(void *ctx, int result), void *ctx)
{
return 2; /* always overwrite (FIXME: could make this a cmdline option) */
}
static const LogPolicyVtable server_logpolicy_vt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.eventlog = server_eventlog,
.askappend = server_askappend,
.logging_error = server_logging_error,
.verbose = null_lp_verbose_no,
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
};
struct AuthPolicy_ssh1_pubkey {
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
RSAKey key;
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
struct AuthPolicy_ssh1_pubkey *next;
};
struct AuthPolicy_ssh2_pubkey {
ptrlen public_blob;
struct AuthPolicy_ssh2_pubkey *next;
};
unsigned auth_methods(AuthPolicy *ap)
{
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
struct server_instance *inst = container_of(
ap, struct server_instance, ap);
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
return inst->cfg->auth_methods;
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
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool auth_none(AuthPolicy *ap, ptrlen username)
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
{
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
struct server_instance *inst = container_of(
ap, struct server_instance, ap);
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
if (inst->cfg->auth_methods & AUTHMETHOD_NONE)
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
return true;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
}
Uppity: support SSH-2 password change request. This is the first time I've _ever_ been able to test that feature of the client userauth code personally, and pleasingly, it seems to work fine.
2018-10-29 07:23:32 +00:00
int auth_password(AuthPolicy *ap, ptrlen username, ptrlen password,
ptrlen *new_password_opt)
{
const char *PHONY_GOOD_PASSWORD = "weasel";
const char *PHONY_BAD_PASSWORD = "ferret";
if (!new_password_opt) {
/* Accept login with our preconfigured good password */
if (ptrlen_eq_string(password, PHONY_GOOD_PASSWORD))
return 1;
/* Don't outright reject the bad password, but insist on a change */
if (ptrlen_eq_string(password, PHONY_BAD_PASSWORD))
return 2;
/* Reject anything else */
return 0;
} else {
/* In a password-change request, expect the bad password as input */
if (!ptrlen_eq_string(password, PHONY_BAD_PASSWORD))
return 0;
/* Accept a request to change it to the good password */
if (ptrlen_eq_string(*new_password_opt, PHONY_GOOD_PASSWORD))
return 1;
/* Outright reject a request to change it to the same password
* as it already 'was' */
if (ptrlen_eq_string(*new_password_opt, PHONY_BAD_PASSWORD))
return 0;
/* Anything else, pretend the new pw wasn't good enough, and
* re-request a change */
return 2;
}
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
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool auth_publickey(AuthPolicy *ap, ptrlen username, ptrlen public_blob)
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
{
struct AuthPolicy_ssh2_pubkey *iter;
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
for (iter = ap->shared->ssh2keys; iter; iter = iter->next) {
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
if (ptrlen_eq_ptrlen(public_blob, iter->public_blob))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
}
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
RSAKey *auth_publickey_ssh1(
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
AuthPolicy *ap, ptrlen username, mp_int *rsa_modulus)
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
{
struct AuthPolicy_ssh1_pubkey *iter;
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
for (iter = ap->shared->ssh1keys; iter; iter = iter->next) {
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
if (mp_cmp_eq(rsa_modulus, iter->key.modulus))
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
return &iter->key;
}
return NULL;
}
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
AuthKbdInt *auth_kbdint_prompts(AuthPolicy *ap, ptrlen username)
{
Fix miscellaneous minor memory leaks. All found by Coverity.
2019-05-04 15:19:13 +00:00
AuthKbdInt *aki;
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
switch (ap->kbdint_state) {
case 0:
Fix miscellaneous minor memory leaks. All found by Coverity.
2019-05-04 15:19:13 +00:00
aki = snew(AuthKbdInt);
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
aki->title = dupstr("Initial double prompt");
aki->instruction =
dupstr("First prompt should echo, second should not");
aki->nprompts = 2;
aki->prompts = snewn(aki->nprompts, AuthKbdIntPrompt);
aki->prompts[0].prompt = dupstr("Echoey prompt: ");
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
aki->prompts[0].echo = true;
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
aki->prompts[1].prompt = dupstr("Silent prompt: ");
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
aki->prompts[1].echo = false;
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
return aki;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
case 1: {
struct server_instance *inst = container_of(
ap, struct server_instance, ap);
Fix miscellaneous minor memory leaks. All found by Coverity.
2019-05-04 15:19:13 +00:00
aki = snew(AuthKbdInt);
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
if (inst->cfg->ssc->stunt_allow_trivial_ki_auth) {
aki->title = dupstr("");
aki->instruction = dupstr("");
} else {
aki->title = dupstr("Zero-prompt step");
aki->instruction = dupstr("Shouldn't see any prompts this time");
}
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
aki->nprompts = 0;
aki->prompts = NULL;
return aki;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
}
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
default:
ap->kbdint_state = 0;
return NULL;
}
}
int auth_kbdint_responses(AuthPolicy *ap, const ptrlen *responses)
{
switch (ap->kbdint_state) {
case 0:
if (ptrlen_eq_string(responses[0], "stoat") &&
ptrlen_eq_string(responses[1], "weasel")) {
ap->kbdint_state++;
return 0; /* those are the expected responses */
} else {
ap->kbdint_state = 0;
return -1;
}
break;
case 1:
return +1; /* succeed after the zero-prompt step */
default:
ap->kbdint_state = 0;
return -1;
}
}
char *auth_ssh1int_challenge(AuthPolicy *ap, unsigned method, ptrlen username)
{
/* FIXME: test returning a challenge string without \n, and ensure
* it gets printed as a prompt in its own right, without PuTTY
* making up a "Response: " prompt to follow it */
return dupprintf("This is a dummy %s challenge!\n",
(method == AUTHMETHOD_TIS ? "TIS" : "CryptoCard"));
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool auth_ssh1int_response(AuthPolicy *ap, ptrlen response)
Uppity: add challenge-response auth methods. This adds the server side of the SSH-2 keyboard-interactive protocol, and the pair of very similar SSH-1 methods AUTH_TIS and AUTH_CCARD (which basically differ only in message numbers, and each involve a single challenge from the server and a response from the user).
2018-10-22 19:32:58 +00:00
{
return ptrlen_eq_string(response, "otter");
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool auth_successful(AuthPolicy *ap, ptrlen username, unsigned method)
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
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
}
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
static void safety_warning(FILE *fp)
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
{
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fputs(" =================================================\n"
" THIS SSH SERVER IS NOT WRITTEN TO BE SECURE!\n"
" DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT!\n"
" =================================================\n", fp);
}
static void show_help(FILE *fp)
{
safety_warning(fp);
fputs("\n"
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
"usage: uppity [options] [--and <options>...]\n"
Uppity: ability to listen on a Unix-domain socket. This will fit nicely with Unix PuTTY's ability to connect to one.
2020-02-22 15:50:44 +00:00
"options: --listen [PORT|PATH] listen to a port on localhost, or Unix socket\n"
Uppity: bring --help up to date. I've been busily adding new options, and forgot to document them all, which will annoy me the next time I haven't used it for a week or two if I don't write them all up now.
2019-03-31 20:17:25 +00:00
" --listen-once (with --listen) stop after one "
"connection\n"
" --hostkey KEY SSH host key (need at least one)\n"
" --rsakexkey KEY key for SSH-2 RSA key exchange "
"(in SSH-1 format)\n"
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
" --userkey KEY public key"
Formatting: miscellaneous. This patch fixes a few other whitespace and formatting issues which were pointed out by the bulk-reindent or which I spotted in passing, some involving manual editing to break lines more nicely. I think the weirdest hunk in here is the one in windows/window.c TranslateKey() where _half_ of an assignment statement inside an 'if' was on the same line as the trailing paren of the if condition. No idea at all how that one managed to happen!
2022-08-03 19:48:46 +00:00
" acceptable for user authentication\n"
Uppity: configurable cwd for session. All my instincts expect the shell subprocesses to start off in ~, so it's confusing if they start off in some random PuTTY checkout directory. So now we default to $HOME, and if I really do want the latter, I can use the new config option to reselect '.'.
2019-03-31 21:12:42 +00:00
" --sessiondir DIR cwd for session subprocess (default $HOME)\n"
Uppity: bring --help up to date. I've been busily adding new options, and forgot to document them all, which will annoy me the next time I haven't used it for a week or two if I don't write them all up now.
2019-03-31 20:17:25 +00:00
" --bannertext TEXT send TEXT as SSH-2 auth banner\n"
" --bannerfile FILE send contents of FILE as SSH-2 auth "
"banner\n"
" --kexinit-kex STR override list of SSH-2 KEX methods\n"
" --kexinit-hostkey STR override list of SSH-2 host key "
"types\n"
" --kexinit-cscipher STR override list of SSH-2 "
"client->server ciphers\n"
" --kexinit-sccipher STR override list of SSH-2 "
"server->client ciphers\n"
" --kexinit-csmac STR override list of SSH-2 "
"client->server MACs\n"
" --kexinit-scmac STR override list of SSH-2 "
"server->client MACs\n"
" --kexinit-cscomp STR override list of SSH-2 "
"c->s compression types\n"
" --kexinit-sccomp STR override list of SSH-2 "
"s->c compression types\n"
Uppity: configurable list of SSH-1 ciphers to allow.
2019-04-01 19:10:09 +00:00
" --ssh1-ciphers STR override list of SSH-1 ciphers\n"
Uppity: option to disallow SSH-1 compression. With this and the ciphers, I think we've now got the full range of SSH-1 config options (such as they are) that correspond to varying the KEXINIT strings in SSH-2.
2019-04-01 19:15:49 +00:00
" --ssh1-no-compression forbid compression in SSH-1\n"
Add --allow/deny-auth to Uppity usage message. These were added in commit a73aaf9457.
2022-01-11 23:54:33 +00:00
" --deny-auth METHOD forbid a userauth method\n"
" --allow-auth METHOD allow a userauth method\n"
" (METHOD = none/password/publickey/kbdint/tis/"
"cryptocard)\n"
Uppity: bring --help up to date. I've been busily adding new options, and forgot to document them all, which will annoy me the next time I haven't used it for a week or two if I don't write them all up now.
2019-03-31 20:17:25 +00:00
" --exitsignum send buggy numeric \"exit-signal\" "
"message\n"
" --verbose print event log messages to standard "
Uppity: fix paste error in --help output. --verbose sends log messages to standard _error_, not standard output.
2020-12-13 12:31:16 +00:00
"error\n"
Uppity: bring --help up to date. I've been busily adding new options, and forgot to document them all, which will annoy me the next time I haven't used it for a week or two if I don't write them all up now.
2019-03-31 20:17:25 +00:00
" --sshlog FILE write SSH packet log to FILE\n"
" --sshrawlog FILE write SSH packets + raw data log"
" to FILE\n"
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
" --and run a separate server on another port\n"
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
"also: uppity --help show this text\n"
" uppity --version show version information\n"
"\n", fp);
safety_warning(fp);
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
}
static void show_version_and_exit(void)
{
char *buildinfo_text = buildinfo("\n");
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
printf("%s: %s\n%s\n", appname, ver, buildinfo_text);
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
sfree(buildinfo_text);
exit(0);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool buildinfo_gtk_relevant = 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
Uppity: add a --listen-once option. This modifies 'uppity --listen' so that it closes the listening socket after the first connection comes in.
2019-03-31 08:27:47 +00:00
static bool listening = false, listen_once = false;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool finished = false;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
void server_instance_terminated(LogPolicy *lp)
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
{
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
struct server_instance *inst = container_of(
lp, struct server_instance, logpolicy);
Uppity: add a --listen-once option. This modifies 'uppity --listen' so that it closes the listening socket after the first connection comes in.
2019-03-31 08:27:47 +00:00
if (listening && !listen_once) {
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
log_to_stderr(inst->id, "connection terminated");
} else {
finished = true;
}
sfree(inst);
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
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool longoptarg(const char *arg, const char *expected,
const char **val, int *argcp, char ***argvp)
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
{
int len = strlen(expected);
if (memcmp(arg, expected, len))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
if (arg[len] == '=') {
*val = arg + len + 1;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
} else if (arg[len] == '\0') {
if (--*argcp > 0) {
*val = *++*argvp;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
} else {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: option %s expects an argument\n",
appname, expected);
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
exit(1);
}
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return 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
}
uxserver.c: 'longoptnoarg' matching function. Replaces a couple of existing strcmp, and does just slightly better because as well as matching "--verbose" (say) it also matches "--verbose=foo" and gives a comprehensible error message about it.
2019-03-30 07:27:57 +00:00
static bool longoptnoarg(const char *arg, const char *expected)
{
int len = strlen(expected);
if (memcmp(arg, expected, len))
return false;
if (arg[len] == '=') {
fprintf(stderr, "%s: option %s expects no argument\n",
appname, expected);
exit(1);
} else if (arg[len] == '\0') {
return true;
}
return false;
}
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
static Plug *server_conn_plug(
struct server_config *cfg, struct server_instance **inst_out)
{
struct server_instance *inst = snew(struct server_instance);
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
memset(inst, 0, sizeof(*inst));
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
inst->id = next_id++;
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
inst->ap.shared = cfg->ap_shared;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
if (cfg->ssc->stunt_allow_trivial_ki_auth)
inst->ap.kbdint_state = 1;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
inst->logpolicy.vt = &server_logpolicy_vt;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
inst->cfg = cfg;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
if (inst_out)
*inst_out = inst;
return ssh_server_plug(
cfg->conf, cfg->ssc, cfg->hostkeys, cfg->nhostkeys, cfg->hostkey1,
Uppity: make a separate AuthPolicy per connection. Despite the name, AuthPolicy in uxserver.c was also holding the state of the current connection, including in particular how far through the multi-step test keyboard-interactive interaction we are. But now that Uppity can handle multiple connections in the same run, we need to reset that state between connections. So the tree234s of acceptable user keys now live in an AuthPolicyShared structure, and AuthPolicy proper is a field of server_instance.
2019-03-31 21:23:03 +00:00
&inst->ap, &inst->logpolicy, &unix_live_sftpserver_vt);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +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
static void server_log(Plug *plug, Socket *s, PlugLogType type, SockAddr *addr,
int port, const char *error_msg, int error_code)
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
{
log_to_stderr((unsigned)-1, error_msg);
}
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
static void server_closing(Plug *plug, PlugCloseType type,
const char *error_msg)
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
{
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
if (type != PLUGCLOSE_NORMAL)
log_to_stderr((unsigned)-1, error_msg);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
}
static int server_accepting(Plug *p, accept_fn_t constructor, accept_ctx_t ctx)
{
struct server_config *cfg = container_of(
p, struct server_config, listening_plug);
Socket *s;
const char *err;
struct server_instance *inst;
Uppity: add a --listen-once option. This modifies 'uppity --listen' so that it closes the listening socket after the first connection comes in.
2019-03-31 08:27:47 +00:00
if (listen_once) {
if (!cfg->listening_socket) /* in case of rapid double-accept */
return 1;
sk_close(cfg->listening_socket);
cfg->listening_socket = NULL;
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
unsigned old_next_id = next_id;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
Plug *plug = server_conn_plug(cfg, &inst);
s = constructor(ctx, plug);
if ((err = sk_socket_error(s)) != NULL)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
Rename SocketPeerInfo to SocketEndpointInfo. I'm preparing to be able to ask about the other end of the connection too, so the first step is to give this data structure a neutral name that can refer to either. No functional change yet.
2024-06-26 05:35:40 +00:00
SocketEndpointInfo *pi = sk_peer_info(s);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
Uppity: ability to listen on a Unix-domain socket. This will fit nicely with Unix PuTTY's ability to connect to one.
2020-02-22 15:50:44 +00:00
if (pi->addressfamily != ADDRTYPE_LOCAL && !sk_peer_trusted(s)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
fprintf(stderr, "rejected connection to serv#%u "
"from %s (untrustworthy peer)\n",
cfg->config_id, pi->log_text);
Rename SocketPeerInfo to SocketEndpointInfo. I'm preparing to be able to ask about the other end of the connection too, so the first step is to give this data structure a neutral name that can refer to either. No functional change yet.
2024-06-26 05:35:40 +00:00
sk_free_endpoint_info(pi);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
sk_close(s);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
next_id = old_next_id;
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
return 1;
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
char *msg = dupprintf("new connection to serv#%u from %s",
cfg->config_id, pi->log_text);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
log_to_stderr(inst->id, msg);
sfree(msg);
Rename SocketPeerInfo to SocketEndpointInfo. I'm preparing to be able to ask about the other end of the connection too, so the first step is to give this data structure a neutral name that can refer to either. No functional change yet.
2024-06-26 05:35:40 +00:00
sk_free_endpoint_info(pi);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
sk_set_frozen(s, false);
ssh_server_start(plug, s);
return 0;
}
static const PlugVtable server_plugvt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.log = server_log,
.closing = server_closing,
.accepting = server_accepting,
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
};
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
static unsigned auth_method_from_name(const char *name)
{
if (!strcmp(name, "none"))
return AUTHMETHOD_NONE;
if (!strcmp(name, "tis"))
return AUTHMETHOD_TIS;
if (!strcmp(name, "cryptocard") || !strcmp(name, "ccard"))
return AUTHMETHOD_CRYPTOCARD;
if (!strcmp(name, "keyboard-interactive") || !strcmp(name, "k-i") ||
!strcmp(name, "kbdint") || !strcmp(name, "ki"))
return AUTHMETHOD_KBDINT;
if (!strcmp(name, "publickey") || !strcmp(name, "pubkey") ||
!strcmp(name, "pk"))
return AUTHMETHOD_PUBLICKEY;
if (!strcmp(name, "password") || !strcmp(name, "pw"))
return AUTHMETHOD_PASSWORD;
return 0;
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
struct cmdline_instance {
int listen_port;
const char *listen_socket;
ssh_key **hostkeys;
size_t nhostkeys, hostkeysize;
RSAKey *hostkey1;
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
unsigned auth_methods;
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
struct AuthPolicyShared aps;
SshServerConfig ssc;
Conf *conf;
};
static void init_cmdline_instance(struct cmdline_instance *ci)
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
{
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->listen_port = -1;
ci->listen_socket = NULL;
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->hostkeys = NULL;
ci->nhostkeys = ci->hostkeysize = 0;
ci->hostkey1 = NULL;
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->conf = make_ssh_server_conf();
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->aps.ssh1keys = NULL;
ci->aps.ssh2keys = NULL;
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
memset(&ci->ssc, 0, sizeof(ci->ssc));
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
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.application_name = "Uppity";
ci->ssc.session_starting_dir = getenv("HOME");
ci->ssc.ssh1_cipher_mask = SSH1_SUPPORTED_CIPHER_MASK;
ci->ssc.ssh1_allow_compression = true;
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
ci->auth_methods = (AUTHMETHOD_PUBLICKEY | AUTHMETHOD_PASSWORD |
AUTHMETHOD_KBDINT | AUTHMETHOD_TIS |
AUTHMETHOD_CRYPTOCARD);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
}
Start of an SSH-server-specific config structure. This is much simpler than Conf, because I don't expect to have to copy it around, load or save it to disk (or the Windows registry), or serialise it between processes. So it can be a straightforward struct. As yet there's nothing actually _in_ it. I've just created the structure and arranged to pass it through to all the SSH layers. But now it's here, it will be a place I can add configuration items as I find I need them.
2019-03-28 18:29:13 +00:00
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
static void cmdline_instance_start(struct cmdline_instance *ci)
{
static unsigned next_server_config_id = 0;
struct server_config *scfg = snew(struct server_config);
scfg->config_id = next_server_config_id++;
scfg->conf = ci->conf;
scfg->ssc = &ci->ssc;
scfg->hostkeys = ci->hostkeys;
scfg->nhostkeys = ci->nhostkeys;
scfg->hostkey1 = ci->hostkey1;
scfg->ap_shared = &ci->aps;
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
scfg->auth_methods = ci->auth_methods;
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
if (ci->listen_port >= 0 || ci->listen_socket) {
listening = true;
scfg->listening_plug.vt = &server_plugvt;
char *msg;
if (ci->listen_port >= 0) {
scfg->listening_socket = sk_newlistener(
NULL, ci->listen_port, &scfg->listening_plug, true,
ADDRTYPE_UNSPEC);
msg = dupprintf("serv#%u: listening on port %d",
scfg->config_id, ci->listen_port);
} else {
SockAddr *addr = unix_sock_addr(ci->listen_socket);
scfg->listening_socket = new_unix_listener(
addr, &scfg->listening_plug);
msg = dupprintf("serv#%u: listening on Unix socket %s",
scfg->config_id, ci->listen_socket);
}
log_to_stderr(-1, msg);
sfree(msg);
} else {
struct server_instance *inst;
Plug *plug = server_conn_plug(scfg, &inst);
ssh_server_start(plug, make_fd_socket(0, 1, -1, NULL, 0, plug));
log_to_stderr(inst->id, "speaking SSH on stdio");
}
}
int main(int argc, char **argv)
{
size_t ninstances = 0, instancessize = 8;
struct cmdline_instance *instances = snewn(
instancessize, struct cmdline_instance);
struct cmdline_instance *ci = &instances[ninstances++];
init_cmdline_instance(ci);
Uppity: configurable cwd for session. All my instincts expect the shell subprocesses to start off in ~, so it's confusing if they start off in some random PuTTY checkout directory. So now we default to $HOME, and if I really do want the latter, I can use the new config option to reselect '.'.
2019-03-31 21:12:42 +00:00
Arm: turn on PSTATE.DIT if available and needed. DIT, for 'Data-Independent Timing', is a bit you can set in the processor state on sufficiently new Arm CPUs, which promises that a long list of instructions will deliberately avoid varying their timing based on the input register values. Just what you want for keeping your constant-time crypto primitives constant-time. As far as I'm aware, no CPU has _yet_ implemented any data-dependent optimisations, so DIT is a safety precaution against them doing so in future. It would be embarrassing to be caught without it if a future CPU does do that, so we now turn on DIT in the PuTTY process state. I've put a call to the new enable_dit() function at the start of every main() and WinMain() belonging to a program that might do cryptography (even testcrypt, in case someone uses it for something!), and in case I missed one there, also added a second call at the first moment that any cryptography-using part of the code looks as if it might become active: when an instance of the SSH protocol object is configured, when the system PRNG is initialised, and when selecting any cryptographic authentication protocol in an HTTP or SOCKS proxy connection. With any luck those precautions between them should ensure it's on whenever we need it. Arm's own recommendation is that you should carefully choose the granularity at which you enable and disable DIT: there's a potential time cost to turning it on and off (I'm not sure what, but plausibly something of the order of a pipeline flush), so it's a performance hit to do it _inside_ each individual crypto function, but if CPUs start supporting significant data-dependent optimisation in future, then it will also become a noticeable performance hit to just leave it on across the whole process. So you'd like to do it somewhere in the middle: for example, you might turn on DIT once around the whole process of verifying and decrypting an SSH packet, instead of once for decryption and once for MAC. With all respect to that recommendation as a strategy for maximum performance, I'm not following it here. I turn on DIT at the start of the PuTTY process, and then leave it on. Rationale: 1. PuTTY is not otherwise a performance-critical application: it's not likely to max out your CPU for any purpose _other_ than cryptography. The most CPU-intensive non-cryptographic thing I can imagine a PuTTY process doing is the complicated computation of font rendering in the terminal, and that will normally be cached (you don't recompute each glyph from its outline and hints for every time you display it). 2. I think a bigger risk lies in accidental side channels from having DIT turned off when it should have been on. I can imagine lots of causes for that. Missing a crypto operation in some unswept corner of the code; confusing control flow (like my coroutine macros) jumping with DIT clear into the middle of a region of code that expected DIT to have been set at the beginning; having a reference counter of DIT requests and getting it out of sync. In a more sophisticated programming language, it might be possible to avoid the risk in #2 by cleverness with the type system. For example, in Rust, you could have a zero-sized type that acts as a proof token for DIT being enabled (it would be constructed by a function that also sets DIT, have a Drop implementation that clears DIT, and be !Send so you couldn't use it in a thread other than the one where DIT was set), and then you could require all the actual crypto functions to take a DitToken as an extra parameter, at zero runtime cost. Then "oops I forgot to set DIT around this piece of crypto" would become a compile error. Even so, you'd have to take some care with coroutine-structured code (what happens if a Rust async function yields while holding a DIT token?) and with nesting (if you have two DIT tokens, you don't want dropping the inner one to clear DIT while the outer one is still there to wrongly convince callees that it's set). Maybe in Rust you could get this all to work reliably. But not in C! DIT is an optional feature of the Arm architecture, so we must first test to see if it's supported. This is done the same way as we already do for the various Arm crypto accelerators: on ELF-based systems, check the appropriate bit in the 'hwcap' words in the ELF aux vector; on Mac, look for an appropriate sysctl flag. On Windows I don't know of a way to query the DIT feature, _or_ of a way to write the necessary enabling instruction in an MSVC-compatible way. I've _heard_ that it might not be necessary, because Windows might just turn on DIT unconditionally and leave it on, in an even more extreme version of my own strategy. I don't have a source for that - I heard it by word of mouth - but I _hope_ it's true, because that would suit me very well! Certainly I can't write code to enable DIT without knowing (a) how to do it, (b) how to know if it's safe. Nonetheless, I've put the enable_dit() call in all the right places in the Windows main programs as well as the Unix and cross-platform code, so that if I later find out that I _can_ put in an explicit enable of DIT in some way, I'll only have to arrange to set HAVE_ARM_DIT and compile the enable_dit() function appropriately.
2024-12-19 08:47:08 +00:00
enable_dit();
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
if (argc <= 1) {
/*
* We're going to terminate with an error message below,
* because there are no host keys. But we'll display the help
* as additional standard-error output, if nothing else so
* that people see the giant safety warning.
*/
show_help(stderr);
fputc('\n', stderr);
}
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
while (--argc > 0) {
const char *arg = *++argv;
const char *val;
if (!strcmp(arg, "--help")) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
show_help(stdout);
exit(0);
uxserver.c: 'longoptnoarg' matching function. Replaces a couple of existing strcmp, and does just slightly better because as well as matching "--verbose" (say) it also matches "--verbose=foo" and gives a comprehensible error message about it.
2019-03-30 07:27:57 +00:00
} else if (longoptnoarg(arg, "--version")) {
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
show_version_and_exit();
uxserver.c: 'longoptnoarg' matching function. Replaces a couple of existing strcmp, and does just slightly better because as well as matching "--verbose" (say) it also matches "--verbose=foo" and gives a comprehensible error message about it.
2019-03-30 07:27:57 +00:00
} else if (longoptnoarg(arg, "--verbose") || !strcmp(arg, "-v")) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
verbose = true;
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
} else if (longoptnoarg(arg, "--and")) {
sgrowarray(instances, instancessize, ninstances);
ci = &instances[ninstances++];
init_cmdline_instance(ci);
Uppity: add a --listen mode, protected by /proc/net/tcp. Uppity is not secure enough to listen on a TCP port as if it was a normal SSH server. Until now, I've been using it by means of a local proxy command, i.e. PuTTY invokes Uppity in the same way it might invoke 'plink -nc'. This rigorously prevents any hostile user from connecting to my utterly insecure test server, but it's a thundering inconvenience as soon as you want to attach a debugger to the Uppity process itself - you have to stick a gdbserver somewhere in the middle of your already complicated shell pipeline, and then find a way to connect back to it from a gdb in a terminal window. So I've added an option to make Uppity listen on a TCP port in the normal way - but it's protected using that /proc/net/tcp trick I just added in the previous commit.
2019-03-31 08:27:10 +00:00
} else if (longoptarg(arg, "--listen", &val, &argc, &argv)) {
Uppity: ability to listen on a Unix-domain socket. This will fit nicely with Unix PuTTY's ability to connect to one.
2020-02-22 15:50:44 +00:00
if (val[0] == '/') {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->listen_port = -1;
ci->listen_socket = val;
Uppity: ability to listen on a Unix-domain socket. This will fit nicely with Unix PuTTY's ability to connect to one.
2020-02-22 15:50:44 +00:00
} else {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->listen_port = atoi(val);
ci->listen_socket = NULL;
Uppity: ability to listen on a Unix-domain socket. This will fit nicely with Unix PuTTY's ability to connect to one.
2020-02-22 15:50:44 +00:00
}
Uppity: add a --listen-once option. This modifies 'uppity --listen' so that it closes the listening socket after the first connection comes in.
2019-03-31 08:27:47 +00:00
} else if (!strcmp(arg, "--listen-once")) {
listen_once = 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
} else if (longoptarg(arg, "--hostkey", &val, &argc, &argv)) {
Filename *keyfile;
int keytype;
const char *error;
keyfile = filename_from_str(val);
keytype = key_type(keyfile);
if (keytype == SSH_KEYTYPE_SSH2) {
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
ssh2_userkey *uk;
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
ssh_key *key;
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
uk = ppk_load_f(keyfile, NULL, &error);
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
filename_free(keyfile);
if (!uk || !uk->key) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: unable to load host key '%s': "
"%s\n", appname, val, error);
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
exit(1);
}
Give a sensible error when using a too-short RSA key. The ssh_signkey vtable has grown a new method ssh_key_invalid(), which checks whether the key is going to be usable for constructing a signature at all. Currently the only way this can fail is if it's an RSA key so short that there isn't room to put all the PKCS#1 formatting in the signature preimage integer, but the return value is an arbitrary error message just in case more reasons are needed later. This is tested separately rather than at key-creation time because of the signature flags system: an RSA key of intermediate length could be valid for SHA-1 signing but not for SHA-512. So really this method should be called at the point where you've decided what sig flags you want to use, and you're checking if _those flags_ are OK. On the verification side, there's no need for a separate check. If someone presents us with an RSA key so short that it's impossible to encode a valid signature using it, then we simply regard all signatures as invalid.
2019-02-10 08:44:59 +00:00
char *invalid = ssh_key_invalid(uk->key, 0);
if (invalid) {
fprintf(stderr, "%s: host key '%s' is unusable: "
"%s\n", appname, val, invalid);
exit(1);
}
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
key = uk->key;
sfree(uk->comment);
sfree(uk);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
for (int i = 0; i < ci->nhostkeys; i++)
if (ssh_key_alg(ci->hostkeys[i]) == ssh_key_alg(key)) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: host key '%s' duplicates key "
"type %s\n", appname, val,
ssh_key_alg(key)->ssh_id);
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
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
sgrowarray(ci->hostkeys, ci->hostkeysize, ci->nhostkeys);
ci->hostkeys[ci->nhostkeys++] = key;
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
} else if (keytype == SSH_KEYTYPE_SSH1) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
if (ci->hostkey1) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: host key '%s' is a redundant "
"SSH-1 host key\n", appname, val);
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
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->hostkey1 = snew(RSAKey);
if (!rsa1_load_f(keyfile, ci->hostkey1, NULL, &error)) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: unable to load host key '%s': "
"%s\n", appname, val, error);
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
exit(1);
}
} else {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: '%s' is not loadable as a "
"private key (%s)", appname, val,
key_type_to_str(keytype));
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
exit(1);
}
Uppity: option to use a pregenerated key for RSA kex. As and when I make this SSH server into a test suite, I'm not going to want to wait for a gratuitous RSA key generation in every test run. So now you can provide one in advance. It has to be in SSH-1 format, because that's the format for which I happen to already have internal API routines that return an RSAKey instead of an opaque ssh_key. But since you also have to store it without a passphrase, that doesn't really matter anyway.
2019-03-31 20:08:55 +00:00
} else if (longoptarg(arg, "--rsakexkey", &val, &argc, &argv)) {
Filename *keyfile;
int keytype;
const char *error;
keyfile = filename_from_str(val);
keytype = key_type(keyfile);
if (keytype != SSH_KEYTYPE_SSH1) {
fprintf(stderr, "%s: '%s' is not loadable as an SSH-1 format "
"private key (%s)", appname, val,
key_type_to_str(keytype));
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
if (ci->ssc.rsa_kex_key) {
freersakey(ci->ssc.rsa_kex_key);
Uppity: option to use a pregenerated key for RSA kex. As and when I make this SSH server into a test suite, I'm not going to want to wait for a gratuitous RSA key generation in every test run. So now you can provide one in advance. It has to be in SSH-1 format, because that's the format for which I happen to already have internal API routines that return an RSAKey instead of an opaque ssh_key. But since you also have to store it without a passphrase, that doesn't really matter anyway.
2019-03-31 20:08:55 +00:00
} else {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.rsa_kex_key = snew(RSAKey);
Uppity: option to use a pregenerated key for RSA kex. As and when I make this SSH server into a test suite, I'm not going to want to wait for a gratuitous RSA key generation in every test run. So now you can provide one in advance. It has to be in SSH-1 format, because that's the format for which I happen to already have internal API routines that return an RSAKey instead of an opaque ssh_key. But since you also have to store it without a passphrase, that doesn't really matter anyway.
2019-03-31 20:08:55 +00:00
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
if (!rsa1_load_f(keyfile, ci->ssc.rsa_kex_key, NULL, &error)) {
Uppity: option to use a pregenerated key for RSA kex. As and when I make this SSH server into a test suite, I'm not going to want to wait for a gratuitous RSA key generation in every test run. So now you can provide one in advance. It has to be in SSH-1 format, because that's the format for which I happen to already have internal API routines that return an RSAKey instead of an opaque ssh_key. But since you also have to store it without a passphrase, that doesn't really matter anyway.
2019-03-31 20:08:55 +00:00
fprintf(stderr, "%s: unable to load RSA kex key '%s': "
"%s\n", appname, val, error);
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.rsa_kex_key->sshk.vt = &ssh_rsa;
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
} else if (longoptarg(arg, "--userkey", &val, &argc, &argv)) {
Filename *keyfile;
int keytype;
const char *error;
keyfile = filename_from_str(val);
keytype = key_type(keyfile);
if (keytype == SSH_KEYTYPE_SSH2_PUBLIC_RFC4716 ||
keytype == SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH) {
strbuf *sb = strbuf_new();
struct AuthPolicy_ssh2_pubkey *node;
void *blob;
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
if (!ppk_loadpub_f(keyfile, NULL, BinarySink_UPCAST(sb),
NULL, &error)) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: unable to load user key '%s': "
"%s\n", appname, val, error);
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
exit(1);
}
node = snew_plus(struct AuthPolicy_ssh2_pubkey, sb->len);
blob = snew_plus_get_aux(node);
memcpy(blob, sb->u, sb->len);
node->public_blob = make_ptrlen(blob, sb->len);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
node->next = ci->aps.ssh2keys;
ci->aps.ssh2keys = node;
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
strbuf_free(sb);
} else if (keytype == SSH_KEYTYPE_SSH1_PUBLIC) {
strbuf *sb = strbuf_new();
BinarySource src[1];
struct AuthPolicy_ssh1_pubkey *node;
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
if (!rsa1_loadpub_f(keyfile, BinarySink_UPCAST(sb),
NULL, &error)) {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: unable to load user key '%s': "
"%s\n", appname, val, error);
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
exit(1);
}
node = snew(struct AuthPolicy_ssh1_pubkey);
BinarySource_BARE_INIT(src, sb->u, sb->len);
get_rsa_ssh1_pub(src, &node->key, RSA_SSH1_EXPONENT_FIRST);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
node->next = ci->aps.ssh1keys;
ci->aps.ssh1keys = node;
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
strbuf_free(sb);
} else {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: '%s' is not loadable as a public key "
"(%s)\n", appname, val, key_type_to_str(keytype));
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
exit(1);
}
Uppity: configurable SSH-2 authentication banner. I've had to test banner handling several times recently, what with trust sigils and the fix for CONF_ssh_show_banner. So it's the thing I've most wanted to keep reconfiguring about Uppity so far.
2019-03-28 18:36:45 +00:00
} else if (longoptarg(arg, "--bannerfile", &val, &argc, &argv)) {
FILE *fp = fopen(val, "r");
if (!fp) {
fprintf(stderr, "%s: %s: open: %s\n", appname,
val, strerror(errno));
exit(1);
}
strbuf *sb = strbuf_new();
if (!read_file_into(BinarySink_UPCAST(sb), fp)) {
fprintf(stderr, "%s: %s: read: %s\n", appname,
val, strerror(errno));
exit(1);
}
fclose(fp);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.banner = ptrlen_from_strbuf(sb);
Uppity: configurable SSH-2 authentication banner. I've had to test banner handling several times recently, what with trust sigils and the fix for CONF_ssh_show_banner. So it's the thing I've most wanted to keep reconfiguring about Uppity so far.
2019-03-28 18:36:45 +00:00
} else if (longoptarg(arg, "--bannertext", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.banner = ptrlen_from_asciz(val);
Uppity: configurable cwd for session. All my instincts expect the shell subprocesses to start off in ~, so it's confusing if they start off in some random PuTTY checkout directory. So now we default to $HOME, and if I really do want the latter, I can use the new config option to reselect '.'.
2019-03-31 21:12:42 +00:00
} else if (longoptarg(arg, "--sessiondir", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.session_starting_dir = val;
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-kex", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_KEX] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-hostkey", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_HOSTKEY] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-cscipher", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_CSCIPHER] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-csmac", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_CSMAC] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-cscomp", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_CSCOMP] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-sccipher", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_SCCIPHER] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-scmac", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_SCMAC] = ptrlen_from_asciz(val);
Uppity: allow CLI override of the KEXINIT strings. This is an obviously useful test feature, since if nothing else it will let me exercise every individual crypto primitive, even the ones that the client-side configuration is too coarse-grained to describe in detail (such as the difference between CBC and CTR mode versions of the same cipher).
2019-03-31 07:35:31 +00:00
} else if (longoptarg(arg, "--kexinit-sccomp", &val, &argc, &argv)) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.kex_override[KEXLIST_SCCOMP] = ptrlen_from_asciz(val);
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
} else if (longoptarg(arg, "--allow-auth", &val, &argc, &argv)) {
unsigned method = auth_method_from_name(val);
if (!method) {
fprintf(stderr, "%s: unrecognised auth method '%s'\n",
appname, val);
exit(1);
}
ci->auth_methods |= method;
} else if (longoptarg(arg, "--deny-auth", &val, &argc, &argv)) {
unsigned method = auth_method_from_name(val);
if (!method) {
fprintf(stderr, "%s: unrecognised auth method '%s'\n",
appname, val);
exit(1);
}
ci->auth_methods &= ~method;
Uppity: configurable list of SSH-1 ciphers to allow.
2019-04-01 19:10:09 +00:00
} else if (longoptarg(arg, "--ssh1-ciphers", &val, &argc, &argv)) {
ptrlen list = ptrlen_from_asciz(val);
ptrlen word;
unsigned long mask = 0;
while (word = ptrlen_get_word(&list, ","), word.len != 0) {
#define SSH1_CIPHER_CASE(bitpos, name) \
if (ptrlen_eq_string(word, name)) { \
mask |= 1U << bitpos; \
continue; \
}
SSH1_SUPPORTED_CIPHER_LIST(SSH1_CIPHER_CASE);
#undef SSH1_CIPHER_CASE
fprintf(stderr, "%s: unrecognised SSH-1 cipher '%.*s'\n",
appname, PTRLEN_PRINTF(word));
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.ssh1_cipher_mask = mask;
Uppity: option to disallow SSH-1 compression. With this and the ciphers, I think we've now got the full range of SSH-1 config options (such as they are) that correspond to varying the KEXINIT strings in SSH-2.
2019-04-01 19:15:49 +00:00
} else if (longoptnoarg(arg, "--ssh1-no-compression")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.ssh1_allow_compression = false;
uxserver: option to generate numeric "exit-signal". This mimics a bug in some old SSH servers for which PuTTY contains compensation code (parsing an incoming "exit-signal" two ways and seeing which one worked). I completely rewrote that code in commit 7535f645a, as part of the BinarySource rework. Now I can finally test it sensibly.
2019-03-30 07:28:38 +00:00
} else if (longoptnoarg(arg, "--exitsignum")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.exit_signal_numeric = 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
} else if (longoptarg(arg, "--sshlog", &val, &argc, &argv) ||
longoptarg(arg, "-sshlog", &val, &argc, &argv)) {
Filename *logfile = filename_from_str(val);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
conf_set_filename(ci->conf, CONF_logfilename, logfile);
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
filename_free(logfile);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
conf_set_int(ci->conf, CONF_logtype, LGTYP_PACKETS);
conf_set_int(ci->conf, CONF_logxfovr, LGXF_OVR);
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
} else if (longoptarg(arg, "--sshrawlog", &val, &argc, &argv) ||
longoptarg(arg, "-sshrawlog", &val, &argc, &argv)) {
Filename *logfile = filename_from_str(val);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
conf_set_filename(ci->conf, CONF_logfilename, logfile);
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
filename_free(logfile);
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
conf_set_int(ci->conf, CONF_logtype, LGTYP_SSHRAW);
conf_set_int(ci->conf, CONF_logxfovr, LGXF_OVR);
Uppity: option to always send PK_OK / RSA1 challenge. This allows me to deliberately provoke the conditions for the stale-pointer bug in the agent key list parsing.
2020-02-05 21:14:26 +00:00
} else if (!strcmp(arg, "--pretend-to-accept-any-pubkey")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.stunt_pretend_to_accept_any_pubkey = true;
Uppity: add stunt for unauthorised agent forwarding attempts. With the new --open-unconditional-agent-socket option, every time Uppity receives an SSH connection, it will immediately open a Unix- domain socket and attempt to do agent forwarding on it, in the sense that any connection to that socket will be turned into an "auth-agent@openssh.com" CHANNEL_OPEN request on whichever SSH connection it was associated with. That connection-global socket is independent of any that are created as part of setting up a session channel. The pathname of the socket file is written to the server's event log (there being no other sensible place to send it). The aim is that this allows me to test the behaviour of an SSH client if the server tries to open an agent-forwarding channel outside the usual context. In particular, it allows me to test the change I just made in the previous commit, that if you enable agent forwarding in the client configuration, then auth-agent channels opened by the server are accepted even if no session channel opened by the client has sent an auth-agent-req. More importantly, it allows me to check that I _haven't_ accidentally arranged that those channels are accepted even when agent forwarding is _not_ permitted by the client configuration! Implementation details: the agent forwarding socket was previously implemented as part of the internal sesschan structure. I've moved it out into a little sub-struct of its own which can be created independently of a sesschan.
2020-12-23 22:26:44 +00:00
} else if (!strcmp(arg, "--open-unconditional-agent-socket")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.stunt_open_unconditional_agent_socket = true;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
} else if (!strcmp(arg, "--allow-none-auth")) {
Uppity: add command-line options to configure auth methods. Now you can turn various authentication methods on and off, so that the server won't even offer (say) k-i or publickey at all. This subsumes the previous -allow-none-auth option; there's now a general -{allow,deny}-auth=foo option schema, so -allow-auth=none is the new spelling of -allow-none-auth. The former spelling is kept for backwards compatibility, just in case.
2021-09-28 17:08:58 +00:00
/* backwards-compatibility synonym for --allow-auth=none */
ci->auth_methods |= AUTHMETHOD_NONE;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
} else if (!strcmp(arg, "--allow-trivial-ki-auth")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.stunt_allow_trivial_ki_auth = true;
Uppity: add stunt options for trivial authentication. This allows the 'no trivial auth' option introduced by the previous commit to be tested. Uppity has grown three new options to make it accept "none" authentication, keyboard-interactive involving no prompts, and the perverse sending of USERAUTH_SUCCESS after a signatureless public-key offer. The first of those options also enables the analogue in SSH-1; the other two have no SSH-1 analogues in the first place. (SSH-1 public key authentication has a challenge-response structure that doesn't contain any way to terminate the exchange early with success. And the TIS and CryptoCard methods, which are its closest analogue of k-i, have a fixed number of prompts, which is not 0.)
2021-06-19 14:41:18 +00:00
} else if (!strcmp(arg, "--return-success-to-pubkey-offer")) {
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
ci->ssc.stunt_return_success_to_pubkey_offer = true;
Uppity: add a stunt mode --close-after-banner. A user reported yesterday that PuTTY can fail to print a userauth banner message if the server sends one and then immediately slams the connection shut. The first step to fixing this is making a convenient way to reproduce that server behaviour. (Apparently the real use case has to do with account expiry - the server in question presumably doesn't have enough layer violations to be able to put the text "Your account has expired" into an SSH_MSG_DISCONNECT, so instead it does the next best thing and sends it as a userauth banner immediately before disconnection.)
2023-04-29 10:34:08 +00:00
} else if (!strcmp(arg, "--close-after-banner")) {
ci->ssc.stunt_close_after_banner = 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
} else {
Improve Uppity's online help and command-line errors. We now show the --help output if invoked with no arguments, and the help text also includes a big safety warning in the hope of stopping anyone from mistaking this for a _secure_ SSH server implementation. While I'm here, the errors now all use appname[] in place of constantly repeating the program name. (Not because I anticipate a change right now, but if nothing else, it makes things easier moving errors out into shared source files or between applications.)
2018-10-22 19:17:47 +00:00
fprintf(stderr, "%s: unrecognised option '%s'\n", appname, arg);
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
exit(1);
}
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
if (ninstances > 1 && listen_once) {
fprintf(stderr, "%s: cannot listen once only with multiple server "
"instances\n", appname);
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
exit(1);
}
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
for (size_t i = 0; i < ninstances; i++) {
ci = &instances[i];
if (ci->nhostkeys == 0 && !ci->hostkey1) {
fprintf(stderr, "%s: specify at least one host key\n", appname);
exit(1);
}
if (ninstances > 1 && !(ci->listen_port >= 0 || ci->listen_socket)) {
fprintf(stderr, "%s: cannot talk to stdio with multiple server "
"instances\n", appname);
exit(1);
}
}
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
random_ref();
/*
* Block SIGPIPE, so that we'll get EPIPE individually on
* particular network connections that go wrong.
*/
putty_signal(SIGPIPE, SIG_IGN);
sk_init();
uxsel_init();
Uppity: allow running multiple independent servers. I've moved all the results of the command-line config options into a small struct instead of having them be local variables of main(). We maintain an array of those structs; most command-line options modify the last element in the array; and we respond to the new special option '--and' by appending a fresh struct to the end of the array and initialising it to default values. So now, if I want two or three SSH servers running on different ports with separately configured host keys, banners, etc, I can do that with a single command line along the lines of: ./uppity --listen 2222 --hostkey this.ppk --bannertext "this" \ --and --listen 2223 --hostkey that.ppk --bannertext "that" There's a single number space of connections used in log messages, and each new connection reports which of the servers it connects to. This is only a marginally useful feature: there's not much it does that couldn't have been done just as well by running multiple Uppitys each in their own process. But when I do want several servers at once (which I've been using recently to test the jump-host system), it's quite nice to have them all producing a single combined stream of log data and all conveniently killable with a single ^C.
2021-09-17 15:10:29 +00:00
for (size_t i = 0; i < ninstances; i++)
cmdline_instance_start(&instances[i]);
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
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
cli_main_loop(cliloop_no_pw_setup, cliloop_no_pw_check,
cliloop_always_continue, NULL);
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
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
return 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
}
Reference in New Issue Copy Permalink