So I managed to lock myself out of my own computer.
I installed mysecureshell and didn’t realize that it disables shell access, which was my only way to control the machine.
So what did I do?
- Recover the root password
- Boot into recovery mode
- Restart Ubuntu and when the Grub menu comes up
- Select Ubuntu “Advanced options”
- Then select “Drop to root shell prompt”
- Remount /
mount -rw -o remount /
- Reset password
- Re-enable SSH
- Now you should be able to ssh remotely as root. So ssh into the machine as root and provide the password
- vi /etc/ssh/sftp_config
- under the <Default> section make sure that you have the following
- Restart mysecureshell
service mysecureshell restart
When I installed mysecureshell to setup sftp for my Ubuntu 16.04 server, it decided to do a lot of other things like…disable ssh access.
I don’t know why they don’t tell you this in screaming caps to begin with.
But a quick look at the Shell directive (http://mysecureshell.readthedocs.io/en/latest/tags/childs/shell.html) reveals that indeed if you install mysecureshell, it will turn it off by default.
I’m not necessarily opposed to that as a practice but they should make that really obvious as it took me quite some time to figure out what it was that made mysecureshell turn it off in the first place.
I installed mysecureshell via apt-get and configure sftp but then suddenly I got:
$ ssh user@server
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-59-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
22 packages can be updated.
0 updates are security updates.
Last login: Thu Feb 2 01:27:02 2017 from 10.10.10.10
Shell access is disabled !Connection to server closed.
What gives? I didn’t change SSH access…I added SFTP. Or did I? So yes, installing mysecureshell will in fact disable SSH access by default.
Adding the directive
to the <Default> parent tag will re-enable ssh access.
I was installing vCenter on my ESXi server. Since this was my first time installing vCenter, I decided that installing via UI was a far better choice than install from the CLI. But then that meant I needed to get a UI on to the Ubuntu VM I had stood up to do the install from. So this is what I did.
- Install the xfce4 and tightvnc packages. Xfce is a desktop environment for Unix and Unix-like OS’s. We will use Xfce, but you could use a different desktop environment if you want.
sudo apt install xfce4 xfce4-goodies tightvncserver
- Validate that the server can be started and create an access password for view and control (you can also setup a separate password for view only)
- Configure vncserver to always use Xfce
The configurations for vncserver are kept in the ~/.vnc/xstartup file. Out of the box, it looks like this:
xsetroot -solid grey
#x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
# Fix to make GNOME work
We need to change this so it uses Xfce instead of GNOME. You could edit the xstartup file directly (not recommended) or make a back up of it and start fresh with:
- Make the startup script executable
sudo chmod +x ~/.vnc/xstartup
- Start VNC server
- Test from a Mac OS X machine.
- Open an ssh session with port forwarding
ssh -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address
- Open Screen Sharing
- From Safari or from Spotlight, type:
- You should see something like this:
- Daemonize the VNC Server
- Create the service
sudo vi /etc/systemd/system/vncserver@.service
Add the following to it. Replace $user with your username
Description=Start TightVNC server at startup
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
- Register the service with the system
sudo systemctl daemon-reload
sudo systemctl enable firstname.lastname@example.org
- Kill any currently running instances
vncserver -kill :1
- Start the service
sudo systemctl start vncserver@1