WordPress Dashboard weiß und unbenutzbar

Posted on by

Ich habe einige weitere Blogs, um die ich mich leider viel zu selten kümmere. Als ich neulich einen dieser anderen Blogs als Administrator öffnen wollte, war das Dashboard komplett weiss und nicht bedienbar – nur die linke Menüleiste wurde angezeigt. Der HTML-Quelltext zur Seite zeigte ganz unten einen PHP-Fehler an:

Fatal error: Access to undeclared static property: WP_Screen::$this in blog/wp-admin/includes/screen.php on line 706

Ein Blick in die entsprechende Datei zeigt tatsächlich die wirklich seltsame und bemängelte Konstruktion (aus statischer Klassenreferenz mit $this), die zumindest mit PHP 5.4 nicht mehr kompatibel ist. (Nebenbei: Eine Redefinition und Nutzung von $this als statische Variable einer Klasse war schon vor PHP 5.4 falsch bis gefährlich. Dass PHP 5.3 umgekehrt die Verwendung von $this mit statischen Variablen in der Form $this::$var erlaubt, hat damit nichts zu tun. Na ja – auch WordPress-Entwickler machen wohl ab zu Fehler, bei denen man sich fragt, wie man überhaupt auf so ein Statement kommen konnte … )

Bei meinem Web-Hosting-Provider hatte ich tatsächlich vor einiger Zeit tatsächlich die Nutzung von PHP 5.4 als Standard eingestellt. Meine WordPress-Version war zudem auch schon ein wenig alt – eine 3.3.x-Version. Im Internet findet man aber die Beschreibung eines unbrauchbaren Dashboards aber auch für 3.8 Upgrades. Dort war das Statement in der screen.php strukturell ähnlich verbockt:

Fatal error: Access to undeclared static property: self::$this in blog/wp-admin/includes/screen.php on line 706

Wir kommt man nun wieder zu einem benutzbaren WordPress?

Die eine Variante ist, alle WordPress Dateien auf dem Server manuell upzudaten. Dabei muss man aber einige Konfigurationsdateien unbedingt unangetastet lassen. Ferner läuft man Gefahr, dass auch ein Datenbank-Update erforderlich wird, das nach einem reinen Austausch der Dateien aber nicht unbedingt automatisch angestoßen wird. (Vor einem manuellen Update in jedem Fall Backups aller Dateien UND der Datenbank machen!)

Will man sich – wie ich – solchen Risiken nicht aussetzen, muss man das fehlerhafte PHP Statement selbst korrigieren. [Bestätigt darin haben mich zwei Forumsbeiträge, deren Links ich weiter unten angebe.] Also die Datei “wpadmin/includes/screen.php” per FTP vom Server herunterladen und in Zeile 706 (oder für welche Zeile der Fehler sonst gemeldet wurde) editieren und in den Statements

“WP_screen::$this->_help_sidebar”
bzw.
“self::$this->_help_sidebar”

die Kassenreferenz vor dem “$this” entfernen, so dass nur

$this->_help_sidebar

übrigbleibt. Unmittelbar nachfolgende Strichpunkte oder anderen Code unverändert lassen. Danach die Datei wieder auf den Server laden.

Im Anschluss wurde bei mir das Dashboard wieder nutzbar und ich konnte das Upgrade auf Version 4 wie gewohnt durchführen. Danach funktionierte alles wieder normal. Viel Spass weiterhin mit euren WordPress-Blogs!

Links zu dem WordPress-Fehler:
http://wordpress.stackexchange.com/questions/127427/how-to-fix-empty-dashboard-issue-in-wordpress
https://wordpress.org/support/topic/38-update-now-all-dashboard-pages-blank

Links zu $this, self:: und statischen Variablen in PHP:
http://de.wikibooks.org/wiki/Websiteentwicklung:_PHP:_Statische_Eigenschaften_und_Methoden
http://stackoverflow.com/questions/151969/when-to-
use-self-vs-this
http://www.programmerinterview.com/index.php/php-questions/php-self-vs-this/
http://www.diffen.com/difference/self_%28PHP%29_vs_this_%28PHP%29
http://php.net/manual/de/language.oop5.static.php
und komplexer mit dynamischen Klassennamen:
http://stackoverflow.com/questions/675676/access-a-static-variable-by-varreference

vsftp – temporary FTP access for a defined list of users

Posted on by

We adminster Opensuse servers for some of our customers at server hosters – e.g. at Strato, a Telekom subsidiary. Sometimes some web server files have to be upgraded either by us or by specific users of the customer. But only sometimes. Under normal operative conditions the FTP access to the server shall not be allowed.

To enable a FTP service we have installed “vsftp”. We further want the FTP users of our customers not to be able to access a shell on the server and restrict their FTP access to a certain directory. However, some of our own admins shall be able to access other server directories by FTP also.

Some basics of how you may set up and configure a vsftp server on an Opensuse system have already been described in my article
vsftp unter Opensuse 12.2 und 12.3.
The basic settings are valid for Opensuse 13.1, too. The settings discussed in the named article already restricted FTP users to a specific directory.

Sporadic FTP access

We solve the sporadic access requirement as follows:
The firewall on the server blocks all ports (with the exception of a dedicated SSH-Port for certificate based SSH logins and http/https ports) under normal operation conditions. But a trained user at the customer site can open a SSH connection and is allowed to start (but not change) a shell script (running with root rights) that temporarily opens ports for FTP connections for a defined IP (the WAN IP of the customer) to the vsftp server.

A simplified example for such a shell script that manipulates a IP chain called “zugriff” may look like: 

#!/bin/bash
iptables -N zugriff 
iptables -F zugriff 
myip=CUSTOMER_IP_ADDRESS 
iptables -A zugriff -p TCP -s $myip --dport ftp -j ACCEPT
iptables -A zugriff -p TCP -s $myip --dport 62050:62100 -j ACCEPT
iptables -t filter -I INPUT 4 -j zugriff
echo "vsftp port and IP rules were set for : " $myip
systemctl start vsftpd.service
echo "vsftp started"

A related simple stop script would be: 

#!/bin/bash
iptables -F zugriff
iptables -t filter -D INPUT -j zugriff
systemctl stop vsftpd.service
echo "FTP services stopped. FTP ports blocked in firewall."

The choice of the passive vsftp ports (in our example the range between 62050 and 62200) must of course correspond to the passive port settings in the vsftp configuration. Set the following options in the vsftpd.conf file:

pasv_enable=Yes
pasv_max_port=62050
pasv_min_port=62100

You may also combine the script commands given above with further commands to start a time interval after which the ports are blocked automatically again. (To prevent possible harm if your trained customer user forgets to stop the vsftp service manually by the given stop scipt).

Grant FTP access to users of a defined list

The vsftp configuration given in my previous article vsftp unter Opensuse 12.2 und 12.3. allows for the access of all locally defined users on the server. They get chrooted to a defined chroot directory.

Note that the single FTP user discussed in the named article got the shell “/bin/false”. Note further that we did not allow anonymous FTP access.

At our customer several users with different UIDs shall get the right to transfer files to the server. The different UIDs shall give us a chance to distinguish their actions in log protocols. (Note that logging the action of users may require special working contract conditions in Germany).

All of the FTP users become members of a special
group. The main FTP directory – let it e.g. be “/srv/www/htdocs/webs” – which becomes their home dir and to which they are restricted by the vsftpd options

chroot_local_user=YES
local_root=/srv/www/htdocs/webs

– gets group ownership of this special group. In addition the SGID bit is set. All of the customer’s FTP users get the shell “bin/false”.

Now, how to restrict the FTP access to defined users among others (e.g. from our own company) and how to extend the directory access for our own admins?

To restrict FTP access to users of a defined list requires the following options:

userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd.user_list

and a file “/etc/vsftpd.user_list” with just the UIDs of the users you want to rant FTP access – each UID in a separate line. The first option tells the vsftpd daemon that the users enlisted in the file “/etc/vsftpd.user_list” get the FTP access granted and shall not be denied it.

Note 1: I had considerable difficulties with my first userlist file, which I had generated and edited with vi on the server. Probably, I did some mistypes whilst editing… Be sure that your userlist file does not contain any special characters not visible on your terminal and that each UID is followed by a line break! Create the file from scratch if you experience unexplainable difficulties or read errors for the file in you FTP client. See: https://groups.google.com/forum/#!msg/alt-f/jtslOMt5aTA/1TW2kGkvmbkJ

Note 2: The file must be readable to the user running the vsftpd process on the server. On Opensuse systems this is presently “root” or “ftpsecure” – depending a bit on how you start the process. You may change ownership of the file to the user “ftpsecure” and drop the standard readability right for “others” – depending on security conditiosn.

Due to the vsftpd option “chroot_local_user=YES” the users get jailed to a certain directory (in our example to directories below “/srv/www/htdocs/webs”). We may want to circumvent this restriction for our own admins whereas for the customer’s users it shall hold and work. To define such an exception requires further vsftp options:

chroot_list_file=/etc/vsftpd.chroot_list
chroot_list_enable=YES

If “chroot_local_use” is set to “YES” then UIDs given (one per line) in the file “vsftpd.chroot_list” are NOT jailed to a chroot directory. In this case the file “/etc/vsftpd.chroot_list” defines exceptions from the chroot-rule. Note, however, that if you had set

chroot_local_user=NO

the opposite would be true: In this case the file “/etc/vsftpd.chroot_list” defines users to be explicitly jailed!

So, now we have combined all our objectives:
We open FTP access when we need it, we grant access to a list of users with most of them jailed to a certain directory
and we grant access to all directories for selected admins.

Have much fun with vsftp on Opensuse!

Strato-V-Server – Opensuse 13.1 – get colors for the "ls" shell command

Posted on by

Today, I tried to work with a freshly installed Strato-V-Server. I had chosen Opensuse 13.1 (64 Bit) as the operative system. When I used the “ls” command I missed the standard coloring of directories and special files.

Using the “env” command and a comparison with a normal Opensuse 13.1 installation showed that required settings for the “ls” coloring were missing. SuSE normally adds these settings via a script “ls.bash” located in the directory “/etc/profile.d”. However, this file was missing on the Strato server. [The script in turn uses “/usr/bin/dircolors”, which existed on the system.]

You could compensate the lack of coloring by manually adding a line

ls –color=tty

to a local “.bashrc” file. However, this would only give you parts of the SuSE coloring scheme for your shell.

The missing file “ls.bash” is the result of a really minimum Opensuse 13.1 installation provided by Strato on their V-servers. It took me a while to find the right RPM package which installs the required files. It is the RPM aaa_base-extras.

After the installation of this package and a reopening of your shell “env” will show some additional lines that control the “ls” color settings: 

user@hxxxxxx:~> env | grep LS
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
...
...
LS_OPTIONS=-N --color=tty -T 0
user@hxxxxxx:~>

I hope this information will help others who miss the the usual “ls”-coloring on Strato-V-servers, too.

fsck on KVM raw device disks

Posted on by

If you have a small company resource optimization is a must. Therefore, I use KVM virtualization to provide several (virtual) servers on a KVM host. The hard disks are provided as raw devices under the control of the KVM “virtio” driver. My virtual machines have been running very reliably for two years now.

However, some days ago one of the servers – a LAMP server called “vm1” – could not be booted any more. Not even its virtual console displayed any messages – the boot process stopped at the very beginning. I took this as a sign to check for corruptions of the file system. In the case of “vm1” the raw device is located on a LVM partition “/dev/volgrpk/vm1_hd1” of a LVM volume group on the KVM host. The internal structure of this device consists of a SWAP partition plus a data partition. The latter one gets mounted on “/” on the virtual guest server.

Because it was such a long time ago that I had to use fsck on a virtual device I had forgotten that you cannot deal directly with KVM raw devices from the KVM host. My naive trial to use fsck directly produced warnings as the KVM host cannot handle KVM raw image devices : 

kvm-host:~ # fsck /dev/volgrpk/vm1_hd1 
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/volgrp1-vm1_hd1

So, I needed a tool which provides access to the partitions of a KVM raw device with some disk image on it.

kpartx to access partitions on KVM raw devices

The easiest way to access a raw device from the KVM host is to use “kpartx”. For Opensuse a relatively up to date RPM is provided in the Update repository “http://download.opensuse.org/update/13.1/“.

For the usage of kpartx see :
KVM-Host – Mounten “virtueller” Gast-Partitionen aus logischen LVM-Volumes
http://linux.die.net/man/8/kpartx
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Troubleshooting_Xen-Accessing_data_on_guest_disk_image.html

Before you apply kpartx you should have a look at “/proc/partitions/” to be able to distinguish the newly attached virtual partitions later on. In my case I get something like: 

kvm-host:~ # cat /proc/partitions           
major minor  #blocks  name

   8        0 3906228224 sda
   8        1    2088450 sda1
   8        2  104856576 sda2
   8        3  125829112 sda3
   8        4  125837312 sda4
   8        5  104855552 sda5
   8        6  104856576 sda6
   8        7    2096128 sda7
   8        8  629145600 sda8
   8        9  419433472 sda9
   8       10  146809856 sda10
  11        0    1048575 sr0
 253        0  125829120 dm-0
 253        1   62914560 dm-1
 253        2   62914560 dm-2
 253        3   83886080 dm-3
 253        4   41943040 dm-4
 253        5  104857600 dm-5
 253        6  188743680 dm-6
 253        7  104857600 dm-7
  43        0   62914560 nbd0

Now, we first make sure that the KVM guests supposed to use your raw image devices are offline. More precisely: … that any KVM guests using image partitions on the raw device you want to access by kpartx are offline. I avoid sharing or NFS-, SMB-mounting
partitions on raw devices – then it is clear which KVM guests to stop.

To get access to the partitions of a raw device we use kpartx with the option “-a”. In the following example this is shown for for two raw devices used by two different virtual servers: 

kvm-host:~ # kpartx -a /dev/volgrpk/vm1_hd1 
kvm-host:~ # kpartx -a /dev/volgrpk/vm2_hd1 
kvm-host:~ # cat /proc/partitions
major minor  #blocks  name

   8        0 3906228224 sda
   8        1    2088450 sda1
   8        2  104856576 sda2
   8        3  125829112 sda3
   8        4  125837312 sda4
   8        5  104855552 sda5
   8        6  104856576 sda6
   8        7    2096128 sda7
   8        8  629145600 sda8
   8        9  419433472 sda9
   8       10  146809856 sda10
  11        0    1048575 sr0
 253        0  125829120 dm-0
 253        1   62914560 dm-1
 253        2   62914560 dm-2
 253        3   83886080 dm-3
 253        4   41943040 dm-4
 253        5  104857600 dm-5
 253        6  188743680 dm-6
 253        7  104857600 dm-7
  43        0   62914560 nbd0
 253        8    2095104 dm-8
 253        9   60818432 dm-9
 253       10    2095104 dm-10
 253       11   60818432 dm-11
kvm-host:~ # file -s /dev/dm-8
/dev/dm-8: Linux/i386 swap file (new style), version 1 (4K pages), size 523775 pages, no label, UUID=23b50bc8-dbeb-4b2d-be10-75b9f390377e
kvm-host:~ # file -s /dev/dm-9
/dev/dm-9: DOS/MBR boot sector
kvm-host:~ # file -s /dev/dm-10
/dev/dm-10: Linux/i386 swap file (new style), version 1 (4K pages), size 523775 pages, no label, UUID=83220483-e419-42d8-88b6-e6dfe202aebc
kvm-host:~ # file -s /dev/dm-11
/dev/dm-11: DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x3, LBA flag 0x1, 1st sector stage2 0x1448200, GRUB version 0.97
kvm-host:~ #

Clearly four additional partitions dm-8 until dm-11 are recognized. Two of them are SWAP partitions. “/dev/dm-9” and “/dev/dm-11” are data partitions each of which is mounted on “/” on my virtual KVM guest servers.

The dm-9 partition is the relevant one for the planned fsck check, which we now can perform in the usual way: 

kvm-host:~ # <strong>fsck -f  /dev/dm-9</strong>
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/volgrpk-vm1_hd1p2: 444945/3808512 files (0.2% non-contiguous), 14281802/15204352 blocks

By the way: A look into “/dev/mapper” shows the available devices and partitions and their device names automatically provided by kpartx: 

kvm-host:~ # ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Oct 27 07:46 control
....
....
lrwxrwxrwx 1 root root       7 Oct 27 12:09 volgrpk-vm1_hd1 -> ../dm-1
lrwxrwxrwx 1 root root       7 Oct 27 12:10 volgrpk-vm1_hd1_part1 -> ../dm-8
lrwxrwxrwx 1 root root       7 Oct 27 12:21 volgrpk-vm1_hd1_part2 -> ../dm-9
lrwxrwxrwx 1 root root       7 Oct 27 12:10 volgrpk-vm1_hd1p1 -> ../dm-8
lrwxrwxrwx 1 root root       7 Oct 27 12:21 volgrpk-vm1_hd1p2 -> ../dm-9
lrwxrwxrwx 1 root root       7 Oct 27 08:43 volgrpk-vm2_hd1 -> ../dm-2
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1_part1 -> ../dm-10
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1_part2 -> ../dm-11
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1p1 -> ../dm-10
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1p2 -> ../dm-11
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd0 -> ../dm-3
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd1 -> ../dm-4

I omitted some lines and devices in the list
above. The last 2 entries stem from a running virtual IMAP server. Note that one and the same device may be presented with different names. again
Now, we can test our virtual server again by booting it – which in my case worked perfectly …

Before testing the virtual LAMP sever with the repaired file system we should not forget to detach the devices still controlled by kpartx: 

kvm-host:~ # kpartx -d /dev/volgrp1/vm1_hd1 
kvm-host:~ # kpartx -d /dev/volgrp1/vm2_hd1

A look into “/dev/mapper” again shows that the raw image disk devices are still shown. However, the partitions have disappeared. 

kvm-host:~ # ls -l /dev/mapper 
total 0
crw------- 1 root root 10, 236 Oct 27 07:46 control
lrwxrwxrwx 1 root root       7 Oct 27 13:18 volgrpk-vm1_hd1 -> ../dm-1
lrwxrwxrwx 1 root root       7 Oct 27 08:43 volgrpk-vm2_hd1 -> ../dm-2
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd0 -> ../dm-3
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd1 -> ../dm-4

Now, we can test our virtual server (here vm1) by booting it – which worked perfectly in my case …

Hosted Strato server – backups and chained firewall tunneling via SSH and shell

Posted on by

I administer several Linux web servers for partner and customer companies. Most of these servers are V-servers hosted at the German Telekom daughter Strato.

[I have described some reasonable security measures for a Strato server with Opensuse in some articles in this blog. See e.g.:
Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication
Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login
and previous articles referenced there.]

When you work with a hosted server, of course, you want to perform periodic backups. If you – for whatever reasons – do not want to pay for the backup facilities Strato offers, a backup requires that you transfer data from the remote server into your own company network through (encrypted) SSH tunnels. Depending on your specific situation you may wish to create a complete backup or a backup of selected directories on the server. During the backup you want to preserve user-rights and mode settings.

In addition to the topic of creating tunnels across firewalls, the question arises what Linux tool might be convenient to perform the backup task if you work with a shell based connection only. Therefore, I shall briefly discuss what I normally do to perform a manually controlled backup from a hosted Strato server. You can combine the methods described of course with some scripting. The described firewall tunneling by SSH is independent of a specific provider.

Tunneling firewalls with SSH

We presume that our company network has a DMZ with two firewalls – a perimeter firewall “PFW” protecting the DMZ and its hosts against the Internet and one or several inner firewalls “IFW(s)” separating the DMZ from inner network segments. Creating firewall tunnels on the outer and/or inner side of the DMZ is always a critical issue.

Our own backup server system for customer data – let us call it “bup” – is e.g. located in an inner segment of our network. The perimeter firewall “PFW” to the Internet resides on a router and can be configured to forward external WAN ports to ports of special hosts inside the DMZ. Servers inside an inner network segment are allowed to build up SSH connections to hosts in the DMZ across their “IFW(s)”; however the servers in the DMZ are not allowed to initiate SSH connections to the servers in the inner segments. For security reasons we poll data from the servers in the DMZ; we do not forward or push from the DMZ to inner segments. For our scenaio we assume that there is only one inner segment and that we only have to deal with a single “IFW”.

I personally prefer a 2-step process to get the data from the hosted server to the backup destination server “bup”:

  • Step 1: I open a reverse SSH tunnel from a special host “intmid” in our DMZ to the Strato server on the Internet and transfer the data from the Strato server to “intmid”. There, I first of all scan the backup files for viruses and malware.
  • Step 2: Afterwards I stop the reverse tunnel and disallow any incoming connections to “intmid”. I then open a ssh reverse tunnel from my destination server “bup” to “intmid” across the IFW, transfer the files to “bup” and encapsulate them there in an encrypted container.

Some readers may think a 2 step procedure may be exaggerated. If you prefer direct connections from the hosted Strato server to “bup” inside your network you may

  • either use a chain of two reverse SSH tunnels (one tunnel per firewall)
  • or a combination of port forwarding on the “PFW” with
    a reverse tunnel across the “IFW”

Both solutions provide a complete connection from the Strato server to “bup” passing both firewalls of your DMZ. Below I describe both methods briefly.

In both of the following methods we need a reverse SSH tunnel from the backup destination server “bup” (inner segment) to the DMZ host “intmid”. I.e., we export a SSH port of server “bup” temporarily to the host “intmid” in the DMZ. This you may e.g. achieve by entering the command

ssh -R 19999:localhost:22 ssh_user_on_intmid@intmid

at your prompt on host “bup”. The “-R” option triggers the creation of a “reverse” tunnel. Port 19999 is assumed to be unused on “intmid”; port 22 is your local port on “bup” for the SSH daemon sshd. “ssh_user_on_intmid” represents a user for SSH connections on “intmid” with sufficient privileges.

Note: If you just want to build the tunnel in the background without using a terminal or executing remote commands you may use the following combination of options for SSH (instead of a plain “-R”) : ssh -nNTfR …...
Please see the man pages of ssh. These options may be especially helpful when using scripts. So, a more general form of the command could be

ssh -p<sshd port server> -nNTfR <forwarded port server>:localhost:<sshd port local> <username>@<ip server>

Note 1: If and when you really work with background SSH tunnels: Take care not to forget to stop the processes for the background tunnels at the end of your backup operation! In scripts this requires some “pid” determination operations for the running ssh processes.

Note 2: Depending on your sshd configuration you may need to have root rights to build the tunnel.

You can test your reverse tunnel through the inner firewall “IFW” by entering

ssh -p 19999 userid_on_bup@localhost

at the prompt of the “intmid” host. You will of course be asked for the password of a valid user “userid_on_bup” on server “bup” and should then get a prompt on “bup”.

Method 1: Chaining two reverse tunnels

The hosted Strato server allows for a ssh connection on a specific port as this is your only way to work on it. You can use this SSH-connection to build up a reverse tunnel from your DMZ host “intmid” to the Strato server. I.e., the SSH port of your DMZ host shall be exported e.g. as port 19999 on the hosted Strato server. By issuing the following command on “intmid” we tunnel the perimeter firewall “PFW”:

ssh -R 19999:localhost:19999 strato_user@ip_of_your_Strato-server -p 61111

Note: Here we have assumed that the Strato-Server listens on port 61111 as its configured SSH port. (Normally, I change the standard port 22 to a high port number. See:
Strato-V-Server mit Opensuse 12.3 – II – Installation / SSH-Port ändern)

You will of course have to give the password for your “strato_user” on the hosted Strato server before entering the shell there.

Why did we use port 19999 on the DMZ host “intmid”? Because we want to chain the two tunnels – the one from “bup” to “intmid” in the DMZ across firewall “IFW” and the one from “intmid” to our Strato server on the Internet across firewall “PFW” to get a complete encrypted connection from the Strato server to “bup”. Both tunnels “meet” at port 19999 on host “intmid”.

Now, at the prompt of the Strato server you can test the combined (reverse) SSH tunnels by entering

ssh -p 19999 userid_on_bup@localhost

Note: Do not get confused by “localhost” in the command above. You must provide the password for user “userid_on_bup” on the server “bup” (!) inside our inner network segment. Our connected tunnels end up there!

You then should get a prompt for user “user_id_on_bup” on our server “bup”. Ok, we now can successfully tunnel two firewalls at the same time by making use of 2 chained reverse SSH tunnels!

Method 2: Port forwarding on the perimeter firewall

Port forwarding on the perimeter firewall could be an alternative to chaining two tunnels. Having build our obligatory reverse tunnel from “bup” to “intmid” we could in addition change the behavior of our PFW – provided of course that it is configurable. In my case I can establish port forwarding for incoming connections on an some external (WAN) port from a defined IP address on the Internet to a definable port of any host at the other (DMZ) side of the perimeter firewall. E.g I could forward a connection from the Strato server trying to reach the WAN side of the perimeter firewall on port 19999 to port 19999 on “intmid” in the DMZ.

Note: If you really do something like this on your firewall you have to be careful to restrict the forwarding to a defined server on the Internet and to close this firewall hole again after the backup procedure. [It makes no sense here to give commands or details as the configuration procedure varies with the type of firewall used.]

However, for this approach to work with openSSH you in addition have to set a parameter for your sshd configuration in the file “/etc/ssh/sshd_config” on “intmid”:

GatewayPorts yes

Otherwise external hosts will not be allowed to use the reverse tunnel. This setting is somewhat dangerous and you should not forget to change it back.

In this approach we couple (local) port forwarding on the PFW with a reverse tunnel from “bup” to “intmid”. The result is basically the same as with two chained reverse tunnels. However, you have to modify your commands on the Strato server somewhat to use port 19999 at the WAN side of your “PFW”. To test the forwarding plus reverse tunnel on the Strato server you would enter:

ssh userid_on_bup@ip_address_of_your_routers_WAN_interface -p 19999

You have to provide the IP address of the WAN interface of your router. Depending on your DSL provider this may change on a daily basis. So you have to find out what it presently is – e.g by the admin interface of your PFW (router) or by asking an external service (e.g. curl icanhazip.com).

All in all I regard the second method as more complicated and potentially also more dangerous than method 1 – because you must not forget to change and change back your sshd configuration on the DMZ host “intmid” and also to reset your PFW configuration. Therefore, I shall only follow the first approach below.

Use rsync to perform the backup

As we have successfully build up tunnels across our firewalls one may think of using “scp” to perform a backup of the server directories. Actually this is not a good idea if you want to make backups of all server directories including system directories. The reason is:

“scp” follows all symbolic links! At least on Opensuse systems this may lead to infinite loops for certain directories whilst copying!

Therefore it is better to use “tar” or “rsync”. See: http://stackoverflow.com/questions/11030394/is-it-possible-to-make-scp-ignore-symbolic-links-during-copy

Personally, I find “rsync” most convenient. And you can combine it
quite easily with SSH! To use the ports defined for our method 1 (with the two chained reverse SSH tunnels) the right syntax for making a backup of e.g. the directory “/var” would be

rsync -avz -e ‘ssh -p 19999’ /var userid_on_bup@localhost:/backups/bup_strato/server_name/

This command has to be performed on the Strato server. Again: Do not get confused by “localhost” – that’s how SSH tunneling works! The “-a” option of the rsync command means “archive mode”. This preserves the mode and user settings of all files and directories throughout the data copying and performs recursions. “z” leads to a transfer of compressed data which will save you time. “/backups/bup_strato/server_name/” represents an example directory on server “bup” where you want to place the backup files of your special Strato server. Of course you should replace it by your own path on your backup server.

Note 1: You have to issue this commands as root on your Strato server to get access to all of the directories there.
Note 2: Please, note that slash “/” at the end of the directory path on the destination system! And note the missing “/” after the local directory “/var”.
Note 3: Please, note the masking of ‘ssh -p 19999‘ by single quotation marks! [To specify the port by “-p 19999” at the end of the ssh command would not work as you would mix rsync and ssh parameters].
Note 4: The big advantage of rsync naturally is that you only would exchange changed files at the next backup.

Have much fun now with your Strato server and making backups through SSH tunnels!