Ubuntu Server 11.04 LTS, snd_intel, Realtek ALC892 und ALSA

Vor ein paar Tagen habe ich Mainboard und CPU beim media pc getauscht. Das neue Board ist ein DH67BL von Intel und hat einen anderen Soundprozessor verbaut. Leider wird dieser vom aktuellen Paket im Repo nicht unterstützt.

Erkannt wird er als:

cat /proc/asound/card0/codec#0  | grep Codec
Codec: Realtek ALC892

 

Hier bzw. hier wird eine Lösung beschrieben.

Kurzfassung:

wget http://files.spacefish.biz/LinuxPkg-5.15rc1.tar.bz2
tar xvfj LinuxPkg-5.15rc1.tar.bz2
cd realtek-linux-audiopack-5.15

Bei Nicht-Ubuntu Systemen soll es wohl reichen, das install skript auszuführen, laut Readme.txt ist die Vorgehensweise etwas anders:

tar xvjf alsa-driver-1.0.23-5.15rc1.tar.bz2
cd alsa-driver-1.0.23
./configure –with-cards=hda-intel
make
sudo make install

Theoretisch kann man auch das install skript ausführen und den Fehler am Ende ignorieren, da es genau das selbe macht. Nach einem Neustart noch im alsamixer alle Kanäle „unmuten“.

Schlankes XBMC unter Ubuntu Server

Zur Installation von Ubuntu gibt es im Netz genügend Quellen und Anleitungen, die jeder an seine eigenen Bedürfnisse (RAID, LVM, Verschlüsselung) anpassen kann. Aus diesem Grund setze ich eine frische Installation voraus. Bei der Installation wurde der Nutzer xbmc angelegt.

1. Netzwerk

Da in diesem Setup auf die Installation einer grafischen Oberfläche wie Gnome oder KDE verzichtet wird, muss die Konfiguration über die Shell und nicht z.B. den Network Manager erfolgen. Im Wiki findet man eine passende Anleitung für die Einrichtung einer WLAN Verbindung mittels wpa_supplicant. Je nach WLAN Chip, kann es nötig sein, Kernelmodule zu laden bzw. zu blacklisten.

Als Beispiel hier die Konfiguration (/etc/network/interfaces) für ein WLAN mit WPA2 Verschlüsselung und fester IP:

auto lo
iface lo inet loopback auto wlan0

iface wlan0 inet static
address 192.168.1.2
gateway 192.168.1.1
dns-nameservers 8.8.8.8
netmask 255.255.255.0
wpa-driver wext
wpa-ssid WLAN
wpa-ap-scan 1
wpa-proto RSN
wpa-pairwise CCMP TKIP
wpa-group CCMP TKIP
wpa-key-mgmt WPA-PSK
wpa-psk _HIER_WPA2_KEY_EINTRAGEN_

 

2. Autologin

Als nächstes wird das automatische Anmelden eingerichtet. Dazu wird rungetty installiert

aptitude install rungetty

und anschließend in der Datei /etc/init/tty1.conf, die Zeile

exec /sbin/getty 38400 tty1

durch die folgende ersetzt

exec /sbin/rungetty –autologin BENUTZERNAME tty1

Dabei natürlich BENUTZERNAME durch euren Benutzer ersetzen. In diesem Kontext also mit xbmc.

 

3. Xorg & nvidia

Installation des Xservers und der proprietären Nvidia Grafiktreiber

aptitude install xorg aptitude install nvidia-current

Evtl. reicht anschließend der Aufruf von

nvidia-xconfig

um eine geeignete Grundkonfiguration für den Xserver zu erstellen.

Hier meine /etc/X11/xorg.conf für eine Geforce GT220 und einen LG 37LH4000 LCD-TV.

Section „ServerLayout“
Identifier     „Prop. Nvidia“
Screen      0  „Screen“ 0 0
EndSection

Section „ServerFlags“
Option      „Xinerama“ „off“
EndSection

Section „Module“
Load    „glx“
EndSection

Section „Monitor“
Identifier  „LG LCD“
Option      „VendorName“ „LG“
Option      „ModelName“ „37LH4000“
Option      „DPMS“ „true“
Option      „PreferredMode“ „1920×1080“
Option      „Position“ „0 0“
Option      „Rotate“ „normal“
Option      „Disable“ „false“
Option      „TargetRefresh“ „50“
Option      „DPI“ „180 x 180“
EndSection

Section „Device“
Identifier  „Geforce GT220“
Driver  „nvidia“
Option  „NoLogo“                „true“
Option  „DynamicTwinView“       „false“
Option  „FlatPanelProperties“   „Scaling = Native“
Option  „ModeValidation“        „NoVesaModes, NoXServerModes“
Option  „ModeDebug“             „true“
Option  „HWCursor“              „false“
EndSection

Section „Screen“
Identifier „Screen“
Device     „Geforce GT220“
Monitor    „LG LCD“
DefaultDepth     24
SubSection „Display“
Depth     24
Modes  „1920x1080_50“ „1920x1080_60_0“ „1920x1080_30“ „1920x1080_25“ „1920x1080_24“  „1920x1080_50i“ „1920x1080_60i“
EndSubSection
EndSection

Section „DRI“
Mode         0666
EndSection

 

4. Sound

Wir verwenden zur Tonausgabe ALSA, diese erfolgt über die onboard Soundkarte, genauer: über den optischen Digitalausgang an einen externen Verstärker. Wer den Ton über hdmi ausgeben möchte, findet hier oder hier evtl. Hilfe.

aptitude install alsa-base alsa-utils
alsamixer

Im Alsamixer alle Spuren am besten ein wenig aufdrehen. Darauf achten, dass unter den Spuren kein MM steht. Das bedeutet, dass die Spur gemutet ist. Zum „laut schalten“ die Spur auswählen und m drücken. Außerdem muss der Benutzer noch zur audio Gruppe hinzugefügt werden. Dies passiert mit

usermod -a -G audio xbmc

 

5. XBMC

Das xbmc Repository hinzufügen

aptitude install python-software-properties
add-apt-repository ppa:team-xbmc/ppa
aptitude update

und anschließend die standalone version von xbmc mit allen Abhängigkeiten installieren

aptitude install xbmc-standalone

Den korrekten Start kann man nun mit

xinit xbmc-standalone

testen. Damit das xbmc zukünftig automatisch gestartet wird, fügen wir die Zeilen

if [ -z „$DISPLAY“ ] && [ $(tty) == /dev/tty1 ]; then
xinit /usr/bin/ck-launch-session /usr/bin/xbmc-standalone
fi

in die Datei .bash_profile ein.

 

6. Fernbedienung mit Lirc

Verwendet wird die HP Media Center Fernbedienung (diese hier), welche von lsusb als

Bus 004 Device 002: ID 0471:0815 Philips eHome Infrared Receiver

erkannt wird. Nach der Installation von lirc mittels

aptitude install lirc

sollte automatisch der Konfigurationsdialog starten. Für die oben genannte Fernbedienung

Windows Media Center Transceivers/Remotes (all)

und

Microsoft Windows Media Center V2 (usb) : Direct TV Receiver

auswählen. Abschließend den lirc daemon noch zum Autostart hinzufügen:

update-rc.d lirc enable default

Im xbmc sollte keine weitere Konfiguration nötig sein.

 

7. Power Management

Das udisks Paket mit allen Abhängigkeiten mittels

aptitude install udisks

installieren und die Datei /var/lib/polkit-1/localauthority/50-local.d/custom-actions.pkla mit dem Inhalt

[Actions for xbmc user]
Identity=unix-user:xbmc
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*
ResultActive=yes

erstellen.

Jetzt nur noch das xbmc selbst einrichten und das war es. Viel Vergnügen!

Quellen:
http://wiki.ubuntuusers.de/autologin
http://wiki.xbmc.org/?title=XBMCbuntu
http://wiki.xbmc.org/index.php?title=HOW-TO_install_XBMC_for_Linux_on_Ubuntu_with_a_minimal_installation,_an_unofficial_Step-by-Step_Guide
http://forum.xbmc.org/showthread.php?t=38804
http://wiki.ubuntuusers.de/lirc
http://wiki.xbmc.org/index.php?title=Ubuntu_Suspend_/_Wake
http://forum.xbmc.org/showthread.php?t=73236
http://www.loggn.de/ubuntu-xbmc-10-0-dharma-pvr-repository/

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/

VPN einrichten mit pptpclient / pptp-linux

Für den Netzzugang über ein virtuelles privates Netz (VPN) gibt es sicherlich eine ganze Menge guter Gründe, einer davon ist z.B. die Überwindung der geobasierten Sperrung von Webseiten à la Youtube („Dieses Video ist in deinem Land nicht verfügbar“). Auf Amerika beschränkte Angebote wie der Streaming Dienst Hulu sind damit in Deutschland nutzbar. Der Anbieter VPN on Demand befindet sich seit einiger Zeit in der Betaphase und ermöglicht einen kostenlosen VPN Zugang. Dazu einfach eine E-Mail mit dem Betreff „vpnod“ an promotion@vpnod.com schicken und kurze Zeit später gibt es die Zugangsdaten per E-Mail.

Als erstes muss der PPTP-Client installiert werden. Unter Arch Linux mittels

[pat@earth ~]$ sudo pacman -S pptpclient

unter Debian und Ubuntu heißt das Paket pptp-linux und wird mittels

[pat@earth ~]$ sudo aptitude install pptp-linux

installiert. Nach der Installation konfigurieren wir eine neue VPN Verbindung, hier im Beispiel von VPN on Demand. Dazu legen wir im Verzeichnis /etc/ppp/peers eine Datei für die neue VPN-Verbindung an und tragen folgendes ein: (Die im folgenden verwendeten Variablen $BENUTZER und $PASSWORT sind natürlich mit den erhaltenen Zugangsdaten zu ersetzen)

[pat@earth ~]$ sudo vim /etc/ppp/peers/vpnod

pty „pptp vpn.vpnod.com –nolaunchpppd“
name $USER
linkname vpnod
remotename vpnod
ipparam vpnod
usepeerdns
require-mppe-128
file /etc/ppp/options.pptp

In der Datei chap-secrets werden nun die Zugangsdaten definiert.

[pat@earth ~]$ sudo vim /etc/ppp/chap-secrets

$BENUTZER vpnod $PASSWORT *

Zum testen starten wir das VPN und setzen die Schnittstelle als Standardgateway, so dass der gesamte Internetverkehr über das VPN läuft. Am besten vorher und nachher diese Seite zur Überprüfung der eigenen IP besuchen. Hinweis: Ab diesem Zeitpunkt wird jeglicher Traffic über das VPN geroutet, d.h. auch E-Mails, Instant Messenger oder andere Anwendungen die auf dem System laufen. Die Daten sind zwar bis zur VPN Gegenstelle verschlüsselt, ab dort ist es allerdings Aufgabe des Anwenders für die Verschlüsselung zu sorgen. Wer dem VPN Anbieter nicht traut (oder leicht zu Paranoia neigt :) ) sollte hier die selben Sicherheitsvorkehrungen wie bei der Nutzung eines öffentlichen WLAN Hotspots, sprich HTTPS/SSL, vornehmen.

[pat@earth ~]$ sudo pon vpnod
[pat@earth ~]$ sudo route add default dev ppp0

Sollte der Verbindungsaufbau scheitern, kann der Aufruf von pon mittels

[pat@earth ~]$ sudo pon vpnod debug dump logfd 2 nodetach

bei der Fehlersuche hilfreich sein.

Zum Abbau der Verbindung, die Route wieder entfernen (sollte poff automatisch machen) und die Verbindung trennen.

[pat@earth ~]$ sudo route del default
[pat@earth ~]$ sudo poff

Klappt alles ohne Probleme, kann man das ganze nun automatisieren. Alle Scripte (*.sh) im Ordner /etc/ppp/if-up.d/ werden automatisch nach dem Aufbau der VPN Verbindung ausgeführt. Da Rounting eine komplexe Sache und ein Post für sich wäre, hier nur beispielhalt ein Script zum routen des gesammten Traffics über das VPN.

pat@earth ~]$ sudo vim /etc/ppp/ip-up.d/10-route.sh

#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1
#VPN=ppp0

route del default ${INTERFACE}
route add default dev ${VPN}

Und erstellen ein weiteres Script, welches nach dem Abbau der VPN Verbindung wieder die richtige Route einträgt.

[pat@earth ~]$ sudo vim /etc/ppp/ip-down.d/10-route.sh
#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1

# Gateway (use ‚route‘ to find out, IP or name)
GATEWAY=192.168.2.1

route del default ${VPN}
route add default gw ${GATEWAY} ${INTERFACE}

Ist der Hostname oder die IP des Gateways nicht bekannt, hilft das Kommando route.

[pat@earth ip-up.d]$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 202 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 202 0 0 eth0

Eine Möglichkeit das Ganze nun automatisch beim Systemstart zu machen, findet man für Arch Linux z.B. hier.

Quellen: http://pptpclient.sourceforge.net

Must-have Firefox Add-ons

Ich wurde vor einiger Zeit gefragt welche Firefox Add-Ons ich verwende und diese Frage möchte ich heute beantworten. Da sich einige Add-Ons nicht exakt einer Kategorie zuordnen lassen, habe ich die Kategorien nur grob eingeteilt.

Allgemein
Adblock Plus – Blockt lästige Werbung und Pop-Ups
NoScript – Selektives Erlauben/Verbieten von Javascript, Java etc. für einzelne Seiten
Omnibar – Integriert die Suchfunktion in die Adresszeile
OptimizeGoogle – Verbessert die Google Suchergebnisse und entfernt Werbung und Spam
Session Manager – Speichert geöffnete Tabs/Fenster und stellt Sie nach einem Absturz wieder her
Tab Preview – Seitenvorschau wenn der Mauszeiger über das Tab fährt
ColorfulTabs – Färbt Tabs in verschiedene Farben und verschafft so Überblick
FaviconizeTab – Verkleinert Tabs auf die Größe der Favicons
Xmarks – Synchronisiert Lesezeichen/Passwörter zwischen mehreren Firefox Installationen
Firefox Sync – Siehe Xmarks
Fast Dial – Miniaturansicht von Lesezeichen als Startseite
FEBE – Sicherung der Firefox Einstellungen, Add-Ons etc.
FlashGot – Downloadmanager
VTzilla – Untersucht download per Rechtsklick auf Viren mit VirusTotal

Entwicklung
Web Developer – Menüleiste mit verschiedenen Tools zur Webentwicklung
ColorZilla – Pipette, ColorPicker etc.
Firebug – Webentwicklungs „suite“
CodeBurner for Firebug – Erweitert Firebug um HTML und CSS Referenzen

Sicherheit / Penetration Testing
Access Me – Testet Lücken im Session Handling
Add N Edit Cookies – Kann Sessions und Cookies hinzufügen/bearbeiten
Fireforce – GET/POST Formular BruteForcer
FoxyProxy Standard – Proxy Manager
FxIF – Zeigt die EXIF Daten in den Bildeigenschaften an
HackBar – Toolbar zur Unterstützung bei der Suche nach SQL Injections
HTTPS-Everywhere – Verwendet automatisch SSL auf vielen Seiten
Live HTTP headers – Zeigt die HTTP Header einer Seite
PassiveRecon – Information Gathering Tool
ShowIP – Zeigt die IP Adresse der aktuellen Seite in der Statusleiste
SQL Inject Me – Testet verschiedene SQL Injection Schwachstellen
Tamper Data – Kann HTTP(S) Header bearbeiten und verfolgen
Wappalyzer – Erkennt die verwendete Software auf einer Webseite
XSS Me – Testet eine Seite auf XSS Schwachstellen

humans.txt

Vor ein paar Tagen bin ich auf die Seite humanstxt.org gestoßen und mir gefällt die Idee.

It’s an initiative for knowing the people behind a website.
It’s a TXT file that contains information about the different people who have contributed to building the website.

„About“ Seite meets robots.txt… oder so ähnlich. Ich finds gut: humans.txt.

UPDATE: Hier gibt es auch ein Plugin für WordPress.

How to install Adobe Air and TweetDeck on Ubuntu 10.10 64Bit

Short tutorial on how to install Adobe Air 2.x and TweetDeck on a 64bit Ubuntu Linux.

  1. Go to http://get.adobe.com/de/air/ and grab the latest 32bit version of Adobe Air, which is 2.5.1 when writing this. Select the .bin version in the dropdown below.
  2. Grab a copy of getlibs from here. (local copy)
  3. Use GDebi to install the .deb or type in a terminal

    sudo dpkg -i getlibs-all.deb

  4. Run getlibs and download the required libraries

    sudo getlibs -l libnss3.so.1d libnssutil3.so.1d libsmime3.so.1d libssl3.so.1d
    libnspr4.so.0d  libplc4.so.0d  libplds4.so.0d libgnome-keyring.so libgnome-keyring.so.0
    libgnome-keyring.so.0.1.1

  5. Run ldconfig to update the necessary links to the shared libraries

    sudo ldconfig

  6. Make the downloaded Adobe Air Installer executable and install Adobe Air

    sudo chmod +x AdobeAIRInstaller.bin
    sudo ./AdobeAIRInstaller.bin

Now the installation of TweetDeck. The default installation path for TweetDeck is in /opt, which suits my preferences. Since the installer needs the right to write to the installation directory (really! :) ), I create a new subfolder and change the ownership of it my user.

  1. Create directory and change ownership

    sudo mkdir /opt/TweetDeck
    sudo chown $USER /opt/TweetDeck

  2. Go to http://www.tweetdeck.com/desktop/, click the „Install TweetDeck“ Button and change the installation path to /opt/TweetDeck. If you don’t have flash installed/enabled, download the .air file from here.
  3. If you’re not running Gnome or KDE, take a look at this small script to make TweetDeck start without error. When you followed this tutorial, you have to make a small change to the script. Replace the line

    DIRNAME=”/opt/TweetDeck/bin”

    with

    DIRNAME=”/opt/TweetDeck/TweetDeck/bin”

  4. Follow me in your fresh installed TweetDeck on 64Bit Ubuntu. :)

Ubuntu 10.10 + Pidgin (libpurple) + ICQ (Oscar) = Fail!

Auch wenn ich der Meinung bin, man sollte lieber das Jabber Protokoll für Instant Messenger nutzen, wie beispielsweise Google es bei Google Talk macht, ist ICQ wohl immer noch in Deutschland am weitesten verbreitet. Gründe für den Wechsel findet man z.B. bei Wikipedia.

Gelegentlich kommt es vor, dass Änderungen am ICQ Protokoll oder an der Infrastruktur vorgenommen werden und sich alternative Clients kurzzeitig nicht anmelden können. Genau das ist wohl dieses Wochenende passiert. Da laut offizieller Pidgin homepage nur Sicherheitsupdates außerhalb des Releasezyklus von Ubuntu angeboten werden, gibt es wohl erstmal keine automatisierte Lösung des Problems. In diversen Foren gibt es mittlerweile verschiedene Lösungen, wobei das Deaktivieren von SSL die einfachste, allerdings auch „unschönste“ Lösung ist, da somit eure Logindaten unverschlüsselt übertragen werden. Am sinnvollsten erscheint mir da die Installation des pidgin ppa und Aktualisierung auf das neuste Release.

Vorgehensweise:

  • Installer paket herunterladen: Pidgin PPA Package
  • Rechtsklick auf die Datei und „Mit GDebi Paket-Installationsprogramm öffnen“ auswählen
  • Rechts auf den Button „Paket installieren“ klicken
  • Nach der Installation die Aktualisierungsverwaltung öffnen (Unter xfce: Startmenü -> System)
  • Auf Aktualisierungen überprüfen und anschließend installieren
  • Pidgin neustarten und die Einstellungen für das ICQ Konto öffnen (Konten -> ICQ -> Konto bearbeiten)
  • Auf dem Reiter Erweitert den Server auf slogin.icq.com ändern und ein Häkchen bei „Benutze SSL“ und „clientLogin benutzen“ setzen

Danach sollte die Anmeldung am ICQ Server auch über SSL wieder funktionieren. Außerdem bekommt ihr durch die PPA Installation jetzt immer die neuste Version von Pidgin bequem über die Aktualisierungsverwaltung.

How to use the Twitter API with PHP and OAuth (single user)

Since a few months, applications have to use OAuth to authenticate a Twitter account using the REST API. If you want to write a php application for just one account (like your own small webclient), you don’t have to go the „ping-pong“ way of authentication. You only need this to authenticate different users and as we only need access for one single user, it is possible to simplify the oauth authentication step. Nevertheless I find it much more comfortable to you a finished library. In this example we will use Abraham Williams‘ awesome TwitterOAuth library for PHP, which requires a minimum PHP version of 5.2.x, cURL and OpenSSL.

First you have to visit http://dev.twitter.com/apps an register a new application. Choose „Browser“ as application type and set the default access level to „Read & Write“. You will need the printed „Consumer key“ and „Consumer secret“ in the next step. Also you will need the „Access Token (oauth_token)“ and „Access Token Secret (oauth_token_secret)“, which can be found under „My Access Token“ in the right menu.

Include the library in your PHP script. Change the path accordingly.

require_once(‚twitteroauth/twitteroauth.php‘);

Open your config file and define the 4 needed keys like:

define(‚CONSUMER_KEY‘, ‚aAaAaAaAaAaAaAaAaAaA‘);
define(‚CONSUMER_SECRET‘, ‚bBbBbBbBbBbBbBbBbBbB‘);
define(‚OAUTH_TOKEN‘, ‚cCcCcCcCcCcCcCcCcCcC‘);
define(‚OAUTH_TOKEN_SECRET‘, ‚dDdDdDdDdDdDdDdDdDdD‘);

To connect to Twitter, add in your PHP script:

$twitter = new TwitterOAuth (CONSUMER_KEY, CONSUMER_SECRET, OAUTH_TOKEN, OAUTH_TOKEN_SECRET);

You can now use the $twitter object to interact with the Twitter API. For example fetch your user information or post an update.

$twitter->get(‚account/verify_credentials‘);
$twitter->post(„statuses/update“, array(„status'“=> „First tweet using my own Twitter app!“));

Check out the TwitterOAuth documentation for more options and the Twitter documentation for available ressources.

I hope this small guide helps you getting started and I would love to see some of your results. Questions? Comments!

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.