On Thu, Dec 26, 2019 at 2:42 AM Giovanni Mascellani <
gio@debian.org> 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 <g.mascellani@gmail.com>
Postdoc researcher - Université Libre de Bruxelles