modifying sshd auth policy on the fly? - SSH

This is a discussion on modifying sshd auth policy on the fly? - SSH ; one day i was away from home without my keys when i urgently needed ssh access to my web servers. i had turned off password auth, being concerned about the volume of guesswork reported in the logs. thankfully my hosting ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: modifying sshd auth policy on the fly?

  1. modifying sshd auth policy on the fly?

    one day i was away from home without my keys when i urgently needed ssh
    access to my web servers. i had turned off password auth, being concerned
    about the volume of guesswork reported in the logs. thankfully my hosting
    firm was accommodating enough to turn password auth back on for me (eric's a
    great guy). lesson learned, i haven't turned password auth off again. yet.

    while it would help, i'm not real excited about port number obscurity. and
    if i can avoid it, i'd rather not start writing scripts to dynamically
    modify kernel policy at the ip or socket level (i'm using freebsd so the
    canned iptables methods would need some hacking).

    so i'm considering how a non-root script might turn password auth on/off or
    enable/ban specific users or something like that. whatever mechanisms i
    choose to implement, i'd rather avoid running the script(s) as root, if at
    all possible.

    so my question: is sshd willing to read any config files that aren't solely
    root-writable and without receiving a signal or restarting? maybe a bit like
    qmail reads control files on the fly? a group-writable file of banned
    usernames would do the trick, just for example. i read the sshd man file but
    din't get any bright ideas.


  2. Re: modifying sshd auth policy on the fly?

    Tom Worster wrote:
    > so i'm considering how a non-root script might turn password auth on/off or
    > enable/ban specific users or something like that. whatever mechanisms i
    > choose to implement, i'd rather avoid running the script(s) as root, if at
    > all possible.


    By "avoid running it as root", do you mean that you really don't
    want any part of the mechanism to run with root privilege, or just
    that you don't want to have to _authenticate_ as root in order to
    run the script?

    If the latter, then probably the simplest approach is a root script
    with carefully limited behaviour, invoked through some mechanism
    that lets selected non-root users run it without additional
    authentication. A setuid binary is the obvious such mechanism, but I
    like

    http://chiark.greenend.org.uk/~ian/userv/

    for being generally less prone to the various ways one can attempt
    to bamboozle a setuid program.
    --
    Simon Tatham "loop, infinite _see_ infinite loop"
    - Index, Borland Pascal Language Guide

  3. Re: modifying sshd auth policy on the fly?

    On 6/30/08 4:04 AM, in article UPs*CtIgs@news.chiark.greenend.org.uk, "Simon
    Tatham" wrote:

    > Tom Worster wrote:
    >> so i'm considering how a non-root script might turn password auth on/off or
    >> enable/ban specific users or something like that. whatever mechanisms i
    >> choose to implement, i'd rather avoid running the script(s) as root, if at
    >> all possible.

    >
    > By "avoid running it as root", do you mean that you really don't
    > want any part of the mechanism to run with root privilege, or just
    > that you don't want to have to _authenticate_ as root in order to
    > run the script?


    i was really hoping for the former.

    i can certainly do something like this: write php scripts and use ssh for
    good http/html based auth. the script writes a flag to a file saying if ssh
    password auth is enabled or disabled. then a root daemon or cron script
    reads the file and, if the flag state has changed, it changes sshd auth
    policy in sshd_config and restarts the server.

    but this makes me nervous.

    not so much because my root daemon or cron script might be the object of an
    exploit. that's a concern, sure. but i know how buggy my code tends to be
    and dicking around with sshd_config is a pretty sensitive thing. one slip up
    and i can easily lose access to the server -- a database with continuous
    commercial traffic on it -- at the very moment when i need it, i.e. when i'm
    away from base without my private keys and customers are calling to ask
    what's up with the service.

    it just makes me nervous.

    if sshd were a bit more amenable, i might be ok with it. running 'apachectl
    graceful' worries me much less because (1) httpd will check the config file
    and refuse to restart if it doesn't like it, and (2) i don't lose access to
    the server if my change to httpd.conf brakes web service.


    > If the latter, then probably the simplest approach is a root script
    > with carefully limited behaviour, invoked through some mechanism
    > that lets selected non-root users run it without additional
    > authentication. A setuid binary is the obvious such mechanism, but I
    > like
    >
    > http://chiark.greenend.org.uk/~ian/userv/
    >
    > for being generally less prone to the various ways one can attempt
    > to bamboozle a setuid program.


    thanks for pointing userv out. i wasn't aware of it and this looks pretty
    interesting. if i do use a root script/daemon then i'll consider maybe using
    userv.


+ Reply to Thread