Schlagwort-Archive: ssh

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