sfx2000
Part of the Furniture
Here's a small sample of the re-write/cleanup - this is the OpenSSH and VNC section for Remote Access - this is not final, but an indication that I'm taking it a bit more seriously this time...
(if folks notice - this is in Wiki Markup, so it works with DokuWiki, and might work with other Wiki engines as well)
So again, that's why I ask for your patience...
(if folks notice - this is in Wiki Markup, so it works with DokuWiki, and might work with other Wiki engines as well)
Code:
====== Remote Access ======
As a server, we don't always need to keep a monitor/keyboard mouse attached - I don't have one attached to my servers except when initially setting up the system - once complete, the keyboard/monitor/mouse are removed as it's one small way of improving security a little bit (difficult physical access to the console)
The following sections will enable us to establish secure remote access to the host - whether on the local network, or remote/offsite
==== SSH Server ====
Let's sort ssh - we have lots of space, so let's use OpenSSH vs Dropbear
//**Comment** - Dropbear, like BusyBox, is awesome software, and great for an small footprint (mem/storage) environment - they're safe and secure to use, but in this walkthru, we have a full linux install, and there are better tools to use//.
**Install OpenSSH Server**
sudo apt install openssh-server
ssh back into the box
ssh test@192.168.1.6
or try if you have installed avahi-daemon as noted above
ssh test@testbox.local
Note - most of the defaults are fine, so we'll hit the high points to improve security
edit the /etc/ssh/sshd_config - save a copy first -
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
and then
sudo nano /etc/ssh/sshd_config
edit/change the following:
LogLevel VERBOSE
LoginGraceTime 30
PermitRootLogin no
MaxAuthTries 3
X11Forwarding no
MaxStartups 2:30:10
Add this line - this is for additional security - if the AllowUsers directive is used, then only user accounts that follow will be allowed to authenticate, others, even if they have an account on the system, will not be allowed - this is whether passwords are used or keyfiles.
AllowUsers test
Save changes - restart ssh keep current session open
sudo service ssh restart
Try to login to the ssh server again - should work, if not, check your edits...
** SSH Hardening for Security **
We've already done the two best steps - Disabling the Root Login, and the Access Users directive. These two items will block every connect attempt - I've had an SSH server sitting in my home network forwarded out to the public internet for many years, with thousands of attempts a week, and no compromises.
The absolute very best way to secure SSH is to use public/private key based logins. The downside is that keybased logins do incur a bit more effort to set up on the server side, and if one works with many clients, there's the overhead of managing all those key files across the client machines.
//**Comment** - Public/Private Keys by themselves do not offer more security, however they do offer more 'trust' which is just as important - I use them at work, and I think they're a good idea - I'm just not in a position to answer 1000 questions on certificates, key management, client configurations - when username/passphrase (the PW isn't sent in the clear, btw) is sufficient for most folks - the best security is simple security, things break when more steps are added.//
If you want to set up Public/Private Keys for OpenSSH, see the excellent reference on Ubuntu's wiki, the steps there apply pretty much to any linux based OpenSSH server.
**Changing SSHD Ports**
I'm only adding this as folks will say - How to change the sshd port?
Changing ports is not always a good idea, as it's security thru obscurity, which is no security at all as the robots will always find a way.
I've seen posts on the forums where folks are unwisely using port 80 and/or port 443 - without understand the issues with those ports and processes that run as root, or owned by root - bad idea.
If you __must__ change the SSH port keep in mind that port numbers below 1024 are privileged ports that can only be opened by root or processes running as root.
So pick always port above that - used to be that above TCP port 8000 was good, but many apps are starting to use them.
If you change the SSH port also open the new port you have chosen on the firewall and close port 22.
sudo vi /etc/ssh/sshd_config
Change or add the following line and save. Again, consider above before doing this.
Port <ENTER YOUR DESIRED PORT>
Restart SSH server:
sudo service ssh restart
If you get locked out, you know why.
OpenSSH is very secure if done right.
==== VNC server ====
Now that we have SSH going, we'll add a secure VNC connection endpoint - and we can scrub using an attached keyboard/mouse/monitor
Remote Desktop - tightvnc with xfce, xfce is a lighteight desktop environment - as an option, if one installed Ubuntu Server addition, it's a good time to consider installing a desktop environment - I recommend Xubuntu-Desktop as it's lightweight enough, and very fast over a VNC connection.
**Install xuBuntu-Desktop and Firefox**
sudo apt install xubuntu-desktop firefox
**Install VNC**
sudo apt install xfce4 xfce4-goodies tightvncserver
To complete the VNC server's initial configuration after installation, use the vncserver command to set up a secure password.
vncserver
**Configuring the VNC Server**
First, we need to tell our VNC server what commands to perform when it starts up. These commands are located in a configuration file called xstartup in the .vnc folder under your home directory. The startup script was created when you ran the vncserver in the previous step, but we need modify some of the commands for the Xfce desktop.
When VNC is first set up, it launches a default server instance on port 5901. This port is called a display port, and is referred to by VNC as :1. VNC can launch multiple instances on other display ports, like :2, :3, etc. When working with VNC servers, remember that :X is a display port that refers to 5900+X.
Because we are going to be changing how the VNC server is configured, we'll need to first stop the VNC server instance that is running on port 5901.
vncserver -kill :1
The output should look like this, with a different PID:
Output
Killing Xtightvnc process ID 17648
Before we begin configuring the new xstartup file, let's back up the original.
sudo mv ~/.vnc/xstartup ~/.vnc/xstartup.bak
Now create a new xstartup file with nano or your favorite text editor.
sudo nano ~/.vnc/xstartup
Paste these commands into the file so that they are performed automatically whenever you start or restart the VNC server, then save and close the file.
#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &
The first command in the file, xrdb $HOME/.Xresources, tells VNC's GUI framework to read the server user's .Xresources file. .Xresources is where a user can make changes to certain settings of the graphical desktop, like terminal colors, cursor themes, and font rendering. The second command simply tells the server to launch Xfce, which is where you will find all of the graphical software that you need to comfortably manage your server.
To ensure that the VNC server will be able to use this new startup file properly, we'll need to grant executable privileges to it.
sudo chmod +x ~/.vnc/xstartup
Now, restart the VNC server.
vncserver
The server should be started with an output similar to this:
<code>
test@testbox:~$ vncserver
New 'X' desktop is testbox:1
Starting applications specified in /home/test/.vnc/xstartup
Log file is /home/test/.vnc/testbox:1.log
</code>
**Testing the VNC Desktop**
In this step, we'll test the connectivity of your VNC server.
Next, you may now use a VNC client to attempt a connection to the VNC server at testbox.local:5901 (or 192.168.1.6:5901)
You'll be prompted to authenticate. The correct password to use is the one you set in the vncserver initial setup
Once you are connected, you should see the default Xfce desktop that was included as part of the TightVNC installation.
**Creating a VNC Service File**
Next, we'll set up the VNC server as a systemd service. This will make it possible to start, stop, and restart it as needed, like any other systemd service.
First, create a new unit file called /etc/systemd/system/vncserver@.service using your favorite text editor:
sudo nano /etc/systemd/system/vncserver@.service
Copy and paste the following into it. Be sure to change the value of User and the username in the value of PIDFILE to match your username.
<code>
[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target
[Service]
Type=forking
User=test
PAMName=login
PIDFile=/home/test/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i
[Install]
WantedBy=multi-user.target
</code>
Save and close the file.
Next, make the system aware of the new unit file.
sudo systemctl daemon-reload
Enable the unit file.
sudo systemctl enable vncserver@1.service
Stop the current instance of the VNC server if it's still running.
vncserver -kill :1
Then start it as you would start any other systemd service.
sudo systemctl start vncserver@1
You can verify that it started with this command:
sudo systemctl status vncserver@1
To save memory/cpu time, you can turn off the VNC server on the fly, and turn it on when you need it.
sudo systemctl stop vncserver@1So again, that's why I ask for your patience...
