Shell In a Box - same as ssh?

QuickBox Support
,
#1

I suppose the title really asks it.

For a long and complicated reason I cannot get ssh access on one of my computers.

Is shell in a box essentially the same? IE can I do all the things I need to do from the web console that I could if I was ssh in to the box?

#2

Shell in a Box is an exact emulator of the bash environment so you shouldn’t have any problems performing essential and/or in-depth tasks.

May I ask what types of issues you are facing when trying to access ssh? I read “long and complicated” - this only makes me curious :slight_smile:

#3

abridged version: I cannot get openVPN to work properly with the Chromebook - seriously have you tried? Horrific!

At home the firewall allows my IP, but if I’m out it’s nice to know I can still access the shell :grinning:

#4

Oh, yeah… that sums it up then :laughing:

I wonder if they have some proprietary means to botch VPN use on their hardware.

One of the reason I opted for Shell in a Box was that very reason. I have to work through numerous VPN networks for my real life job and they too will cast a shadow on things such as SSH connections. The Web Console makes it easy enough to bypass all that noise.

#5

it’s bloody brilliant!

while we’re chatting - could you answer a quick question about how the virtualhosts are set up on the quickbox setup?

#6

Not really any vhost per se. We include a series of configuration files for each independent application. You can find these located at /etc/apache2/sites-enabled. As you install services, the package install scripts will write in the necessary config files and apache will smartly pick up the rest.

#7

I’m talking about the virtualhost 80 vs 443 stuff in those conf files
I’ve noticed that if you hit http://seedbox.domain.net you get an unencrypted password prompt, you then get forwarded to the https (atleast I do after running through the lets encrypt process). Is there a reason the config for 80 doesn’t just forward to 443 without asking for auth?

If there’s some weird rutorrent / scgi hook voodoo going on fair enough, was just curious why the option of unencrypted password was offered

#8

Ah, this is due to the auth being required for both 80 and 443 connections. The thing with it is this… when that happens you are technically authenticating rutorrent and the dashboard, then it forwards you to 443 connections wherein you are required to authenticate on a secure connection.

Reason being:

The dashboard is stored at /srv/rutorrent/home which is due to how we hook in some essential rutorrent magic to make the dashboard so very amazing. Therefore, port 80 is requiring that authentication be submitted before forwarding to a secure port by way of rutorrent.

I have actually thought about turning off authentication on port 80 and just passing entry over to strictly https headers… but then people that demand using rutorrent without secure protocol get stiffed.

This can technically be removed by anyone that chooses and is using https (which is preferred) by editing the default-ssl.conf for the :80 virtualhost. Since you’re using Lets Encrypt you can add a permanent redirect that will only require authentication once for both 80 and 443… since it’s imediately forwarding the headers to a secure port.

Add the line Redirect permanent / https://DOMAIN add the end of the :80 vhost such as the example below.

</VirtualHost><VirtualHost *:80>
        DocumentRoot "/srv/rutorrent/home"
        <Directory "/srv/rutorrent/home/">
                Options Indexes FollowSymLinks
                AllowOverride All AuthConfig
                Order allow,deny
                Allow from all
        AuthType Digest
        AuthName "rutorrent"
        AuthUserFile '/etc/htpasswd'
        Require valid-user
        </Directory>
SCGIMount /quickbox 127.0.0.1:XXXXX
Redirect permanent / https://DOMAIN
</VirtualHost>
#9

lol @ me pasting the line including DOMAIN thinking it was linked to host name somewhere up the file.

When I restart apache2 it continues to forward to DOMAIN, what’s that command to clear the cache?

#10

nvm - found it in a previous post :slight_smile:
that’s great.

I found I needed to add a / on the end of the domain to allow things like nextcloud to switch to https too

thanks for your help!

1 Like
#11

@JMSolo Question somewhat related to this.

I’d like to take port 80 for something else. Can I disable that whole virtual host section that references port 80 and still have everything work on 443?

Thanks for your time.

#12

Absolutely! I would think that you can either comment that out… assign it to a subdomain… or just offer it to the apache gods and implement some other vhost. As long as QuickBox stuff remains attached to 443, you’re golden.

1 Like