Dotaz: Dropbear SSH server a klíče

[MilanC]

Ahoj,

jsem trochu zmatený, třeba mi někdo okáže poradit. Snažím se rozjet SSH server na jednom routeru, na doporučení jsem zvolil právě dropbear v poslední verzi.

Mám ho vypřekládaný a na cílové platformě je možné jej spustit. Podle dokumentace by měl podporovat SSH2.

Dotazy:

- aby se uživatel mohl ověřit klíčem, musí mít jeho uživatel v systému nastaveno heslo nebo může být i prázdné? + musí mít nějaký shell.
- dropbear využívá nějaký vlastní (binární) formát pro klíče. Lze sice převádět přes dropbearconvert do formátu openssh a naopak, ale klíče v openssh formátu nativně načíst neumí?
- pokud si vygeneruji klíče přes /bin/dropbearkey -t rsa -f id_rsa -s 4096 > id_rsa.pub, tak v komentáři je ssh1!!! Proč?
- pokud si vygeneruji klíče třeba přes puttygen, tak mi je ten konverzní nástroj nebere pro převod do binárního tvaru.
- pokud si vygeneruji klíče přes ssh-keygen -t rsa -b 4096, tak tyto pak převést lze, ale stejně autorizace selže.
- nerozumím tomu, proč dropbear server musím spouštět s odkazem na privátní klíč. Ano je mi jasné, že z PK lze odvodit public klíč. Nějak žiju v tom, že pro zprovoznění SSH přes klíče dám do putty daný PK a na cílový stroj vložím public klíč do authorized_keys, a to by mělo stačit ne? Dropbear ale při startu vyžaduje jako parametr odkaz na soubor s privátním klíčem.
- ve většině návodů na dropbear generují souběžně rsa i dsa klíče. Má to nějaký důvod?

Jsem z toho popravdě nějaký zmatený, tak budu rád, pokud někdo poradí a trochu se mi to vyjasní. Děkuji.

Odpovědi

[MilanC]

Případně můžete doporučit nějaký jiný SSH server pro embedded linux, ideálně s minimem závislostí apod.

[Jendа]

- pokud si vygeneruji klíče třeba přes puttygen, tak mi je ten konverzní nástroj nebere pro převod do binárního tvaru.

Klíče z Putty se převedou do openssh tvaru smazáním hlavičky a patičky, smazáním nových řádků, doplněním "ssh-rsa " na začátek a volitelně doplněním komentáře, čímž to převedeš na následující případ.

- pokud si vygeneruji klíče přes ssh-keygen -t rsa -b 4096, tak tyto pak převést lze, ale stejně autorizace selže.

Mně v authorized_keys na OpenWRT s dropbearem fungují normálně openssh klíče. Převádět bylo podle mě potřeba jen privátní.

- nerozumím tomu, proč dropbear server musím spouštět s odkazem na privátní klíč

Jedná se o klíč, kterým se prokazuje server. Je to přesně stejné jako /etc/ssh/ssh_host_rsa_key u openssh. Je to klíč který by neměl opustit server (pokud má dost výkonu na to aby si ho vygeneroval sám), s klientským klíčem to nemá nic společného a klientský soukromý klíč se samozřejmě nikam z klienta nenahrává.

- ve většině návodů na dropbear generují souběžně rsa i dsa klíče. Má to nějaký důvod?

Historicky se používalo (i) dsa, ale to už je pasé.

[MilanC]

Jestli se mohu zeptat, kde authorized_keys máte uložený? v uživateli pod dropbear či ./ssh/ podadresářem nebo /etc/dropbear?

Já ať zkouším všemožné, pořád končím takto (se souborem PK ve formátu https://snipboard.io/A7Bv8T.jpg):

Unable to use key file "D:\router2.pk" (OpenSSH SSH-2 private key (old PEM format))
Using username "root".
root@192.168.1.254's password:

případně takto (se souborem PK ve formátu https://snipboard.io/G3Rf7Z.jpg):

Using username "root".
Server refused our key
root@192.168.1.254's password:

Díky.

[pavele]

Adresář .ssh musí mít práva 700 a samotný klíč práva 600.

Klíč uživatele by měl vypadat asi takto:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,DF72390EE088094E

j5pX6047vcx4YBSZ2kSjc3RG2Qvvr7z4Vk7QTjezauTjLvPOjTLOkW/5UbqT5EXI
L1tpD2WmDXccOuCD+HpTAUfa0goKgWhLt8a0AbGn09L14LkKTOEwAYN0HRt8rshD
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END RSA PRIVATE KEY-----

[Jendа]

/etc/dropbear/authorized_keys

Jinak odkud je to načítá by šlo zjistit třeba strace.

[MilanC]

Ano tak to mám původně. Ale pro jistotu jsem teď ještě zkopíroval do /root/.ssh/authorized_keys. (/root je symlink do /var/root ramdisku) Všude radí něco jiného. Nicméně veškerá možnost logování je skoro žádná, nebo to na tom embedded linuxu prostě zatím neumím.

Po zkopírování do /root/.ssh mi to začalo řvát na chybějící /var/log/wtmp, který jsem ručně založil. Ale stejně pak končím na chown/chmod. A z výpisu mám dojem, že se stejně autorizuji heslem, ale toteď neřeším, můžu to na tom klidně ladit dál.

[1860] Jun 04 20:23:00 Child connection from 192.168.1.14:18071
[1860] Jun 04 20:23:01 Auth succeeded with blank password for 'root' from 192.168.1.14:18071
[1860] Jun 04 20:23:01 Exit (root) from <192.168.1.14:18071>: chmod(/dev/ttyp0, 0622) failed: Read-only file system
[1860] Jun 04 20:23:01 wtmp_write: problem writing /var/log/wtmp: No such file or directory
[1860] Jun 04 20:23:01 chown /dev/ttyp0 0 0 failed: Read-only file system
[1860] Jun 04 20:23:01 chmod /dev/ttyp0 0666 failed: Read-only file system
[1861] Jun 04 20:23:21 Child connection from 192.168.1.14:18074
[1861] Jun 04 20:23:22 Auth succeeded with blank password for 'root' from 192.168.1.14:18074
[1861] Jun 04 20:23:22 Exit (root) from <192.168.1.14:18074>: chmod(/dev/ttyp0, 0622) failed: Read-only file system
[1861] Jun 04 20:23:22 wtmp_write: problem writing /var/log/wtmp: No such file or directory
[1861] Jun 04 20:23:22 chown /dev/ttyp0 0 0 failed: Read-only file system
[1861] Jun 04 20:23:22 chmod /dev/ttyp0 0666 failed: Read-only file system

[MilanC]

Tak jsem se posunul. Potíž dělal opravdu read-only /dev/, kde si nemohl vytvořit potřebný terminál.

Řešení: Udělal jsem úpravu mého image, tak, že po startu nahradím /dev čistým tmpfs a znovu do něj dev vygeneruji přes mdev. Neobešlo se to bez nějakých změn v kernelu a busyboxu...

echo /bin/mdev > /proc/sys/kernel/hotplug
mount -t tmpfs mdev /dev
mdev -s
mkdir /dev/pts

Pořád se mi ale nedaří s těmi klíči. Už jsem si tam přidal strace a podle výpisu tak nějak tuším proč. On doplňuje do cesty domovský adresář uživatele (root), ale v mém případě ho mám prázdný.

[pid  1426] stat64("/", {st_mode=S_IFDIR|0755, st_size=197, ...}) = 0
[pid  1426] stat64("//.ssh", 0x7fe79730) = -1 ENOENT (No such file or directory)

viz open_known_hosts_file (cli-kex.c)

Zkoušel jsem i exportnout proměnnou HOME do překladu, ale žádný rozdíl. Jinak known_hosts mám i v /etc/dropbear, ale tam to evidentně nehledá (za což asi může spouštění s -r /var/dropbear/id_rsa).

[Filip Jirsák]

aby se uživatel mohl ověřit klíčem, musí mít jeho uživatel v systému nastaveno heslo nebo může být i prázdné?

Heslo může být prázdné. Ale účet nesmí být uzamčen/zakázán.

nerozumím tomu, proč dropbear server musím spouštět s odkazem na privátní klíč. Ano je mi jasné, že z PK lze odvodit public klíč. Nějak žiju v tom, že pro zprovoznění SSH přes klíče dám do putty daný PK a na cílový stroj vložím public klíč do authorized_keys, a to by mělo stačit ne? Dropbear ale při startu vyžaduje jako parametr odkaz na soubor s privátním klíčem.

Myslím, že to bude spíš privátní klíč serveru.

ve většině návodů na dropbear generují souběžně rsa i dsa klíče. Má to nějaký důvod?

Tradice. DSA se používalo pro zpětnou kompatibilitu a prostě se to stále kopíruje do novějších návodů, protože málokoho z autorů těch návodů napadne zamyslet se nad tím a změnit to.

pokud si vygeneruji klíče přes ssh-keygen -t rsa -b 4096, tak tyto pak převést lze, ale stejně autorizace selže

Bez podrobnějších informací, třeba co je v logu, vám těžko někdo poradí.

[MilanC]

Děkuji za odpovědi.

Chápu to tedy tak, že ten klíč/klíčový pár v tom dropbear formátu, který přímo dropbear využívá je tedy serverový a tedy mě vůbec nemusí trápit, že je SSH1? A tedy s tím vygenerovaným uživatelským klíčovým párem nemá nic společného. Ten použiji jako vždy, putty + authorized_keys a může být SSH2 formát?