Forem: ServerAuth

How to set up a server with Vultr

Mike Barlow — Tue, 02 Apr 2024 18:46:56 +0000

In this guide we'll be showing you how to work your way around the Vultr Control Panel so you can deploy your own server and integrate it into ServerAuth for easy server management.

Getting started

For the purpose of this guide, we'll assume you already have an account with Vultr and our Platform. If not, do that now before proceeding.

If you prefer a more automated approach then skip ahead to the Easier alternative setup. With this method we create the server on your behalf using the Vultr API.

Adding your SSH Key

When you first login to Vultr, your dashboard screen should look something like this.

Our first task is to add your computers SSH key to your account in Vultr. During server creation you will be asked which SSH Key to add to the server, if you don't have one you can add on then. However, doing it first saves breaking away mid-setup. If you already have a SSH Key in your Vultr account, skip ahead to Deploy your Server section.

In the left menu, click the Account link and then in the "sub left menu", click "SSH Keys" and it should look something like this.

Click the Add SSH Key button to bring up the add form. Drop in your SSH Key and give it a "friendly name" so you can identify which key is which if you add multiple keys, I've called mine "My Laptop". If you need a guide on creating an SSH Key, you can follow our guide on how to set up SSH Keys.

An SSH Key should look something like this.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCwQgfXajx0XezIrX74LJJdzaPEGTO8iWv1loQboV3RaPGxHSbQeRGLsKiHUG46zrNIssq73eCqtzXh9OYBHB8308/QYlXpYBsbgW5q+U+dYL4eTJde5S3oDoKD09EgWJ/NY8vXoJ/iJAlSbvaTUr98xCRQ3F7BUDh9gr7DYpyWNXAjF+XJp4dETT02/y0o+cQ4vITGu0OljvwCIkDSFt+QNQn6Wggd+C1bbQRPY8N0DchzqhF3ixU+XF1Q3KKUC7QTldfnrlRCr6qDKI2eSfUL+iG2N0KuLTSLvCe+84XqM1I2IwfujQtUcAgxyWF2nRp0xYHiKty60nrI1dNbQl5/uEJUHpL5sCo8kcjMfMS0lhTDyoaNBKTt/j3zu+cBiXj2IZa7lBQuLuH+/oTiBtuJ7g+XO8E8zXQKXmbZiFiC/7TA5A4Z9SkB6lcZqGLF5xbnKFnHywUPN1mdrDL8XyDQrNBmdqyzuqVZieDkCyrVraT12ruWjgR8UB0jM+j6yLKqmN9uUzBIvhavlHpzw/YeJ4pZSqjuicWLPnK9BzKSAqx0WbtQa0aCY0O1f6PVeirW6JM9zUvV7H0Yy4QGRyllaahy7z7kD4kxXQX07K0ep2SbmzstpRizRp38dG71fvNpel8dFtKPxOaTy4bBAARUc6UcW1RtJPrHQnxWZmdigQ== mike@example.com

Once saved, head back to the initial Vultr Dashboard screen by clicking the Products link in the left menu and then Compute in the sub left menu.

Deploy your Server

From this dashboard scree, click the "+ Deploy" button next to the search box. This should take you to the screen to deploy a new instance.

First you need to select the type of instance you want, for this guide we are selecting a Cloud Compute - Shared CPU server.

Next, select the location of the server. It's important to know where your target audience may be located. For example, if you server is going to be hosting websites/systems specific to the Floria area you may wish to select the Miami location. This simply ensures that any requests to your websites have the fastest response time possible.
For this guide we've selected London, UK.

Next up, we need to select the operating system you want installed on the server. You also hve the option to upload your own ISO or select an App from their marketplace! We're big fans of Ubuntu here, so we're going to select Ubuntu 22.04.

With the OS selected, it's time to pick the size of the server you need. Vultr have a wide range servers from High Performance AMD and Intel servers down to your standard VPS. For this guide we're happy with a regular cloud compute server but we do want a little extra memory so we've opted for the "55 GB SSD" server.

Next is some additional options including, automated backups, DDOS protection, IPv6, VPC and more! We have our own backup solution so we've unticked the automated backups and left all the other options off.

Now it's time to set the SSH key that we wish to use. If you've been following along then you should have a drop down menu that contains the SSH key you added earlier, select it from the menu if you have. If not, click to add a new SSH key.

With that, it's time for the last step which is to set the Server hostname and give it a label for easy identification. If you're happy with everything you've selected, hit the deploy now button to start creating your server!

You will be taken out of the form and to a listing page that will show any servers in your account. Our new server will now appear in the list with a status of "Installing". Once it's finished the status will change to "Running" and should look something like this.

Once running, your servers IP address should appear under the server hostname/label. Click to copy it as it will be needed next!

Integrating with ServerAuth

When you login to ServerAuth or create your account, you will seen a screen that looks like this. This is your dashboard and server list, any servers you integrate ServerAuth into will appear here.

Click the center of the content area or the blue "Add A Server" button to get started. You'll have the option to select a server provider or to setup a custom server. More on server providers below in the Easier alternative setup

Select the "Create custom server" option, this will take you into the 3 step process for integrating ServerAuth into your server.

The first step will ask you to select the operating system for your server, we selected Ubuntu 22.04 as that matches what we created in Vultr. Like the "Server Label" in Vultr, you will then be asked to enter a name for the server. This will be used so you can identify the server within the ServerAuth server list. For the purpose of this guide, leave Server Users and tags blank. Click next when you're done.

Step 2, is where we need the IP address you copied earlier, paste that into the first box. Next is the SSH port, as default this is 22 and unless you've changed something on your server, you can leave it as is. The last box is for the SSH username ServerAuth will use to make the initial connection to your server. As default with Vultr, this is root. However, you can click into your server within the Vultr control panel and find the username in the bottom left of the content area.

Below is a screenshot showing our step 2 filled out, hit next when you're done.

When creating the server, we selected a SSH key to install on the server. We do this to avoid connecting to your server via a password which is less secure than using a SSH key that is tied directly to your machine. With this in mind, we're going to select the SSH Connection option on step 3 of this installation flow.

When you select "SSH Connection" option you will be shown your ServerAuth teams SSH key. This is used by our system to authenticate with your server so we can configure it. Copy your teams SSH key and open up your terminal.

SSH into the root user of your new server with the following command, remember to switch out the IP address for your IP.

ssh root@[your-server-ip]

Once you are connected, open up the authorized_keys file for your root user, this can be found at ~/.ssh/authorized_keys.

Use whatever editor you are most comfortable with to open and edit the file. I'm using nano in this tutorial.

nano ~/.ssh/authorized_keys

You will see a SSH key already in the file, this will be the original key you selected during server creation on Vultr. Move the cursor to a new line and paste in your ServerAuth team SSH key and save the file.

Head back to your ServerAuth window, and check the box to confirm you have added the SSH key to your user and click Test Connection. The UI will change to show we are testing the connection and once complete, the UI will change again to show if it was successful or not. If it was successful, you will be able to continue setting up your server, click the "Setup Server" button to continue.

Our systems will start connecting to your server, setting up and configuring all it's options allowing us to help make server management easier for you. You'll be shown an "in progresss" screen with all the steps completed, along with the steps left to complete.

Once complete, you will be automatically be redirected to the server overview screen for your new server! From here you can start to manage your server directly from our Platform.

An easier alternative setup

Want to lighten the task of setting up your server? We have an easier way to create your Vultr server via their API.

First head back to the Vultr Control Panel and click into Account via the left menu and then click into API within the sub left menu. As default the API will be disabled, click the Enable API button to turn it on. The page will reload and your API key will be at the top of the page, copy it to the clipboard.

Further down the page is the Access Control section, from here you can restrict which IP address can access the Vultr API on your behalf, click to allow all IPv4 and IPv6 addresses.

Once enabled, head back to the ServerAuth platform and click into the Teams section via the main menu and then click into Server Providers via the sub menu. You will be shown the form to add a new server provider.

Give the provider a name, if you have multiple Vultr accounts this could be the name or email on the Vultr account so you know the difference. Select Vultr from the provider dropdown. A box will appear to add your API Token. Paste it in then hit save.

Click the Servers link in the top menu and click to Add a Server. You will notice that this page looks slightly different from before as you will now have Vultr as a server provider option.

Click the Vultr provider and you will be taken to a new form and prompted to fill out a name for the server so it can be identified within ServerAuth (and the Vultr, we'll send this name to them via the API). Then select which region you wish to create your server in, these will match the options available in the first step when creating the server within Vultrs control panel.

We've selected London again. Once you select your region, there will be a short delay as we use your API token to retrieve the available server types within that region and the prices from the Vultr API.

Select the server type / price you want, we've opted for the same server type as earlier in the tutorial. 1 core, 2GB ram, 55GB storage for $10 per month (at time of writing). Once selected, you can ignore the rest of the options and click the button to create your server.

You will be presented with a similar processing screen as before, however wording will be slightly different to reflect the different processes now occurring.

In the background, our systems are now talking to the Vultr API and creating your server. Once Vultr has finished creating your server our systems will automatically start configuring your server so it has everything it needs for us to manage your server.

Once complete, you will be redirected to the familiar server details page.

Whichever method of integration you chose, setup is now complete! You can use the left menu to access the various options available and start managing your server like a pro!

Check out our help site for more information or assistance on using parts of the system. Alternatively, if you can't find the answer you're looking for, within the ServerAuth platform, you should see the "Need Help?" link in the header. Use this to get in touch with us and we'll do our best to answer any questions you have!

How to set up a server with Hetzner

Mike Barlow — Wed, 13 Mar 2024 12:49:00 +0000

In this guide we'll be showing you how to navigate the Hetzner Cloud control panel so you can create your own server and integrate it into ServerAuth for easier server management.

Getting started

For the purpose of this guide, we'll assume you already have accounts with Hetzner and ServerAuth. If not, do that now before proceeding.

If you prefer a more automated approach then skip ahead to the Easier alternative setup. With this method we create the server on your behalf using the Hetzner API.

Navigating Hetzner

When you first login to hetzner you want to ensure you are logging in to the Cloud section of Hetzner. In doing so, you should see a screen similar to this.

To help get you started, Hetzner create a Default project for you. A project is essentially a wrapper for servers and their configurations. This allows you to group related servers together and isolate them from different projects in your account.

For this guide, we'll use the Default project Hetzner create for you, but if you wish create a new project before proceeding.

Creating your server

To create your first server, click the "+ Create Server" link within the project box.

This will take you to the page to create your server with Hetzner. The first step of which is to select which location you wish to use.

For this guide, we've selected Ashburn, VA which is US east. Next up, we have to select the operating system and version we want Hetzner to install on the server on creation. For maximum compatibility with ServerAuth features, we've selected Ubuntu 22.04.

You will then be asked to select the CPU type for your server. For the purposes of this guide, we've opted for a shared CPU and selected the CPX11 which gives us 2vCPUs, 2GB RAM and 20TB of traffic.

In the next section you can customize some basic networking settings. As standard all Hetzner instances include a free IPv6 addresses, however you'll likely want to select an IPv4 address. To use these you'll be charged an extra fee of €0.00096/hour, or approx €0.70/month (prices correct at the time of publication).

The next option is to set up SSH keys for your root user. Grab your SSH key from your computer, if you're on Mac or Linux you can run the following command.

cat ~/.ssh/id_rsa.pub

This should output your SSH key into termainal for you to copy and paste. If you haven't yet got a SSH key on your computer, you can follow the first part of our guide, How to Set up SSH Keys.

Once, you have your SSH key copied to clipboard, click the add SSH key button and paste your key into the modal window that appears.

For this guide, we are skipping the rest of the config. Depending on your use case you may need to add more hard drives to the server via the Volumes section or enable backups.

Note We'd recommend not using the firewall within Hetzner control panel if you wish to use the Firewall management within ServerAuth.

Lastly, Hetzner will generate a name for your server based upon some of the options selected however, you can amend this and give your server a more recognisable name so you know what the purpose of the server is. On the right of the screen, you should also see something similar to this depending on what options you have selected.

Once you're happy, click Create & Buy now. Hetzner will start creating your server and you will be redirected to the server listing page.

You can hover over the icon next to the server name to find out the status. When it's green like this screenshot, it should mean your server is up and running. Click the IP address to copy it to your clipboard ready for ServerAuth integration.

Integrating ServerAuth

When you first login or create your account with ServerAuth, you will be presented with a screen like this.

Click the "Add a Server" button to get started with integration to ServerAuth. You'll be presented with an option to select a server provider.

Select the "Create custom server" option, this will take you into the 3 step process for integrating ServerAuth into your server.

Step 1 asks you to select the operating system of your server, we selected Ubuntu 22.04 during server creation so select that again here. Then enter a recognisable name for your server so you can identify it within ServerAuth. For the purpose of this guide, you can leave Server Users blank and also ignore tags. Click next, when you're done.

Step 2 asks you for some more information regarding the server. Grab the server IP from Hetzner if you don't already have it saved to your clipboard, and then paste it into the Server IP box.
You can leave SSH Port as 22. For the SSH Username, enter "root" and click next.

Step 3 is where we start to connect to your server. When creating the server in Hetzner, we added our SSH Key rather than use a password, this is always the preferred option over using SSH passwords.

Select "SSH Connection" option and you will be presented with your ServerAuth teams SSH key. This is used by our system to authenticate with your server so we can configure it. Copy your teams SSH key and open up your terminal.

SSH into your root user on your newly created server with the following command, remember to switch out the IP address for your IP.

ssh root@[your-server-ip]

Once you are connected, open up the authorized_keys file for your root user, this can be found at ~/.ssh/authorized_keys.

For this guide, I'm using nano to edit the file but use whatever editor you are most comfortable with.

nano ~/.ssh/authorized_keys

You will see a SSH key already in the file from Hetzner setup. Move the cursor to a new line and paste in your ServerAuth team SSH key, and save the file.

Head back to your ServerAuth window, and check the box to confirm you have added the SSH key to your user and click Test Connection. The button will change to show it is currently testing the connection to your server and once complete, the options should change at the bottom allowing you to setup the server.

Click the Setup Server button to start the setup process. You will be redirected to a processing screen, showing you the steps to setup your server and highlighting which step the process is currently on.

Once setup is successfully completed, you will be redirected the server details screen! Setup is now all complete and you can begin to use ServerAuth to manage your server.

An easier alternative setup

There is also an easier, alternative way to setup your server with Hetzner and integrate it into ServerAuth!

First head to your Hetzner account and click into a project. Hover over the left menu and click into "Security" at the bottom of the menu.

The first screen will show you any SSH keys you have saved. Next click the sub menu to load the API Tokens page.

Click the button to generate an API token. A modal will appear, give the API token name so you know what it's used for and grant it read and write access, then click Generate API Tokens.

Click to show your API token and make sure you copy it. Head back to ServerAuth and in the top menu, click the Team link and then the "Server Providers" link in the side menu. You will be presented with a box to create a new server provider.

Give the provider a name, if you have multiple Hetzner accounts this could be the name or email on the Hetzner account or some other identifier. Select Hetzner from the provider dropdown. A box will appear to add your API Token. Paste it in then hit save.

Click the Servers link in the top menu and click to Add a Server. You will notice that this page looks slightly different from before as you will now have Hetzner as a server provider option.

Click the Hetzner provider and you will be taken to a new page to enter a recognisable name for your server and then to select which region you wish to create your server in. These will match the options available in the first step when creating the server within Hetzners control panel.

Once you select your region, there will be a short delay as we use your API token to retrieve the available server types and prices from Hetzners API.

You can change the region and the list of available server types will update to reflect availability and pricing. For this guide, we selected to create another CPX11 server. You can also ignore the remaining options. Click Create Server to start the process!

You will be presented with a similar processing screen as before, however wording will be slightly different to reflect the different processes now occurring.

In the background, our systems are now creating the server in your Hetzner account via the API and your API token. Once the server has been created, our server management setup will begin and our system will start to configure everything it needs to manage your server.

Once complete, you will be redirected to the familiar server details page.

Whichever method of integration you chose, setup is now complete! You can use the left menu to access the various options available and start managing your server like a pro!

Deploying Laravel 11 with Reverb Websocket Support

Rick Mills — Tue, 12 Mar 2024 21:43:38 +0000

With the release of Laravel 11 comes a brand new first-party websocket package called Reverb. Reverb replaces the need for a 3rd party websocket server such as Soketi or Ratchet, and allows your codebase to act as both the websocket client and server, helping to keep your project nice and tidy, and not reliant on what are often legacy unmaintained packages.

In this guide, we're going to go through setting up a brand new Laravel 11 project, installing Reverb, and then deploying it to your server directly from GitHub. We'll also cover how to configure your server to act as the Reverb host using supervisor.

Creating a new Laravel 11 Project

To get started with creating your project we're going to make use of the Laravel Installer package. This provides a convenient command line to install and set some of the basics of your Laravel installation.

If you've not got the Laravel Installer or would like to use another method, the official Laravel documentation covers a few other ways to create a new project.

laravel new laravel-reverb-demo

The above command will create a new project inside a subdirectory. During the installation you'll be asked a few questions about which database server you'd like to use (we're using SQLite for our demo but feel free to pick your preferred database service), whether you'd like to install Laravel Breeze or Jetstream, and if you'd like to initialize a git repository (select yes to follow along with this guide).

Once your application has been installed you can check it out locally by using a local web server such as Valet, or by using the command line PHP serve tool provided by Laravel:

php artisan serve

Installing Laravel Reverb

Now that you've got a fresh Laravel project up and running, it's time to set up Reverb. This has been made incredibly easy with Laravel 11. Simply browse to your project in your terminal and run the installation command:

php artisan install:broadcasting

During installation, you'll be asked if you'd like to install and build Reverb's Node dependencies, select yes. Once it's finished building Reverb is installed.

Configuring Laravel Reverb

Once Reverb is installed, it'll be time to configure it to work with your project. This may involve tweaking the configuration, or implementing it into your existing codebase.

We recommend following along with the official Reverb documentation as each use case may vary slightly here. Once you're happy it's working as expected for your project you can continue on to the next step, which is to deploy your project.

Deploying your Laravel Reverb application

Once you've got reverb running, and have implemented it as needed locally you'll be wanting to deploy it to your server.

ServerAuth's site management allows you to deploy sites directly from GitHub, with automatic deploys every time you push to a production branch. Here we'll detail how to set your Reverb project up on a server managed with ServerAuth.

For the remainder of this guide, we're going to assume you've committed your project up to a production branch on GitHub, and have set up a server with ServerAuth. If you've not done this yet you can check out our other guides on setting up a server. We also have guides on setting up a new server from DigitalOcean and Hetzner.

1. Add a new site

From your server management page in ServerAuth, click the 'Sites' link in the left-hand sidebar. If your server has not yet been configured for site hosting you'll be prompted to install it.

ServerAuth intentionally does not install features onto your server unless you plan on using them. When you click the install button your server will automatically be configured with Nginx and PHP.

Once site support is enabled on your server, click the Add Site button in the top right to start setting up your project. You'll be prompted to provide the domain name, site type (select "PHP or Static HTML" from the list), a PHP version (Select 8.3 or newer), and a user (you can also create a new user specific to this site if you wish). Be sure to also tick the SSL Enabled box unless you wish to use a temporary domain, in which case tick the "Enable Temporary Domain" box instead. Finally, click the Add Site button to start the setup process.

ServerAuth will now configure the webserver for your site. Once it's done you'll be shown the site dashboard, which provides a general overview of the site.

Here's how our site setup looks:

2. Deploy your site

Now that you've set up a new blank site, we need to connect it to your GitHub project. If you've not already done so, link your GitHub account with your ServerAuth account here. This will allow ServerAuth to pull in your project to your server automatically.

Next, click the "Install Application" button on the site overview page, and select the GitHub account that has access to your project repository.

Enter the repository name into the textarea (e.g yourname/yourproject) and select the branch you wish to deploy.

Once you've selected the branch you'll have the option to enable automatic deployments and run migrations. Here's how ours looks:

Once your project has been deployed, check that you can access it before proceeding.

3. Enabling Laravel Reverb

Now that your sites running it's time to enable Laravel Reverb. For this, we're going to make use of ServerAuth's built-in Supervisor daemon management.

For this example we're only going to be using the Supervisor setup, however, Reverb also supports running via Nginx, which is covered in the official documentation. If you wish to do this on your ServerAuth server and keep things tidy, you can create a 'pre-load' file which will load before your site's main nginx configuration, this can contain your Reverb specific nginx configuration. To add this, place it inside the /etc/nginx/serverauth/sites/yourdomain.com/reverb.conf.pre directory to autoload it into your site's configuration.

To set up Reverb to use Supervisor, browse to your server inside ServerAuth and select 'Daemons' from the sidebar. If you've not yet installed supervisor a button will be shown to install it.

Once installed you can add a new daemon for reverb. The key parts here are the path to your project, and the command to run. Reverb can be run via artisan with the reverb:start option.

Here's how ours looks for this demo:

You've now set up Reverb and have it running on your server! If you browse to port 8080 on your deployed site you'll see Reverbs default 'Not found.' message. This means Reverb is running and no action was provided, you're now ready to start using websockets on your site.

Common issues

Many server providers disable certain ports at the host level. If you're using a provider such as AWS or Azure you may need to open port 8080 on their firewall (sometimes referred to on their platforms as a security group).
Reverb requires Laravel 11 and a minimum of PHP 8.2. If your server's default PHP version is older then be sure to reference the full path to your chosen PHP version. On Ubuntu servers managed by ServerAuth this will typically be /usr/bin/php8.x

Using ServerAuth for your Laravel project deployment

Laravel offers an incredible amount of flexibility and ease of development, allowing complex applications to be built in no time at all. With ServerAuth you can deploy your Laravel projects directly from a Git repository to both your live and staging sites.

Combined with built-in database, cronjob, and scheduler management ServerAuth is the ideal sidekick to make Laravel server hosting a breeze!

Learn more about Laravel Deployment using ServerAuth

How to deploy a Filament app

Mike Barlow — Tue, 05 Mar 2024 22:30:39 +0000

For this guide we're assuming you already have PHP, Composer and GIT installed on your computer and that you're familiar with terminal commands.

Create your application

First we are going to create a brand new Laravel application. I have a "sites" folder in my user directory where I keep all my projects. If you already have a folder like this, navigate to it in your terminal, if not you can use the following command to create your own sites folder and navigate into it.

mkdir ~/sites && cd ~/sites

Next, we're going to use the "create-project" command from composer to create a new Laravel application in a folder called "filament-app". Use the command below to create the application and navigate into the folder.

composer create-project laravel/laravel filament-app && cd filament-app

This command simply, downloads the "laravel/laravel" repository from packagist and runs a composer install on it to install all the framework dependencies. It does this in a folder called "filament-app" and then it changes our terminal directory to the new application.

Once finished, that is the base Laravel application installed and we can start to install Filament. If you have a local server running that allows you to run applications you can visit that project locally and you should see the default Laravel application homepage that looks something like this.

Next we'll start to install filament. We'll do this via composer again. Use the following command to add filament to your composer file and install it and it's dependencies.

composer require filament/filament:"^3.2" -W

Once finished we can create your first panel. Panels are the top most containers within Filament. Panels then include pages, forms, tables, actions, widgets and more that let you build feature rich admin areas.

Run the following command to start an interative flow that will ask you for the ID of the panel.

php artisan filament:install --panels

It should be prefilled with "admin". Leave this as is, and press enter. The command will now create and attempt to configure your first panel and will provide some information on the status. It should look something like this in your terminal.

You will also be asked to give their repository a star on Github. Don't be shy, show them some love ❤️.

Save to GitHub

Next we're going to save the code to Github. If you haven't already, sign up for a github account or login if you already have one.

Before proceeding, if you haven't already we recommend you add your SSH key to your Github account.

In the top right corner, click the plus icon to open up the drop down menu and click new repository.

Give your repository a name and then be sure to select whether the repository should be public or private. For this guide I've called it "filament-app" but you should give it a more descriptive name.

Upon creation you'll be given some instructions on how to add code to the repository. Within the Quick Setup section, ensure the SSH option is selected and copy your repository URL. It should look something like ours below but with your username and repository name.

Head back to your terminal window and make sure you are within your project root folder and run the following commands.

# This creates the git setup on your machine.
git init

# Remember to swap out the repository URL in this command
# This command links the keyword "origin" to your repository URL
git remote add origin git@github.com:serverauth-com/filament-app.git

# This adds all the files to "staging" meaning they are ready to be committed
git add --all .

# This creates a git commit with a commit message of "Initial Commit"
# You can change the commit message if you wish to be more descriptive in your commit
git commit -m "Initial Commit"

# This command pushes all new commits to the repository and branch specified
# Note the use of "origin" here, this is how git knows the repository URL to push the code to
# and "main" is simply the branch name. "main" has become a defacto standard for the default branch
git push origin main

Once completed, your code should all be in your repository on Github. If you head back to your browser and refresh the repository screen that had the quick setup section you should now see all the files and folders that make up the Laravel application we have created so far.

Provision server

For the purpose of this guide we'll assume you already have a server configured with ServerAuth. If you want a guide on creating a server, you can check out our guides on how to set up a server with DigitalOcean or how to set up a server with Hetzner.

With your server set up within your ServerAuth account we need to install a few different services if you haven't already got them enabled.

Sites

First we need to enable "Sites". This will install and configure Nginx and PHP on your server. Once your server is setup, click to manage the server within the ServerAuth platform and head to Sites in the left menu.

You will be presented with an info box and a button to "Install Nginx". This button will also install PHP at the same time. Click the button to start the installation and you will be shown an "in progress" screen. You can navigate away from this page while this is installing and you can move onto the next service.

Databases

Next, head to the Databases section from the left menu. You will be presented with the options to install MySQL and also Redis. We're going to need MySQL to store data for our Filament application so go ahead and click to Install MySQL.

Redis is an optional service, you can use Redis to help manage things like caches and user sessions so it can be useful depending on your needs with the application. If you think you are going to need it, go ahead and click the "Install Redis" button too.

As with the Sites section, you will see "in progress" screens for MySQL and Redis.

Next we need to create a database and database user, once MySQL has finished installing and the page has refreshed, you should see an empty table and a "Create Database" button. Click that to bring up the create database modal, fill out the form but ensure you leave the "Allow remote access" checkbox unchecked. Remember to make a note of the data you enter as this will be needed later.

Daemons

Like Redis, Daemons are an optional service. A Daemon is essentially a task that can run in the background without interaction from a user and depending on the configuration it can be set up to always keep it running.

Laravel comes with the ability to run queues and other background jobs that can benefit from being run as Daemons. If you are going to be making use of these then head to the Daemons section. Once there you can "Install Supervisor", which is almost a de-facto standard for running Daemons on Linux.

Create site and deploy

Head back to the "Sites" section once it has finished installing and you should see the option to "Add Site", click this button and you will be taken to the form to create a new site. Fill out the form with your details, ensuring you select the latest version of PHP when doing so. We also recommend you make use of website isolation and create a brand new user for your website to run under. This just adds an extra layer of security to your setup. For this guide, we've created a new user called "filament-app".

ServerAuth also provides the ability to create a temporary domain if your website is not yet ready to go live. Check the "Enable Temporary Domain" option and our system will create a subdomain within one of our development domains for you to use while your application is in development.

Click add site and our system will begin creating and configuring the Nginx records on your server. While this is happening, you will be taken to the Site Overview page where you will see the details you entered along with your temporary domain if enabled. Avoid visting your temporary domain until the site has finished installing. See below for a screenshot of the Site Overview page.

Once your site has finished install, click the Install Application button towards the bottom of the Website Details section, alternatively click "Application" in the left menu. If you haven't already, connect your Github account to ServerAuth and then return to this page. You should then see an option to select your connected Github profile.

Select your Github profile and populate the text box with your repository, we'll then try to find your repository and retrieve the list of branches in your repository. As per this guide, we only have one which is our "main" branch.

Some extra options will appear once you've selected your branch, check the option for composer install and then click install.

Configure SSH access

While your application is being installed, we'll need to setup your SSH access to the server so we can configure Laravels .env file.
Head back to Manage Server via the left menu and then click Server Access. On this page will be a "Grant Access" section. Select yourself from the Team Member drop down and then check the server user you defined when installing the site, ours was "filament-app". We don't need to set any date restrictions so leave that as is.

Save that form then head to "SSH Keys" in the top menu and add your SSH key to your account. Once saved, please allow a few minutes for our systems to sync your SSH Key with any servers you have been given access to.

Run database migrations

Once your site has finished installing and your SSH access has been synced, it's time to log on to your server and update the application .env file! Open up your terminal window and run the following command, swapping out the user and server IP address for your details. You can find your servers IP address on the Server Overview page.

ssh user@ip-address

If it's the first time, you may be asked to check the fingerprint and the server you are connecting to. Reply "yes" when asked. Because we have logged in to the server as the user running your application, we will be taken automatically to that users home directory where the site should be. You can run ls in your terminal to check list the files and folders available. I entered "filament-app.test" as the domain for the site when creating it so we can see that folder shown below on the server.

Change into that directory with the cd command, as shown below. Remember to swap out the domain name for the one you entered.

cd filament-app.test

We now need to create the .env file. Laravel ships with an example .env file so we can copy that one with the cp command.

cp .env.example .env

Next we want to open that new .env file for editing. For this guide, I'm using nano but use which ever editor you are more comfortable with.

nano .env

Within the .env file, find the block of attributes for the database details and enter the database name, database username and database password you entered when creating the database in an earlier part of this guide. The connection, port and host can be left as the default values.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE="filament_app"
DB_USERNAME="filament_db_user"
DB_PASSWORD="my_super-secure_DB_p4s5w0Rd!"

Save the details and close the file editor, now we are ready to run the laravel migrations and create our first user. Run the follow command to run the database migrations and create the needed database tables.

php artisan migrate

Now run the following command to create the first admin filament user.

php artisan make:filament-user

You will be asked to enter a name, email address and password for the user. Once done press enter to save and create your user.

Test!

Will that, we should now be able to visit your site. Head to your domain (or temprary domain) and add /admin to the end. Our temporary domain was "scenic-spire-3aca605f.serverauth.net" so we have gone to https://scenic-spire-3aca605f.serverauth.net/admin

You should be presented with a login screen, entered the email and password that you just entered to create the filament user. If everything has been successful, you will be logged in and should see a dashboard similar to this.

You can now begin developing your application using Filament!

Enable push to deploy

When developing, it will be handy to have code automatically pushed to your server. If you head back to the ServerAuth platform and click Sites in the top menu, click manage on your filament app to be taken to the Site Overview page.

From here, you can trigger a manual deployment but this isn't great as it would mean having to visit ServerAuth everytime you pushed a commit, instead, we can enable "Auto Deployment". ServerAuth will create a Webhook on your repository that will receive a request everytime you push a commit to your repository. If it's the correct branch that has been pushed, our system will automatically trigger a deployment!

To enable it, click Application in the left menu while on the Site overview page. In the main content area you should see a toggle option to turn it on.

Now every time you push code to your repository, our systems will automatically deploy it for you!

Happy building!

Learn more about Laravel Deployment using ServerAuth

Why you need an SSH Access Manager - Part 2

Mike Barlow — Tue, 15 Jun 2021 18:45:50 +0000

Before diving into this article I recommend you take 5 minutes to have a read of part 1 of our 2 part, "Why you need an SSH Access Manager" blog series.

Part 1 of our article featured more information on the security aspects for why to use one but in this article, I want to talk more about the "managing" of SSH keys as a reason to use one.

Authorized Keys

To define which SSH keys have access to your server, each server user has its own directory and within, a folder called .ssh. This folder should have a file called authorized_keys and the purpose of this file is to hold the public key for each SSH key that should have access.

It's a very simple system that works great, as it's a simple case of adding a new public key on a new line in the file and saving it, (or deleting a line to remove access).

Flaws

This however, does come with some flaws! (Doesn't everything?) In the first instance, this requires you to have access to that server yourself to add a new SSH key.

Usually, this won't cause too much of a problem but there could be times when you need access to a server but have just got a new computer. Or maybe, you reformatted and didn't back your SSH keys up!

Another problem with this is that these authorized keys are not shared between servers. So if you are the manager/team leader and have someone new join your team, have fun logging into every server and adding the persons public key to the authorized keys file.

One of the last main flaws is like the last but in reverse! You have a team member leave and you now need to remember every server they had access to and you have to log in to each one and search the authorized keys file to remove their access.

The Pandemic

The recent pandemic and the work from home movement has shown a rise in the people working from home rather than the office. This means a higher number of people most likely working on new machines, which in turn means more SSH keys needing to be added to servers.

Then if that person leaves, you also now have to find and remove, not just one, but two SSH keys across every server.

Now, with people starting to return to the office, there will be a need to add SSH keys from your work machines to any new servers created during the pandemic, creating more unnecessary for the team leaders.

Solutions

This is where an SSH Access Manager like ServerAuth steps in.

ServerAuth gives you a central place to manage all your SSH Access. Simply create your servers, add your users and grant access all within our platform.

Your users with a ServerAuth account will then be able to log in and add all their SSH keys. Once added, ServerAuth will automatically sync all of the users' SSH keys to every server that you have given them access to.

Find yourself away from your main computer and needing server access? Or have you reformatted your machine and forgot to back up your old SSH key? Simply grab this new machines SSH key, log in to ServerAuth and add the key to your account and wait for it to sync!

Try it now!

While it's not the main thing in most teams tech stacks, an SSH Access Manager is something that teams should start considering. We built ServerAuth in response to our personal experiences and know it will help others!

5 things you should do right now to secure SSH access to your server

Mike Barlow — Wed, 14 Oct 2020 12:05:25 +0000

At ServerAuth our goal is to help improve your experience with SSH access management on your servers. We do this with our Platform and Agent and can make managing access simple!

Managing access is just one part of running a server, keeping it secure is another part. Over the last few months, we've been putting together some guides on how to set up and implement some basic things that will help keep your access secure.

It's worth noting, these will not secure your server entirely as these are for securing your SSH access not your server as a whole.

1 - Changing your SSH port

This is one of the most basic things you can do. Everyone who has had some experience with servers knows that SSH access is on port 22. If someone was trying to gain illegal access to your servers they will know automatically to try that port.

Changing the port number you use to SSH into your server is something simple and quick that can be implemented and instantly adds a complication for anyone trying to gain access to your server as they now need to find what port SSH is running on before they can log in.

To set this up, all you will need to do is edit one file, /etc/ssh/sshd_config. Set the correct config value, save and you're done!

You can read the full guide here.

2 - Disable password login

By default, all users have a password that can be used to login to the server via SSH. If you have the IP address and the username / password you will be able to log in, no matter who you are!

By disabling password login, you are forcing users to set up SSH Keys on your servers before they can log in. A SSH key is a special key that has a public and a private part. The private part of the key stays on the user's computer, the public part is placed on the server.

This means even if someone has given away the password to the server, only those users with a valid SSH key authorized on the server can log in.

You can read the full guide on how to disable password login here.

3 - Setup password aging

At ServerAuth we always advocate removing the need for passwords and moving to SSH key login entirely. You can then use our Platform to easily manage who has access to your servers! However, we appreciate that it may not always be possible to setup. So to make passwords safer, you can implement Password Aging.

As the naming suggests, this is the act of defining how old your passwords can be. The second your passwords age moves over the allowed limit in the config, the server will force you to change your password.

This adds the benefit that, your password will be changing more and therefore anyone who gains knowledge of your password will hopefully only know an old, expired password, keeping your server secure!

As mentioned, we would highly recommend disabling password logins entirely but if you cannot, read our guide on how to set up password aging here.

4 - Disable root access

In Linux, the root user is the top dog. This user has access to do EVERYTHING. If someone malicious was to gain access to your server via the root user, you're in for a very bad time.

Thankfully, Linux provides us with a way of disabling access to the root user via SSH. Doing so will force a malicious user to gain access to your server via one of the other server accounts. Server accounts which hopefully you have created with fewer permissions than root and only given them access to what they need.

The benefits of this are obvious, by changing a single line within /etc/ssh/sshd_config, it can be the difference between losing a few folders versus losing a whole server.

You can read the full guide on how to set this up here

5 - Two-Factor authentication for SSH

Two-factor authentication is becoming a standard across websites, with many forcing you to enable it to keep your account secure. Doing so means people now need to know your password and they need access to the app on your phone which generates the two-factor codes!

It's a great way to add extra security and peace of mind to your account / profile. But did you know you can set it up on your servers also?!

That's right, you can configure your servers so that anyone trying to log in via SSH will need to enter their password or have their SSH key on the server and then, add in a separate code generated via an app on their phones.

The process from a users point of view is extremely familiar to anyone who has used two-factor authentication before and is an amazing way to secure SSH access to your servers.

You can read our full guide on how to set it up here.

Conclusion

Server security should also have layers! Individually all these points don't amount to much, but added together they are simple and effective ways to secure SSH access to your servers!

Managing Server Access, SSH Keys and our solution!

Mike Barlow — Tue, 20 Aug 2019 20:50:33 +0000

After seeing the complexities of managing SSH keys within a growing team and all the new legislation with GDPR, myself and good friend Rick set about seeing if we could solve the issue. Both our places of work suffer from the pain of managing team members SSH keys, both with slightly different reasons from a smaller team but 100% remote and no actual central storage of SSH keys to a larger office based team but with lots of servers which rely on server deployment scripts being individually updated and run every time you want to add or remove someone's access.

While the SSH Keys stored in the deployment scripts is a step up than nothing at all, there is a script required for each server so to modify the keys you need to add or remove the keys on each server and then wait while the rebuild scripts run, which is not ideal - we all have better things to be doing!

We decided early in the planning process that the central API, which would store the ssh keys, should not need access to the server nor should it know anything about the server other than a ‘server name’ label which is to be used within the GUI when granting / revoking access. We also wanted the option to choose which accounts on the server would be managed by this central ssh key api. This narrowed down our options for executing this idea to an agent that would run on the server and call to the api with the unique key for that account, allowing us to return the correct SSH keys.

We started testing our concept by simply placing a text file on a test domain to replicate an api endpoint, we knew we could built up a CRUD based GUI to manage the servers, accounts and SSH Keys no problem but our main concern was being able to find the right combination of cron jobs, server permissions and distribution methods for the agent. Given our knowledge of PHP and the Laravel framework we decided to give Laravel Zero a go (Laravel Zero is a console framework, built using Laravel components), we could easily build out the console commands needed to setup the agents config on the server, contact the api and write to the correct authorized_keys file to set the allowed SSH Keys on the server.

After some trial and error we got everything working, however we ran into one snag, mainly from us not reading documentation correctly, and not fully understanding what people use their servers for. We'd used Zero's built in compiler (which uses box under the hood), which creates a PHAR archive. This can be executed as a binary on Linux systems. However as we quickly discovered, would require a compatible php version to be installed. This wasn't ideal as we’d need to require, or install a specific php version. This was a bit of a dead end for us. Whilst we're both PHP developers clearly not everyone out there is using, or would want php installed on their servers.

Given what we wanted to accomplish and the requirements around it, we realised that PHP wasn’t going to cut it and that we’d need to actually look at a different language. After further research we settled on Go as the language to use for the agent as it would allow us to both provide pre-made binaries for all major Linux distributions (along with the source code for anyone wanting to manually compile it).

So, with that we drew straws, which resulted in Rick taking on the task of learning Go and creating the agent, leaving myself to build out the api and application gui.

Building the Agent

With the division of work decided, Rick set about following the Go docs and decided to make use of Cobra, an awesome package for building CLI based applications. This sped up development time significantly, and allows for building out the required functionality with minimal fuss.

The agent ended up being pretty simple. It supports adding a new system account, removing system accounts and then syncing the ssh keys for all accounts. A config file is created and contains the api keys needed to run each of the sync commands for the servers system accounts. The sync command can then be set up to run as a cron task at frequent intervals.

This probably sounds insanely basic, but this was the intention. We don't want to know the ip addresses or location of the servers connected to ServerAuth, so at no point are any server details required, we just ask for a generic name (although this is more for your own reference than ours). The agent sits on your server, and connects to us instead of the other way around. More on this later.

Building the API & Web App

I obviously drew the task of creating the GUI / API. As we both knew Laravel, it was the obvious choice to use this as in the future we would both be able to make updates if necessary. Before starting the agent, Rick also put together the ui design. Not only did this make my life easier, but was super quick to do as it was built using TailwindCSS!

Early on I decided to avoid doing anything fancy with Javascript and decided to keep it simple and functional. We can always roll out more bells and whistles at a later date.

For the GUI, we settled on having a user register and create a team, this person can then invite other people to create an account and join. Each user would then be able to manage their SSH Keys. If a user had the correct permissions, they would then be able to “create a server”, this simply creates a row in our database with a unique key and will then provide the user with the code to run on their server to setup and configure the agent.

Once the server was configured, the user would then be able to manage that server within the GUI and assign other users from their team to individual accounts on the server. This would allow you to give team leaders access to the root user for example, but only give standard team members access to the users on the server that they need access to!

Then obviously came the actual API endpoint, this required nothing complicated other than receiving unique keys for the team, server, server account and then returning all the SSH Keys for the users assigned to that server account. This would require multiple calls to the API per server for each account managed by the API but it would make things easier to handle and secure rather than a single API call to retrieve SSH Keys for every account on the server.

From proof of concept to working product was pretty rapid. By making use of open source packages, and modern development techniques we've been able to rapidly take a proof of concept to workable product in just a few months.

With our built in SSH Key Syncing, Scheduled SSH Access and an array of other features, we've been able to make SSH Access Management painless and easy to manage!

We're now in the advanced testing phase, using ServerAuth in production setting and everything has been working great. We’re now wanting to open things up and get more people involved to iron out all the last few kinks in the system, and get some important feedback from others, especially if this is something that may make life easier for them too. We're keeping ServerAuth as a free service for now but will likely look at offering a couple of paid plans for larger organisations at some point down the line.

If you work somewhere that you feel would benefit from ServerAuth we'd love to work with you! We've put together some details over at https://serverauth.com but we're also on twitter if you’d like to chat (@MikeBarlow, @RickMillsUK and @ServerAuth).