On Thu, Dec 26, 2019 at 2:42 AM Giovanni Mascellani <[email protected]> wrote:
> Hi, > > Il 23/12/19 22:40, Carl Karsten ha scritto: > > 3. Box P is a publicly accessible box that has videoteam's public key in > > authorized_keys, so it can accept an ssh connection from box A and > > forward P's 1234 port back to A's any port (like 22.) This should not > > put P at more risk than S. even if someone make A's private key > > public. yes? > > > > OK, so allowing someone shell access to a box does increase the risk, we > > don't need a shell, lets not do that. /etc/passwd .. shell=/bin/false > > or /sbin/nologin takes care of that. > > > > shell=/bin/false (which does allow the sidedoor connection) - when I > > connect, I see the MOTD banner, which makes me fidget. > > I don't think setting the shell is enough: when you connect via SSH you > can override the shell and execute an arbitrary command. I think you > need to disable everything you can disable in authorized_keys (see the > man page, particularly the "restrict", "command" and "permitlisten" > options). In particular, I would set "command" to something like > /bin/false, in addition to setting the user shell. > man authorized_keys leads me to believe this is better: /etc/ssh/sshd_config ForceCommand /bin/false I like it because it is an easier file to edit. sound good? > With all these things set, then I believe that the account is > sufficiently locked down, and the only thing an attacker with the > private key can do is to steal all your ports, which is annoying but > does not entail permanent modifications on the system. > > Periodically rotating the secret key and disabling it when it is not > needed might be a good idea anyway. And, of course, better to keep the > box well updated. > > Giovanni. > -- > Giovanni Mascellani <[email protected]> > Postdoc researcher - Université Libre de Bruxelles > > -- Carl K
