0

I'm just trying to see if this is possible before I start working on it. Here's the scenario, I want the server to be constantly listening for SSH requests (which I'm sure it already does, I just don't know where) and depending on the IP address of the incoming machine either do nothing or take an action before the SSH attempt is started.

Note: I want to allow every ssh attempt (with correct credentials of course) into the system, I just want to be able to perform some action before that happens. Running Gentoo Base 2.4.1

4
  • 1
    The listening is done by the ssh daemon and it does already log each connection. What is the action you want to do? An example? – Eduardo Trápani Jun 17 '20 at 15:59
  • The action is actually to disable logging, I want to make it so only devices I don't know get logged – Justanothermatt Jun 17 '20 at 16:13
  • Example would be: I log on with my own device and before anything about my ssh attempt gets logged, logging is turned off, then I complete the ssh and logging is re-enabled – Justanothermatt Jun 17 '20 at 16:16
  • Begin by reading man sshd sshd.conf, then download the source and ... sshd, by default, listens on TCP/22. – waltinator Jun 17 '20 at 16:18
2

To serve up a service over TCP, some program has to call listen() to get a listening socket, and that same program or one related to it has to call accept() to accept the individual incoming TCP connections as further connected sockets. OpenSSH's server dæmon operates in two basic modes in this regard.

  • It is started without the -i option. It executes listen() and then loops repeatedly calling accept() and fork()ing off child processes for every incoming connection.
  • It is started with the -i option. It expects something else to have called listen(), accept(), and fork(), and to have executed it with the connected socket as an already-open file descriptor.

The latter mode is the nowait style of TCP server under the old inetd superserver, the Accept=yes style of TCP socket unit in systemd, and the style of server that works with Daniel J. Bernstein's UCSPI-TCP.

The former mode unfortunately does not correspond with the wait style of TCP server under inetd and the Accept=no style of TCP server under systemd. OpenSSH does not speak the LISTEN_FDS protocol and does not acknowledge already-open file descriptors for listening sockets. Additionally unfortunate is that some people encourage this mode of use and it is thus likely the way that OpenSSH is set up to run on your system.

Because what you want is the latter mode.

You wrap ssh -i inside something else that looks at the information about the remote end of the connnection and does stuff based upon what it finds before then exec()ing ssh -i. (UCSPI-TCP makes this very easy, as the remote end information is put into environment variables.) You then invoke the wrapper instead of invoking ssh -i directly.

The particulars of doing this are up to you, because they depend from things that you haven't told us, such as what service management system you are using. It could range widely from a drop-in snippet with a different ExecStart in a systemd service unit through a revised xinetd config file to a replacement ./service program in a nosh service bundle.

An alternative approach, which will work with the non--i invocation mode but which does not generalize beyond certain options of one particular program giving one particular service (as the aforegiven approach in contrast does), is to use the Match mechanism in the sshd_config file. This cannot do anything except set a subset of OpenSSH options, including the log level, and of course doesn't apply even to other SSH server softwares, let alone to other types of service.

Be sensible in your wrapper. The SSH connection proper is not up and running at the time that it executes; you should not (for security) read any data from the network connection, nor write any to it; and the only things to be doing are checking addresses/ports against lists and thence configuring per-session settings in some way.

Further reading

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.