One problem I found was that I use an alternate port for my SSH server instead of the default port 22 but I couldn’t see an option to use this port in the Gnome-RDP interface..

It turns out that in the field called ‘Computer’ you can also add the port number just as you would using the terminal, so for port 6000 just use 192.168.1.1 -p 6000 where 192…. is your servers IP address.

Of course I’m specifically talking about ssh and sendmail. I’ve read plenty of comments theorising on the reason for the sshd daemon running, many talk about Red Hat being mainly installed on headless servers so you need to be able to log in over ssh after the install is complete.

If that’s the reason then that’s all well and good for Red Hat Enterprise Linux but I doubt the same is true for Fedora. Surely the vast majority of Fedora installs are personal computers and laptops where if you need ssh it should be up to you to start the service. Exactly the same is true for sendmail.

It’s been the same with Fedora since I started using it at Fedora Core 4 and it’s something I’ll never understand. At the very least it should be an option in the Anaconda installer if you with to run ssh.

It’s not like I upgrade the firmware that often but it’s annoying that I have to go through this procedure every time I do.

I see the latest firmware also has an enable SSH option but I’d really like to see this expanded into a full SSH interface, allowing for different ports, not allowing password logins, certificate generation etc.

WordPress Directory Permissions

While I was upgrading my blog to WordPress 2.6 I noticed some strange files in my upload directory. As suggested in the WordPress codex my upload directory permissions were set to be world writeable (777) since this was required my my web host but it seems that someone has exploited this hole and uploaded files there. On top of that they then get linked by Google so searches on my site show content from the uploaded pages.

I’ve since disabled the WordPress upload capability by changing the directory permissions and I advise you to do the same. This page echoes my sentiments well.

The Diskstation stays running but refuses all connection via http, SSH, cifs or any other method. The only way to fix is to turn it off using the button on the front panel.

I’ll download and install the 0640 firmware tonight and see if it fixes the issue.

Update – Just installed the 0640 firmware and it still doesn’t work, it’s also a bit hard to debug since the SSH connection is lost so you’re working in the dark.

You can also detach the sessions, log off from the SSH session and then later log back on, reattach the session and continue from where you left off. It’s really useful for long running tasks that you need to monitor.

There’s a great Red Hat Magazine article showing the basics plus how to set up a .screenrc config file to automatically start sessions or add a status bar to the bottom.

The only other option is to use the nohup command but this does not allow for monitoring progress of a program.

The main problem is that to install screen I need to first install bootstrap but like many people I’m slightly afraid of bricking my Diskstation.

Maybe I’ll add this to the Synology feature request forum in the meantime.

Diskstation Port 80 not responding

On a related note if I enter the admin pages for my Diskstation and enable https connections then my Diskstation no longer listens on port 80, I’ll have to look into this more when I have the time.

One of the consequences of this is that rsync no longer works without a few tweaks since by default it works over port 22 and expects a password.
To fix this just use the command below and rsync will work without interaction (assuming the key passphrase was left empty).

#  rsync -au -e 'ssh -p 99 -i /home/username/.ssh/id_rsa' /path/to/source HOST:/path/to/destination

Just replace -p 99 with your SSH port and /home/username/.ssh/id_rsa with the location of you private key.

References:

1. http://www.synology.com/enu/forum/viewtopic.php?f=36&t=5475
2. http://fedoranews.org/dowen/sshkeys/

Enable SSH

I won’t cover enabling SSH since there are patches supplied from Synology for this purpose and the process is very simple.
I should mention that it’s a good idea to use the telnet patch to enable telnet so you don’t get locked out if something goes wrong.

Make SSH only accept login using keys

You need to login to your box via SSH and edit the file /etc/ssh/sshd_config as shown here to accept keys to log in.

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Also change the following line to prevent passwords being used to log in.

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

While were here we’ll also change the default SSH port from 22 to something else to stop most attacks targeted at port 22. Uncomment the line at the top of the file and change the port number.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 99

Create the Key Pairs

On you host computer (not the diskstation) open a terminal and run the following command, do NOT do this as root.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bobpeers/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa
Your public key has been saved in id_rsa.pub
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX bobpeers@freja

The id-rsa key is you private key and should be kept on the computer you connect from. The id_rsa.pub is the public key that should sit on the server (or servers) that you wish to connect to. If you choose a passphrase you will be prompted for that on login so if you wish to use automated scripts you should not use a passphrase.

The public key needs to be copied to the Disk Station. Back in the SSH terminal:

# cd /root
mkdir .ssh
touch .ssh/authorized_keys
vi .ssh/authorized_keys

Since scp is not enabled you cannot just copy the key so we need to open the id_rsa.pub file on the host, copy the contents and paste them into the file on the Disk Station (in a terminal paste is ctrl + shift + v).

Edit the file permissions

On the Disk Station we need to secure the authorized_keys file, in the SSH terminal type:

chmod 700 .ssh
chmod 644 .ssh/authorized_keys

Reboot and login

Reboot the Disk Station (type reboot in the SSH terminal, this will of course kill your session). Next on the host computer login in again but if you old login was:

$ ssh root@123.4.5.6

You should now use:

$ ssh root@123.4.5.6 -p 99

Where -p 99 is the port you used for SSH in the sshd_config file. You should now login to the Disk Station using your passphrase, if you chose one, or else you will be immediately logged in if you used an empty passphrase.