Re: Prepare for more online participation?
Hi, Il 25/03/20 12:20, Paulo Henrique de Lima Santana ha scritto: > Do you have any experience with BigBlueButton? > > It seems a good solution to presentations, but I think we need login to > watch. BBB is a nice software for remote teaching and conferencing, but I am not sure it scales well with many listeners. It is mostly oriented to classroom-like meetings, where only a limited number of endpoints actually engage in the room. So the speakers can directly join the BBB room (and share webcam, screen, use the whiteboard, as they please), but the general public should have the video delivered by a more scalable solution (like the one we already use for DebConf, except that it would need to be integrated with BBB). This also means, of course, that viewers do not need to login). The feedback can be done via IRC as we are already used to do. The BBB room must probably have at least one moderator together with the speaker, so that the speaker is not required to monitor the IRC channel. For both Jitsi and BBB it is important to have a well-connected server and to implement STUN/TURN/ICE properly, otherwise there will be never ending connection issues. This might require some nontrivial admin and network skills, which are surely available in Debian, but it is important to give a fair amount of attention to that. I am not sure of how the connection with Ben was implemented in Curitiba, but my feeling back then was that it was quite hacky. Good for a one time test, but we probably want something more click-and-go for the general availability. For BBB only the moderator needs to have an account on the BBB server. Then they can create rooms and give the access link to anybody. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: private key in the wild
Il 27/12/19 10:41, Carl Karsten ha scritto: > I'm wondering what/where this is set: /bin/sh: > I am guessing the error is because /home/runr/bin/sh doesn't exist, but > this seems like a sloppy way to be secure. I don't know. Probably it depends on how the scp thing is implemented. However, I'd say that yours is the most secure configuration I can think of. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: private key in the wild
Hi, Il 27/12/19 09:51, Carl Karsten ha scritto: > I like it because it is an easier file to edit. sound good? I believe you still have to edit authorized_keys to put the "restrict" option, otherwise a number of other authorizations are retained (see the man page), and I believe you don't want. Also, using ForceCommand will apply to all users, while I believe you still want to access that box with another user for administration. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: private key in the wild
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. 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 Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
