Schlagwort-Archive: ssh

Reverse ssh tunnel

My ISP started to roll out broken IPv6 for home users, so my services aren’t available from outside anymore. I don’t need a full vpn solution, but sometimes I just want to ssh home to check a file etc. The simplest solution was to create a reverse ssh tunnel. The raspberry pi inside my home network connects to my public server via ssh. Logged in on the server I can connect to a local port and get forwarded to the raspberry. That works for me really well.

Since wifi is a little bit flaky, I need to make sure, that the ssh connection is reopened when there is a connection loss. You can write a very simple script like this and use a cronjob to execute it.

#!/bin/bash

COUNT=$(ps ax | grep 'ssh -Nf -R' | wc -l)

if [ $COUNT -eq 1 ]
then
    echo "No tunnel yet. Creating..."
    ssh -Nf -R LOCALPORT:localhost:PORT user@remote
else
    echo "Tunnel already exists. Aborting."
fi

But I just found out about autossh. Which does the monitoring for you. I tried to get it working with systemd, but without any success. Ideas are welcome.

$ cat /etc/systemd/system/autossh-tunnel.service
[Unit]
Description=reverse ssh tunnel
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=localuser
ExecStart=/usr/bin/autossh -f -M 0 remote -l remoteuser -N -o "ServerliveInterval 60" -o "ServerAliveCountMax 3" -R LOCALPORT:localhost:PORT
ExecStop=/usr/bin/pkill autossh
Restart=always

$ sudo systemctl enable autossh-tunnel.service
$ systemctl start autossh-tunnel.service

Looking at journalctl, I can see the exit but no reason. Executing the command manually works fine.

systemd[1]: Starting reverse ssh tunnel...
systemd[1]: Started reverse ssh tunnel.
autossh[2468]: port set to 0, monitoring disabled
autossh[2474]: starting ssh (count 1)
ssh child pid is 2476
received signal to exit (15)

In the end I modified the bash script to use autossh.

#!/bin/bash

COUNT=$(ps ax | grep 'autossh' | wc -l)

if [ $COUNT -eq 1 ]
then
  echo "No tunnel yet. Creating..."
  /usr/bin/autossh -f -M 0 remote -l remoteuser -N -o "ServerliveInterval 60" -o "ServerAliveCountMax 3" -R LOCALPORT:localhost:PORT
else
  echo "Tunnel already exists. Aborting."
fi

If you have a better solution, let me know.

SSH-Tunnel mit Firefox nutzen

Kurz notiert:

Ich hatte etwas Probleme bei der Verwendung eines aktuellen Firefox mit einem dynamischen SSH Tunnel. Konnte ich in der Vergangenheit etwa mit dem Befehl

ssh -fNCD 4444 remotesshserver

einen SOCKS Proxy auf Port 4444 aufmachen und Firefox einfach auf diesen umlenken, funktioniert dies wohl aktuell(?) nicht mehr. Richte ich den Proxy in den Einstellungen des Browsers ein (localhost, Port 4444, alle Protokolle, SOCKSv5 etc), kann anschließend keine Verbindung aufgebaut werden. Die selben Daten, konfiguriert in FoxyProxy funktionieren allerdings problemlos.

Hilfreich bei der Fehlersuche:

ssh -N -vvv -D 4444 remotesshserver
curl –socks5 127.0.0.1:4444 http://icanhazip.com

QNAP NAS: Volle Festplatte und keine Reaktion mehr

Da ist mir wohl ein Script etwas Amok gelaufen und hat die Festplatten vom Qnap volllaufen lassen. Merkwürdigerweise kann man dann mit so einem Qnap nicht mehr wirklich viel anfangen. Verbindung über das Webinterface oder SSH funktionieren zwar noch, versucht man allerdings Dateien zu löschen, hängt sich das System auf. Die wohl einzige Lösung ist etwas unschön, aber funktioniert.

  • Qnap ausschalten (Stecker ziehen, da shutdown Befehle ignoriert werden)
  • Alle Festplatten ausbauen
  • Qnap einschalten
  • Kurzen und langen Piepton abwarten (kann ca. eine Minute dauern)
  • Alle Festplatten wieder rein
  • Per SSH mit dem NAS verbinden. Benutzer: admin, Passwort: admin. (Das NAS besorgt sich per DHCP eine andere als die konfigurierte IP. Entweder im Log des DHCP-Servers nachschauen oder den QNAP QFinder verwenden)
  • Per SSH: storage_boot_init 2
  • cd /share/MD0_DATA
  • Mit rm einige Dateien löschen
  • reboot

Nach dem Neustart ist das NAS wieder über die konfigurierte IP erreichbar.

QNAP TS419U+ und die Passwortlänge

Wenn man bei Google z.B. nach den Schlagworten „qnap max password length“ sucht, findet man einige Treffer zu Foreneinträgen, in denen sich Besitzer von QNAP Netzwerkspeichern über eine Grenze bei der Passwortlänge ärgern. Anscheinend war es sogar mal so, dass die Firmware, Passwörter, die länger als 16 Zeichen waren, einfach abschnitt ohne den User zu informieren.

(Dieses Vorgehen ist auch schon bei einigen anderen Anbietern aufgefallen. Ich erinnere mich noch an AOL und das Sparkasse Onlinebanking. Allerdings ist das schon einige Jahre her.)

In den offiziellen Foren wird seit langer Zeit (Aus-)Besserung versprochen, jedoch gibt es auch bei der aktuellsten Firmware-Version immer noch ein Limit von 16 Zeichen (siehe Screenshot).

QNAP Passwortlänge

 

Wie es sich für ein NAS gehört, kann man auf das System auch auf andere Art als über das Webinterface zugreifen, z.B. per SSH. Wer allerdings versucht sich hier mit seinem Benutzernamen und 16stelligen Passwort anzumelden, wird sich wundern warum der Login verweigert wird. Angeblich ist das Passwort falsch. Auch im Systemlog des NAS werden die „failed login attempts“ aufgelistet. Nach einiger Fehlersuche ist die Ursache gefunden:

Als Passwort für den SSH-Zugang sind nur die ersten 12 Zeichen gültig! 

Und das 2014! Oh Man. Dokumentiert wird dies natürlich nirgendwo. Jedenfalls habe ich nichts gefunden.

SSH keys nachträglich mit einem Passwort schützen

Hat man sich einmal an die Vorteile von public key Authentifizierung bei einem System gewöhnt, stellt man meist zügig alle anderen Systeme ebenfalls auf diese Art der Authentifizierung um. Möchte man sich von verschiedenen Systemen aus anmelden, muss der eigene private Key auf diese kopiert oder z.B. per USB-Stick mit sich geführt werden. Kommt dieser allerdings in falsche Hände, muss man einen neuen Schlüssel generieren und erneut an alle Systeme verteilen. Zum Schutz des privaten Keys, ist es möglich, diesen mit einem Passwort (besser: Passphrase) zu schützen. Dieses wird benötigt um den Key „freizuschalten“, die eigentliche Anmeldung am entfernten System läuft weiterhin über das public key Verfahren und benötigt kein Passwort.  Für eine einfachere Unterscheidung wird das Kennwort zur Freischaltung deshalb auch als „Passphrase“ und nich als Passwort bezeichnet. Sollte man den privaten Schlüssel bei der Erstellung nicht mit einer Passphrase versehen haben, kann man dies noch nachträglich mit ssh-keygen tun.

[pat@earth ~]$ ssh-keygen -p
Enter file in which the key is (/home/pat/.ssh/id_rsa):  [Enter]
Key has comment ‚/home/pat/.ssh/id_rsa‘
Enter new passphrase (empty for no passphrase):  newSuperSavePassword
Enter same passphrase again:  newSuperSavePassword
Your identification has been saved with the new passphrase.

Quellen:

http://kimmo.suominen.com/docs/ssh/#passwd

http://www.manpagez.com/man/1/ssh-keygen/

Public Key Authentication on OpenWRT using dropbear

OpenWRT is a linux distribution for embedded devices like a router. The installation of OpenWRT on your device instead of the original vendor’s firmware allows you to do some nifty stuff with your router like installing additional software out of openWRT’s own repository.

Although there is a package for the openSSH server available, dropbear is the default choice. To enable password-less ssh access you first need to generate the ssh keys on your client machine if you haven’t already. If you want, you can secure your key by typing in a password, otherwise just press enter.

pat@earth:~$ ssh-keygen

Next you have to transfer your public key (the file ending with .pub) to your openWRT installation.

pat@earth:~$ scp ~/.ssh/id_rsa.pub 192.168.1.1:/tmp/

Replace 192.168.1.1 with the IP of your router. If you changed the Port of your ssh server, you have to define it using the -P parameter like scp -P 4321 etc.

Connect to your router and add the transferred public key file to your authorized_keys. Unlike OpenSSH, Dropbear doesn’t look in .ssh underneath your home directory for the authorized_keys file, so you have to create the file in /etc/dropbear/.

root@router:~# cd /etc/dropbear/
root@router:~# cat /tmp/id_rsa.pub >> authorized_keys
root@router:~# chmod 0600 authorized_keys

Now you should be able to ssh from your client pc to your openWRT device without the need of a password.

Restricted sftp access with rssh and ssh chroot

OpenSSH 4.9 was the first version of the famous daemon that came with an built-in chroot functionality (changelog). Chrooting the sshd and restricting the shell access to a few commands can be a great solution to grant a few users secure access to exchange files. We will use the rssh shell to only allow sftp access for one user, locked to his chrooted home directory. Since it is dangerous to give a user write access to the root of a chroot, you have to create the user’s home directory inside the chroot. In this example /home/ftp will be the chroot and /home/ftp/secftp is the home directory of the user, the place where he finds himself when connecting to the machine.

Install the rssh shell with

$ aptitude install rssh

and adjust the config file for the user secftp to allow sftp access.

$ vim /etc/rssh.conf

user=secftp:027:00010 #user:umask:proto

Then add the new user secftp (with /secftp as home and /usr/bin/rssh as shell) to your system and set a password.

$ useradd -d /secftp -s /usr/bin/rssh -g users secftp
$ passwd secftp

Create the directory and adjust the ownership so secftp can read/write and other group members can read the uploaded files.

$ mkdir -p /home/ftp/secftp
$ chown secftp:users /home/ftp/secftp

Edit your sshd configuration and add the user specific options for your chroot. Don’t forget to add secftp to your AllowUsers (which you should have configured :)).

$ vim /etc/ssh/sshd_config

AllowUsers secftp

Subsystem sftp internal-sftp

Match User secftp
   ChrootDirectory /home/ftp
   AllowTCPForwarding no
   X11Forwarding no
   ForceCommand internal-sftp

Restart the sshd daemon and you should be done.

Sources:
http://www.gossamer-threads.com/lists/openssh/dev/44657
http://hp.kairaven.de/scpsftp/ssh-rssh-sftp.html
http://www.debian-administration.org/articles/590

Using a SSH config file

Create the config file in your .ssh directory if it doesn’t already exist.

touch /home/pat/.ssh/config

Open the file and add your configuration:

Host xmp
HostName example.com
User username
Port 2222

Where Host is the name of the shortcut. You can also add other options like

PubkeyAuthentication yes
PasswordAuthentication no
ServerAliveInterval 25
ServerAliveCountMax 150

or another Host to your configuration. Take a look at the ssh_config manpage for more options.
You can now use your shortcut with

ssh xmp