Change of default sshd.config (AllowTcpForwarding no) is not good (Can't connect from VSCode)

[benok]

BurmillaOS Version: v1.9.1

Where are you running BurmillaOS? (docker-machine, AWS, GCE, baremetal, etc.)
VMware ESXi

Which console you use (default, ubuntu, centos, etc..)
debian

Hi, Thank you for developing burmilla os. I really appreciate your work !

I've replaced one of my server from ros v1.5.5, and
I found I can't remote connect the server from VSCode correctly.

I found it's because "AllowTcpForwarding no" is added to /etc/ssh/sshd_config.

# Enforce security settings
Protocol 2
PermitRootLogin no
MaxAuthTries 4
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
AllowTcpForwarding no

I think default configuration of openssh-server is not so bad.

Please refer the sshd_config(5) man page.

https://man.openbsd.org/sshd_config#AllowTcpForwarding

AllowTcpForwarding

Specifies whether TCP forwarding is permitted. The available options are yes (the default) or all to allow TCP forwarding, no to prevent all TCP forwarding, local to allow local (from the perspective of ssh(1)) forwarding only or remote to allow remote forwarding only. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

p.s.(1)
I've tried to find above change from your repos but it's so big and can't find where this is.
So can't send you pull request.
I want to know the location.

p.s. (2)
For my workaround, I appended to my cloud-init.yml something like that.

runcmd:
  - sed -i.bak 's/^.*\(AllowTcpForwarding\).*/    \1 yes/' /etc/ssh/sshd_config

p.s.(3)
I also noticed vi is missing on install.(#99)
I'm not fan of nano. I think this issue might be similar to #99.
Adding nano is not so bad, but deleting vi is not good for vi users.
(I always search key binding help and feel irritating, even though it's on screen :-) )
I've not decided my opinion for #88 (It has vast pros / cons trade-off),
but please care a bit when changing taste of something.

[olljanat]

It was changed because of to handle rancher#2965 but that is just default. Users always can rewrite config with cloud-init https://burmillaos.org/docs/configuration/advanced/write-files/

PS. Will comment those other things later when front of computer.

[benok]

Oh, I'm sorry. Must have checked source with git blame, indeed.
Thank you for your quick reply.
I'll check rancher#2965.
Perhaps I have to learn more secure configuration.

[benok]

Ah, I misunderstood rancher#2965. It's your commit and not rancher's.
Is it really required to set "AllowTcpForwarding no" by default ?
This os is rancher(admin) user only, and password auth is not supported (basically) as other comment says.
I think "AllowTcpForwarding no" is not required.
Because it's only used by admin and if admin account is compromised, it's all over.
Isn't that right ? :-)

[olljanat]

Ah, I misunderstood rancher#2965. It's your commit and not rancher's.

Yes it is my comment but source for those is security audit done by 3rd party to our environment and their recommendation was lock down all those settings by default unless they are really needed.

Is it really required to set "AllowTcpForwarding no" by default ?

Probably not but like with #99 I'm not fan to changing these defaults back and forward. Especially on those v1.9.x versions where we want to minimize changes.

Btw. What is you use case where you need to be able to connect Burmilla with VS Code? Some development server? For those environments v2.0.x versions would be better anyway and as those are still on beta phase so there we IMO can rethink about some of those decision made during BurmillaOS creation. Feel free to open up PR against of master branch about it.

I also noticed vi is missing on install.(#99)
I'm not fan of nano. I think this issue might be similar to #99.
Adding nano is not so bad, but deleting vi is not good for vi users.
(I always search key binding help and feel irritating, even though it's on screen :-) )

Same as above. Can be fixed on v2.0.x.

I've not decided my opinion for #88 (It has vast pros / cons trade-off),
but please care a bit when changing taste of something.

That why it is discussed under possible v3.0 version so older versions can stay as is.

[olljanat]

Btw. How you connect to Burmilla with VS Code? With some extension? And with which kind of settings?

[benok]

I use official 'Remote - SSH' extention. It's still "preview" status, but it's quite stable and useful.
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

If you use Windows and using Putty(not openssh) to connect servers, ssh2plink is required.
https://github.com/benok/ssh2plink

Btw. What is you use case where you need to be able to connect Burmilla with VS Code?

I'm using Burmilla(/Rancher)OS both for development server using Docker and very small production server.
(No need for scaling / redunduncy. enough with just one instance. K8s is overkill for my use case)

In such use case, Burmilla(/Rancher) is very useful.
Setup is quite easy as it has cloud-init, can choose console from Debian/Ubuntu/CentOS.
Upgrade is easy, etc.