UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

UNICORN COLLEGE Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE Vývoj SSH klienta pro platformu Android

Autor: Zbyněk Dvorský Vedoucí práce: Mgr. Peter Buchlák, Ph.D. 2015, Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma „Vývoj SSH klienta pro platformu Android“ vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že jsem v souvislosti s jejím vytvořením neporušil autorská práva třetích osob a že jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne ……………..

…….……………………………

Poděkování Děkuji vedoucímu bakalářské práce Mgr. Peteru Buchlákovi, Ph.D., za pomoc při výběru tématu a za rady při zpracování mé bakalářské práce.

0

Vývoj SSH klienta pro platformu Android SSH Client Implementation for Android Platform

1

Abstrakt Práce se zabývá problematikou vývoje SSH klienta na platformě Android a využívá teoretické přenositelnosti kódu ze starších verzí Java SE, konkrétně z verze 1.5. Motivací je navrhnout takovou aplikaci, která by později uměla spolupracovat nejen s vyhotoveným GUI, ale i s jinými aplikacemi. Práce krátce zkoumá i odlišnosti mezi vývojem aplikací určených pro mobilní platformy a aplikací určených především pro stolní počítače. Klíčová slova: SSH, Android, Dalvik, Java SE, přenositelnost kódu, grafické uživatelské rozhraní, terminál

Abstract This Bachelor's Thesis discusses SSH client development for Android platform and at the same time it explores the theoretical possibility of code portability, which was implemented by using an older version of Java SE, in particular version 1.5. The main motivation was to design an application that would be able to cooperate with other applications in future, not just with the GUI implemented by this project. The project shortly discusses differences in development of applications for mobile and desktop platforms. Keywords: SSH, Android, Dalvik, Java SE, code portability, graphical user interface, terminal

2

Obsah 1 Úvod....................................................................................................................................4 2 Architektura platformy Android..........................................................................................6 3 SSH......................................................................................................................................9 3.1 Vrstvy SSH protokolu.....................................................................................................11 3.1.1 Transportní vrstva - Šifrování, integrita, výměna klíčů...............................................11 3.1.2 Vrstva autentizace uživatele........................................................................................12 3.1.3 Vrstva propojení..........................................................................................................13 4 Emulátory terminálu..........................................................................................................15 5 Výzkum terminálových aplikací........................................................................................17 5.1 JuiceSSH........................................................................................................................17 5.1.1 Shrnutí.........................................................................................................................19 5.2 ConnectBot.....................................................................................................................20 5.2.1 Shrnutí.........................................................................................................................21 6 Návrh aplikace...................................................................................................................22 6.1 Uživatelské případy........................................................................................................23 6.1.1 UC1.0 Editace - změna parametrů uložené relace......................................................25 6.1.2 UC1.1 Editace - přidání nové relace do seznamu relací..............................................26 6.1.3 UC1.2 Editace - mazání relace ze seznamu relací.......................................................27 6.1.4 UC2.0 Editace - přidání příkazu do skupiny příkazů..................................................28 6.1.5 UC2.1 Editace - přidání nové skupiny do seznamu příkazů.......................................29 6.1.6 UC2.2 Editace - přejmenování skupiny příkazů.........................................................30 6.1.7 UC2.3 Editace - mazání skupiny příkazů....................................................................31 6.1.8 UC2.4 Editace - mazání příkazu ze skupiny příkazů..................................................32 6.1.9 UC3.0 Přihlášení do vzdáleného systému – rychlou volbou.......................................33 6.1.10 UC3.1 Přihlášení do vzdáleného systému – výběrem relace.....................................34 6.1.11 UC4.0 Práce v terminálu – softwarová klávesnice....................................................35 6.1.12 UC4.1 Práce v terminálu – příkaz ze seznamu..........................................................36 6.1.13 UC5.0 Ukončení relace.............................................................................................37 6.1.14 UC6.0 Ukončení všech relací a celé aplikace...........................................................38 6.2 Návrh grafického rozhraní aplikace...............................................................................39 6.2.1 Volba vývojového prostředí.........................................................................................39 6.2.2 Porovnání vývoje GUI s jinými platformami..............................................................40 6.2.3 Volba Android API......................................................................................................40 6.2.4 Jazyk aplikace..............................................................................................................42 6.2.5 Návrh grafických prvků...............................................................................................43 6.3 Struktura aplikace...........................................................................................................45 6.3.1 Implementace protokolu SSH.....................................................................................45 6.3.2 Vnitřní komunikace.....................................................................................................48 7 Závěr..................................................................................................................................50 8 Seznam použitých zdrojů..................................................................................................51

3

1 Úvod Platforma Android (dále jen „Android“) se v posledních letech stala nejrozšířenějším systémem určeným dnes již nejen pro mobilní zařízení. Android aktuálně pohání stovky miliónů zařízení ve více než 190 zemích světa, každý den je jich aktivováno přes jeden milión. Každý měsíc jeho uživatelé provedou okolo jeden a půl miliardy instalací různorodých aplikací z internetového portálu Google Play1. Jako nejrozšířenější mobilní platforma se logicky stala i poskytovatelem aplikací umožňujících vzdálenou správu výpočetních systémů. Cílem této bakalářské práce je implementace jedné takové aplikace pro vzdálenou správu. Autor nejprve zkoumá již podobný, existující software určený nejen pro mobilní zařízení. Na základě provedeného průzkumu pak navrhuje případy užití, které jsou implementovány. Vlastním smyslem celé práce však není konkurovat existujícím, často profesionálním programům. Spíše se snaží nabídnout aplikaci s maximálně zjednodušenou obsluhou a demonstrovat takové řešení na vyhotoveném prototypu. Na základě průzkumu autor definuje základní uživatelské případy, jež jsou následně implementovány. Vzhledem k tomu, že stěžejním programovacím jazykem platformy, pro níž je tato aplikace vyvíjena, je Java, program je vyvíjen právě v tomto programovacím jazyce. Jak již napovídá samotný název práce, zásadním komunikačním protokolem použitým mezi vyvíjeným klientem a vzdáleným informačním systémem je protokol SSH. Samotná funkcionalita protokolu SSH je nicméně velice rozsáhlé a komplexní téma. Není tedy cílem vyvíjet software, který poskytne funkcionalitu toho protokolu. Pro potřeby této práce bude proveden průzkum již hotových knihoven, jež budou do vyvíjené aplikace integrovány. Tato integrace nám dále poslouží jako základ pro druhý cíl této práce, a tím je průzkum přenositelnosti takového řešení. Jde tedy zejména o přenositelnost mezi implementacemi Java SE a Android, jenž mají společné kořeny v projektu Apache Harmony. Ten si v době uvedení Androidu na trh (říjen roku 2008) kladl za cíl sjednotit různorodé implementace standardů Javy a chtěl je zastřešit jedinou Apache licencí 2. Stačí poznamenat, že 1 Android, the world's most popular mobile platform [online]. Google Inc. [cit. 2015-0102]. Dostupné z URL: 2 Apache Harmony [online]. The Apache Software Foundation. [cit. 2015-01-02]. Dostupné z URL: 4

to byly to právě licenční spory, které projekt v říjnu 2011 v podstatě ukončily. Předtím však ještě stihl unifikovat implementace Javy SE verze 1.5. Základní Java SE 5 knihovny implementované v rámci projektu Harmony využívá Dalvik, první virtuální stroj vyvinutý přímo pro Android. Jde o rozsáhlou podmnožinu tříd ze jmenných prostorů java.* a javax.* 3. Není tedy garantována jeho plná kompatibilita, ale je teoreticky možné, že zdrojový kód, využívající nativní knihovny Java SE 5, bude spustitelný i na Androidu. Tato možnost je zásadní právě při výběru a testování knihovny implementující funkcionalitu protokolu SSH. Vývoj pro mobilní aplikace určené pro Android je specifický i díky použitému virtuálnímu stroji překládajícímu a kompilujícímu zdrojový kód Javy. Proto tato práce kromě jiného krátce porovnává i strukturu Java virtuálních strojů a jejich vliv na způsob, jakým se software pro porovnávané platformy vyvíjí. Struktura této práce bude tedy následující. V první části shrneme poznatky týkající se Androidu. Podrobněji rozebereme strukturu platformy, a zejména již zmíněný Dalvik. Prozkoumáme princip fungování jednotlivých aplikací a způsob, jakým jsou obsluhovány operačním systémem. Dále se podrobněji podíváme na protokol SSH. Shrneme jeho vlastnosti a rozebereme, jak probíhá typická relace protokolu SSH. Podíváme se na funkcionalitu aplikací, které tento protokol využívají, a jaké z toho plynou poznatky pro náš výzkum již existujících knihoven implementujících tento protokol. Následovat bude průzkum dostupných implementací SSH protokolu v Javě a jejich výběr. Ve třetí části se podíváme na aplikace určené nejen pro Android, které nějakým způsobem SSH klienta implementují. Typicky se jedná o emulátory terminálu. Každopádně z tohoto průzkumu potom vychází nejčastější případy užití, které shrneme a použijeme pro naši aplikaci. Navrhneme uživatelské rozhraní a podrobněji popíšeme strukturu aplikace. Budeme se detailněji zabývat přístupem Androidu k vývoji grafického rozhraní a vlastnostmi považovanými z hlediska vývoje za určující. Jak již jsme uvedli, druhým cílem práce je zkoumat přenositelnost námi vyvíjeného softwaru. Z tohoto důvodu budou při návrhu a implementaci explicitně zmiňovány odlišnosti v přístupu k vývoji programů určených pro stabilní výpočetní systémy, typicky pro stolní počítače a servery s instalovaným Java virtuálním strojem. 3 Görason, Anders: Efficient Android Threading. 1st edition. Sebastopol: O'Reilly Media, 2014-05-21. ISBN: 978-1-449-36413-7. Strana 2. 5

2 Architektura platformy Android V době svého vzniku byla platforma Android nazývána „Javou na Linuxu“ 4. Toto označení je však poněkud nepřesné. Přestože jsou oba pojmy hojně zastoupeny v popisu jednotlivých součástí celého systému, ne zcela vystihují

jeho komplexnost. Všechny

komponenty systému jsou uspořádány v pětivrstvém modelu. Následující obrázek ukazuje strukturu platformy.

Obrázek č. 1

Zdroj: Yaghmour, Karim: Inside Android's UI. [online]. Opersys. [cit.2015-01-02]. Dostupné z URL:

4 Drake, J., Fora, P., Lanier, Z., Muller, C., Ridley, S. A., Wichersky, G.: Android Hacker's Handbook. Indianapolis: Wiley&Son, 2014. ISBN: 978-1-118-60864-7. Str. 26. 6

Nejspodnější vrstvu tvoří jádro operačního systému Linux postavené na verzi 2.6. Tvoří předěl implementující abstrakci mezi hardware a vyššími vrstvami software. Pro běžící procesy poskytuje operační systém stejné prostředí tak, jak jej známe ze skupiny systémů vycházejících z Unixu. Jeden ze zásadních rozdílů nicméně nalezneme v přístupu k procesům a jejich vzájemné izolaci. Android sice využívá tradičního paradigmatu uživatelského ID a ID skupin, nevyužívá ovšem tradičního způsobu autentizace pomocí hesla a skupinování souborů. Koncept Androidu dává každému běžícímu procesu jeho vlastní uživatelské ID. To znamená, že místo toho Android používá jakýsi plán jedinečných identifikátorů známých jako Android ID. Část skupiny těchto ID je rezervována pro některé privilegované uživatele a uživatele nezbytné pro běh systému. 5 Pro nás je však důležité vědět, že v konečném důsledku má jakýkoliv proces, kterým je i jakákoliv instalovaná aplikace uživatele, svoje vlastní, jedinečné ID. Toto ID definuje kontext, v němž daná aplikace běží a který tuto aplikaci izoluje od aplikací ostatních již na úrovni operačního systému. To mimo jiné implikuje i poměrně významná omezení v přístupu do souborového systému. V další vrstvě nazývané Android Runtime potom kromě knihoven jádra nalezneme Dalvik VM (VM je anglická zkratka pro „Virtual Machine“, tedy česky „virtuální stroj“) a Zygote daemon, jehož jediným úkolem je spouštění aplikací. Dalo by se říci, že pro každý proces aplikace se vytvoří nová instance Dalviku a kromě jejich spouštění potom Zygote aplikacím zprostředkovává přístup ke knihovnám a třídám jádra. Tato vrstva je základní komponentou, nezbytnou pro běh našeho kódu napsaného v jazyce Java. Pro vývojáře Android aplikací se Dalvik může jevit jako jakýkoliv jiný virtuální stroj kompilující zdrojový kód Javy, ale není tomu tak. Celý vývojový proces vypadá následovně6: 1. Vývojář napíše kód syntakticky shodný s Javou. 2. Zdrojový kód je kompilován do .class souborů. 3. Výsledné .class soubory jsou přeloženy do Dalvik bytecode. 4. Potom jsou všechny soubory zkombinovány do spustitelného (DEX) souboru. Výsledkem celého procesu není Java bytecode, nýbrž Dalvik executable. Dalším faktem, který stojí za zmínku, i když není z pohledu vývoje natolik zajímavým, je register-based 5 Drake, J., Fora, P., Lanier, Z., Muller, C., Ridley, S. A., Wichersky, G.: Android Hacker's Handbook. Indianapolis: Wiley&Son, 2014. ISBN: 978-1-118-60864-7. Str. 27. 6 Drake, J., Fora, P., Lanier, Z., Muller, C., Ridley, S. A., Wichersky, G.: Android Hacker's Handbook. Indianapolis: Wiley&Son, 2014. ISBN: 978-1-118-60864-7. Str. 40. 7

architektura Dalviku. Na rozdíl od stack-based architektury nativních Java virtuálních strojů tedy virtuální registry Dalviku simulují funkcionalitu mikroprocesoru. Pro vývoj je však nejdůležitější třetí a čtvrtá vrstva souhrnně nazývaná Android Application Framework. Jak je patrné z obrázku, kromě již zmíněných knihoven projektu Apache Harmony jsou k dispozici i třídy balíčku android.*. Díky nim má vývojář přístup k systémovým službám Androidu. Některé systémové služby, které jsou důležité i z pohledu cíle této práce, si proto popíšeme: View System. Je důležitý pro tvorbu grafického uživatelského rozhraní. Umožňuje tvorbu jednotlivých grafických prvků jako jsou textová pole, tlačítka, seznamy, přepínače a jejich rozložení do různých grafických schémat (anglicky „layouts“). Activity Manager. Je zodpovědný za životní cyklus jednotlivých aplikací. Řídí jejich start, průběh a ukončení. Notification Manager. Zobrazuje a řídí stavový řádek. Poskytuje upozornění uživatelům a jiným aplikacím. Poslední vrstvou je potom vrstva aplikační. Tato vrstva je odpovědná za interakci s uživateli skrze nainstalované aplikace. Může se jednat o software dodaný se zařízením, nebo nainstalované programy z nějakého on-line obchodu, typicky z play.google.com. V této vrstvě bychom hledali i naši aplikaci, která je cílem této práce.

8

3 SSH SSH je protokol umožňující zabezpečenou komunikaci skrz datovou síť. Je důležité zmínit, že se jedná o server-klient protokol. Jeho zkratka znamená „Secure Shell“, což by se do češtiny dalo přeložit jako „bezpečné prostředí“. To by však bylo spíše matoucí, už jen proto, že „shell“ je ustálený pojem pro prostředí příkazové řádky operačních systémů Unix/Linux. Z tohoto důvodu bude v práci používána pouze anglická zkratka. První verze protokolu nazývaná SSH-1 byla vyvinuta v roce 1995 výzkumníkem Helsinské technické univerzity Tatu Ylönenem ve Finsku v reakci na incident s únikem hesel z univerzitní sítě. Ačkoliv Ylönen vyrobil první verzi produktu SSH1 pouze pro sebe, brzy jeho použitelnost objevila i širší veřejnost a tato první verze se brzy stala natolik populární, že ještě ve stejném roce vznikl první návrh na standardizaci u IETF (Internet Engineering Task Force). Ten však byl spíše jakousi dokumentací odhalující slabiny v implementaci, a logickým důsledkem proto bylo, že v následujícím roce, tedy v roce 1996, byla standardizována nová verze protokolu SSH-2. Protokol SSH-2 je definován dokumenty RFC4251 až RFC4256, které lze najít na stránkách IETF7. V důsledku licenčních omezení protokol SSH-2 ve své době nedosáhl takového rozšíření. Situace se změnila až s příchodem produktu OpenSSH, který byl šířen jako svobodný software a implementoval SSH-2 jakožto součást OpenBSD projektu 8. OpenSSH byl záhy úspěšně implementován na operační systémy Linux, Solaris, AIX, Mac OS X a další operační systémy, díky čemuž se pak rozšířil po celém světě. Produkty postavené na SSH-2 (dále již jen zkráceně „SSH“) jsou neustále vylepšovány a zdokonalovány, existují desítky aplikací šířených buď jako svobodný, nebo jako komerční software 9. V současnosti se jen těžko setkáme s distribucemi operačních systémů založených na jádrech Linuxu nebo Unixu, které by neměly nainstalovaný nějaký SSH produkt.

7 RFC4251, RFC4252, RFC4253, RFC4254, RFC4255, RFC4256 [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: 8 Barret, D., Silverman, E., Byrnes R.: SSH The SecureShell. 2Nd edition, Sebastopol: O'Reilly Media, 2005. 978-0-596-00895-6. Str. 9. 9 Barret, D., Silverman, E., Byrnes R.: SSH The SecureShell. 2Nd edition, Sebastopol: O'Reilly Media, 2005. 978-0-596-00895-6. Str. 10 9

Mezi hlavní rysy a vlastnosti SSH protokolu patří jeho schopnost: - Zabezpečit data díky využití silného šifrování. - Kontrolovat integritu dat a garantovat tak, že data zůstala po cestě od odesílatele k příjemci nezměněna. - Autentizace a autorizace. Schopnost poskytovat garanci identity všech komunikujících stran. Na tomto základě potom protokol řídí přístup k uživatelským účtům na straně serveru. - Předávání (anglicky „forwarding“) a tunelování TCP relací. To se dá vysvětlit jako schopnost protokolu načítat tok dat na nějakém TCP portu, tento tok za běhu šifrovat a již šifrovaný jej na jiném portu (lokálním, nebo vzdáleném) poskytovat. Tunelování se typicky využívá pro šifrování komunikace jiných, nezabezpečených protokolů, jako jsou FTP, TELNET, IMAP atd. Obrázek č. 2 ukazuje jednotlivé vrstvy protokolu, které výše uvedené vlastnosti protokolu poskytují. Jak je z obrázku patrné, SSH vychází z IP modelu OSI a je postavený typicky nad vrstvou TCP, ale může jít i o jiný, spolehlivý datový tok. Obrázek č.2

Zdroj: Getting started with SSH security and configuration [online]. New York: IBM [cit.2015-01-02]. Dostupné z URL:

10

V následujícím textu práce se podrobněji věnujeme jednotlivým vrstvám a explicitně vyjmenováváme vlastnosti, které by SSH klient měl implementovat.

3.1 Vrstvy SSH protokolu 3.1.1 Transportní vrstva10 - Šifrování, integrita, výměna klíčů Přestože jsme v rámci této bakalářské práce neměli v úmyslu zacházet příliš hluboko do technických detailů, z pohledu jejího cíle je přesto nezbytné znát, jaké šifrovací algoritmy a algoritmy pro výměnu klíčů a jaké šifry a musí náš klient implementovat. Pro šifrování uživatelských dat relací umožňuje SSH využít řadu symetrických šifer s minimální délkou klíče 128 bitů. Prostudováním dokumentu RFC425311 však zjistíme, že pouze jedna šifra je explicitně vyžadována a jedna šifra doporučena. Zbytek šifer je volitelný. Vyžadovanou šifrou je 3DES-CBC. Jak její název napovídá, jedná se o tříklíčovou šifru určenou pro šifrování, dešifrování a finální šifrování. Každý klíč musí mít minimální délku 8 byte, což dává celkovou minimální délku klíče 128 bitů. Druhou, doporučenou šifrou je AES-CBC s volitelnou délkou klíče, přičemž jeho minimální délka musí být opět 128 bitů. Integrita dat je chráněna hodnotou „mac“ vloženou do každého datového paketu, typicky TCP relace. Tato hodnota je tvořena pomocí nějaké „hashovací“ funkce vybrané MAC algoritmem určeným po vzájemné výměně sdílených klíčů. Počítá se ze známých hodnot sdíleného klíče, čísla pořadí paketu a ještě nezašifrovaných dat zapouzdřených v paketu. Nezašifrovaná je pak vložena do poslední části datového paketu a je kontrolovaná oběma stranami relace. SSH definuje řadu algoritmů pro určení „hashovací“ funkce, ale jen jeden, HMAC-SHA1, je vyžadován a jeden HMAC-SHA1-96 je doporučen12. Algoritmus výměny šifrovacích klíčů je klíčovou součástí protokolu a definuje způsob, jakým jsou jednotlivé klíče generovány a distribuovány všem účastníkům relace. Vý10 Formální anglický název je SSH-TRANS viz. obrázek č. 2 11 Encryption [online]. Organizace IETF.[cit. 2015-01-02]. Dostupné z URL: 12 Data Integrity [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: 11

sledkem celého procesu je vytvoření jednoho symetrického klíče shodného pro všechny komunikační strany, aniž by tento klíč bylo možné při odposlouchávání relace jakkoliv zachytit. Dokument RFC425313 explicitně vyjmenovává dvě metody, které musí SSH produkty implementovat. Jedná se o DIFFIE-HELLMAN-GROUP1-SHA1 a DIFFIEHELLMAN-GROUP14-SHA1. Bezpečnost tohoto algoritmu je založena na složitosti výpočtu diskrétního logaritmu. Funguje na principu výměny veřejných klíčů a modifikaci klíčů privátních. Poslední částí transportní vrstvy je algoritmus výměny veřejných klíčů. Je definována řada algoritmů, z nichž jeden je vyžadovaný SSH-DSS a jeden doporučený SSHRSA14. RSA využívá složitosti získání součinu dvou prvočísel z nějakého velkého čísla. DSS je založený na problému výpočtu diskrétního logaritmu. Z pohledu autentizace je důležité znát, že veřejné klíče nemusí být před začátkem sestavení spojení žádné stranně komunikace známé. Pro úspěšné propojení zabezpečené relace však musí být veřejné klíče vždy navzájem vyměněny. Důležitou funkcionalitou SSH klienta je udržování databáze již známých veřejných klíčů serverů. To bude jednou ze součástí implementace naší aplikace.

3.1.2 Vrstva autentizace uživatele15 Jak již bylo jednou zmíněno, SSH je klient-server protokol. Znamená to tedy, že klient musí být autentizován a na základě autentizace pak musí být autorizován skrze svůj uživatelský účet tak, aby mohl využívat služeb systému, do něhož se snaží získat přístup. To je úkolem autentizačního protokolu. Ten předpokládá, že je již sestavena transportní vrstva a že server byl též úspěšně autentizován. Existují tři základní metody autentizace uživatele. - Autentizace pomocí veřejných klíčů. Dle SSH standardu musí klient tuto metodu povinně implementovat. Předpokládá, že klient již vlastní předem vytvořený privátní klíč vygenerovaný i s veřejným klíčem, který byl přesunut na server. Časté je přesunutí veřejného klíče bez využití připojení (anglicky „out-of-band“). V takových případech se často využívá jiné, přenosné medium. Pro takto sestavenou relaci není apriori vyžadováno heslo. 13 Key Exchange Methods [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: 14 Public Key Algoritthms [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: 15 Formální anglický název je SSH-USERAUTH viz. obrázek č.2 12

Samotná metoda však tuto možnost připouští díky tomu, že je možné heslem zabezpečit přístup k privátnímu klíči u klienta. Její typické využití najdeme u systémů využívajících automatického připojení, kde není interaktivní komunikace s klientem žádaná. - Autentizace pomocí hesla. Nejvyužívanější způsob připojení v případě, že je uživatel fyzickou osobou. Její nespornou výhodou je přenositelnost samotného hesla, která otevírá možnost připojit se k serveru jakéhokoliv SSH klienta, který zadá správné heslo. Její nespornou nevýhodou je potom možnost kompromitování klienta, slabé heslo a chování uživatele. Z pohledu uživatele vypadá takové připojení následovně. Uživatel zadá nějaký řetězec znaků, které identifikují jeho účet na vzdáleném systému. Zároveň zadá název vzdálené domény (host) a nebo IP adresu s TCP portem (typicky port 22). Jestliže se jedná o první připojení, potom veřejný klíč serveru ještě klientovi není znám a je mu zobrazen tzv. „fingerprint“ tohoto veřejného klíče. Je na uživateli, aby zhodnotil, zda-li patří k serveru, k němuž se připojuje. Ve chvíli, kdy uživatel klíč schválí, je tento uložen na nějakém lokální médiu a je využíván při dalších připojeních, takže uživatel již zadává jen heslo, které je posléze ověřeno serverem. Mohou ovšem nastat situace, kdy je veřejný klíč serveru změněn. Běžně je to příčinou přeinstalování nebo aktualizace klíčových částí operačního systému. Potom je opět potřeba interakce s uživatelem k ověření nového veřejného klíče serveru. Tato část otevírá možnost odposlouchávání spojení pomocí „man-in-the-middle“ útoku. Je postavena na tom, že se útočníkovi nějakým způsobem podařilo získat identitu serveru, což se děje typicky přepsáním DNS záznamů. V případě, že uživatel sestaví spojení, funguje útočník jako prostředník mezi klientem a serverem. Na klientské straně bylo nutné provést pouze jedinou změnu: schválit nový veřejný klíč. Na tomto příkladu byla názorně demonstrována interakce uživatele s klientem a serverem. Kromě autentizace pomocí veřejných klíčů se jedná se o další, zásadní funkcionalitu, kterou by měla naše aplikace taktéž implementovat. - „Host-based“ autentizace. Jedná se spíše o alternativu k již vyjmenovaným metodám. Tato metoda funguje tak, že klient pošle zprávu s podpisem vytvořeným z privátního klíče a tento podpis je posléze na serveru porovnán s klientovým veřejným klíčem. Stejně jako u metody autentizace pomocí veřejných klíčů dále není potřeba interakce s uživatelem. Díky požadavkům na zabezpečení jak klienta tak i serveru je ale vhodná jen v uzavřených, např. firemních sítích pro meziaplikační, automatizovanou komunikaci.

13

3.1.3 Vrstva propojení16 Tato vrstva poskytuje funkčnosti, které uživatel může použít přímo a které pro většinu uživatelů definují SSH. Jedná se typicky o využívání vzdáleného připojení a spouštění příkazů a také transfer souborů. Zejména spouštění příkazů nás bude z pohledu vývoje zajímat nejvíce. Klienti dále SSH běžně používají k přesměrování TCP portů, přesměrováni protokolu X atd. Při detailnějším prozkoumání zjistíme, že jsou na této vrstvě definovány jednak operace související s obsluhou komunikačního kanálu samotného, tak i množina klientských požadavků, ať již globálních, ovlivňujících stav připojení, nebo klientských požadavků specifických pro komunikační kanál. Pro účely naší práce jsou zřejmě nejdůležitější následující požadavky: pty-req, sloužící k vytvoření relace s určeným pseudo terminálem; požadavek shell, jenž na straně serveru spouští shell17 účtu operačního systému, ke kterému byl klient autentizován; a konečně pak požadavek exec, jenž na straně serveru spouští libovolný program. Již dříve jsme v této práci zmiňovali funkcionalitu přenosu souborů. Zde je však nutné připomenout, že tato funkcionalita není SSH protokolem nijak přímo definovaná. Uživatelsky dobře známé příkazy scp18 a sftp19 principiálně fungují tak, že se nejdříve vytvoří bezpečný komunikační kanál pomocí SSH protokolu, přes něj se spustí vzdálený proces pro přenos souborů,20 který od SSH procesu získá komunikační kanál. Přes tento kanál pak oba souborové procesy komunikují. Historicky byl příkaz scp implementován jako první. Jedná se však o jednoduchou rutinu umožňující v jedné relaci jen jednoduché kopírování množiny souborů v jednom směru. Na druhou stanu zrod sftp již umožnil vyvinout plnohodnotné klienty pro vzdálenou správu souborů. Jako příklad může být uveden poměrně rozšířený program pro širokou škálu operačních systému FireFox. 16 Formální anglický název je SSH-CONNECT viz. obrázek č. 2 17 Shell je ustálený anglický název pro prostředí uživatelského rozhraní s příkazovou řádkou operačních systémů založených na jádrech Linux a Unix. Je to předchůdce grafických uživatelských prostředí. 18 scp je příkaz z prostředí operačních systémů na bázi Linux/Unix a v angličtině se jedná o zkratku slovní spojení secure copy („bezpečná kopie“). Slovo secure (česky „bezpečný“) implikuje použití protokolu SSH. 19 sftp je příkaz z prostředí operačních systémů na bázi Linux/Unix a v angličtině se jedná o zkratku slovního spojení secure file transfer protocol. Výraz secure (česky „bezpečný“) implikuje použití protokolu SSH. 20 Anglicky file-transfer agent 14

4 Emulátory terminálu Při popisu SSH protokolu a jeho vrstvy propojení jsme zmínili požadavky pty-req, shell a exec. Jejich iniciováním se provedou základní důležité kroky pro vytvoření relace, která umožňuje na straně klienta spustit jednotlivé příkazy určené vzdálenému serveru (požadavek exec), nebo provádět úkony spojené s činností administrátora systému. Typicky uživatel za pomoci příkazové řádky zjišťuje stav systému, mění jeho konfiguraci atd. K tomu využívá terminál emulátor. K vysvětlení toho pojmu je zapotřebí se trochu vrátit do historie. Prvními počítači byly v 60. letech velké sálové systémy, u kterých interakci zprostředkovávala jednoduchá zařízení nazývaná „terminály“. Z dnešního pohledu se jednalo o jednoduchou hardwarovou konfiguraci klávesnice a monitoru (terminálu), umožňující ovládat počítač příkazovou řádkou. Pozdější vývoj potom přinesl video terminály, jejichž prostřednictvím počítače poskytovaly obsluze významně sofistikovanější a přívětivější prostředí - k ovládání výstupu směrem do terminálu sloužily speciální znaky nazývané escape sequences21. Bylo tak možné terminálu říci, kde má být umístěn kurzor, jakou barvou má být vytištěn každý znak atd. Z této doby existuje celá řada technických specifikací určujících typ terminálu, avšak v dnešní době jejich funkcionalita působí poněkud archaicky a již několik desítek let se v podstatě u dnes běžných výpočetních systémů nepoužívají. Co ovšem zůstává trvalou součástí téměř všech operačních systémů je možnost sestavit vzdálené uživatelské rozhraní příkazové řádky (již jednou zmíněný shell). A jsou to především operační systémy rodin Linux a Unix, které ji natrvalo adoptovaly. Jednou z implementací určených pro vzdálený přístup do systému je dnes de facto nejrozšířenější standard původní specifikace VT100/ANSI, který zůstal nezměněn až do dnešních dní, kterým je VT100 emulátor terminálu. Jedná se o program simulující funkčnost VT100. Je nicméně nutné zmínit, že takovýchto emulátorů existuje celá řada, i když nejsou tolik rozšířené. Později pak vývojáři přicházeli s dalšími a dalšími emulátory, jejichž přímými předchůdci však již nebyly samotné hardwarové terminály, ale spíše jiné aplikace. Jde např. o emulátory Xterm, Tmux a jiné. V případě, že uživatel sestaví pomocí výše vyjmenovaných terminálů relaci se sys21 Jedná se o definovanou množinu sekvencí kódů vždy začínajících znakem 0x1B ze sady ASCII kódů. 15

témem, hovoříme o relaci s pseudo-terminálem22 . Z pohledu naší aplikace je důležité, že SSH bylo navrženo tak, aby umožňovalo přesměrovat standardní shell vstup/výstup směrem k SSH procesu běžícímu na serveru a dále směrem k SSH klientovi, kde běží nějaká emulace terminálu. Tím se vracíme na začátek této kapitoly. Pokud tedy SSH klient sestaví spojení ze serverem, může aplikace, která toto spojení využívá přímo přes klienta, signalizovat žádost o připojení do systému pomocí nějakého emulátoru terminálu, který je pro systém známý. K tomu slouží požadavek pty-req. Požadavek shell potom otevře uživateli přístup do shell vstup/výstupu.

22 Uživatelská relace v systému je potom identifikována jako ptty. V angličtině p zastupuje výraz pseudo a tty je zkratkou pro text input/ouptut environment. V češtině tedy ptty znamená pseudo vstupně-výstupní textové prostředí. 16

5 Výzkum terminálových aplikací23 Jak bylo řečeno v úvodu, existuje řada aplikací pro mobilní zařízení se systémem Android umožňujících vzdálenou správu výpočetních systémů. Důležitým hlediskem při jejich využívání je zejména bezpečnost připojení, a proto se základem pro celou řadu výše zmíněných aplikací stal právě velmi rozšířený SSH protokol nabízející stabilitu, vysokou úroveň zabezpečení a komplexní, propracované metody autentizace a autorizace. Náš výzkum se nebude soustředit jen na aplikace pro Android, ale protože nás zajímá i porovnání s jinými, typicky počítačovými a serverovými platformami, krátce se podíváme i na aplikace určené pro tyto platformy.

5.1 JuiceSSH Problémem řady dnešních SSH terminálových aplikací pro Android je, že nenabízí ovládací a funkční klávesy potřebné ke komunikaci s terminály, a proto se jejich uživatelé neobejdou bez hardwarové klávesnice. Někdy je možné tento problém vyřešit klávesnicí připojenou přes bluetooth24, nicméně se tak ztrácí výhoda mobility této aplikace. Častým problémem je navíc obecně podpora různých bluetooth zařízení. Aplikace JuiceSSH je výjimečná tím, že uživatel k zadávání žádnou zvláštní klávesnici nepotřebuje. JuiceSSH pracuje se standardní klávesnicí Androidu doplněnou o lištu se speciálními znaky a klávesami potřebnými pro komunikaci se servery a správu připojení. Umožňuje však zároveň i práci s bluetoothovou klávesnicí. Tato aplikace kromě jiného nabízí možnost volby velikosti písma pomocí tlačítek pro ovládání hlasitosti a správně interpretuje escape kódy terminálu pro tučné písmo, barvy či zpětného posunu kurzoru. Umožňuje uživateli pracovat s terminálem v podstatě stejným způsobem, jako by s ním pracoval v příslušném programu na stolním počítači. Výchozí nastavení aplikace nabízí standardní barevné rozlišení v podobě šedého textu terminálu na černém pozadí.

23 Ke dni 31. 12. 2014. 24 Standard pro bezdrátovou komunikaci na krátké vzdálenosti. 17

Další velkou výhodou aplikace JuiceSSH je, že je v základním provedení dostupná zdarma, a proto dnes patří mezi nejrozšířenější25 SSH nástroj pro uživatele Androidu s velice pozitivním hodnocením.26 Aplikaci JuiceSSH lze na většinu zařízení se systémem Android stáhnout z obchodu Google Play27. Po stažení aplikace je uživatel vyzván k zadání hesla pro šifrování citlivých informací týkajících se účtu (zejména privátních klíčů, hesel pro přístup k serverům, atd.). Po zadání hesla je již možné začít s nastavováním vlastního připojení. Mezi další možnosti patří nastavení oblíbených připojení (Frequently Used), sdílení připojení s ostatními uživateli (TeamShare), synchronizace údajů o uložených relacích mezi různými přístroji s Androidem prostřednictvím CloudSync,28 nebo vlastní nastavení aplikace. Některé z těchto funkcí jsou nicméně k dispozici pouze u placené verze aplikace. Zakoupením aplikace uživatel získá rozšířenou verzi, která nabízí kromě výše zmíněného např. různé barevné motivy, funkcionalitu přesměrovávání TCP portů, ukládání šifrovaných záloh připojení atd. Ačkoliv se bezesporu jedná o užitečné prvky, je na tomto místě potřeba poznamenat, že sdílení a synchronizace dat směrem do veřejného prostoru internetu není pro opatrnější uživatele zrovna lákavá. Subjektivně spíše přidává jen další vrstvu potencionálních bezpečnostních rizik. Je zde proto dobrý předpoklad, že se většina uživatelů bez těchto služeb obejde. Z hlediska uživatelů je tedy nejdůležitější, že základní, bezplatná verze JuiceSSH je v podstatě plnohodnotně použitelnou aplikací. Vytvořit připojení přes JuiceSSH je poměrně přímočarou záležitostí. Jediným požadavkem na uživatele je přiřadit identitu v podobě uživatelského jména s heslem. Další, alternativní možností je využít metody připojení sdílením veřejného klíče. Neplacená aplikace nicméně neumí generovat klíče sama - je nutné je stáhnout z místa generování a nainstalovat je jak do klienta (privátní klíč), tak i na server (veřejný klíč). JuiceSSH umožňuje připojení k více serverům najednou. Jednotlivá připojení se zobrazují v notifikační liště, na níž je možné přeskakovat mezi aktivními servery, nebo se od serveru odpojit. Obsluha terminálu je také poměrně jednoduchá. Po doteku prstem se na displeji 25 Ke konci roku 2014 přes půl milionu stažení. Informace dostupná v aplikaci obchodu Google Play. 26 JuiceSSH-SSH Client [online]. Google. [cit.2014-12-29]. Dostupné z URL: 27 Aplikace nainstalovaná snad u všech nových přístrojů s Androidem. 28 Anglický název pro distribuované výpočetní systémy. 18

otevře nabídka ovládacích a funkčních kláves. Po dlouhém stisku se pak rozvine nabídka dalších možností: kopírování, vkládání, ukládání tisknutelného přepisu terminálu, či ukládání často používaných příkazů. Tato funkce je zřejmě nejzajímavější. I přes všechny skvělé vlastnosti, kterými se tento de facto profesionální emulátor terminálu pyšní, se stále jedná o běžnou mobilní aplikaci, která má i své neduhy, vyplývající především z požadavku na mobilitu: jsou jimi například nedostatečná velikost obrazovky, absence hardwarové klávesnice a často nestabilní připojení do IP sítě. Proto stále ještě není schopná konkurovat aplikacím vyvinutým pro stolní počítače, a i když to může být poněkud subjektivní předpoklad, je zjevné, že její využitelnost spočívá spíše v provádění rychlých administrátorských úkolů, jakými je například zjišťování stavu hardwarových a softwarových komponent a stavu běžících procesů. Nespornou výhodou JuiceSSH je jeho bezplatné získání vzhledem k jeho přesvědčivým kvalitám. Velmi dobře funguje s jakoukoliv softwarovou klávesnicí systému Android, ale zároveň je kompatibilní s klávesnicemi připojenými přes bluetooth rozhraní. Dnes patří mezi základní nástroje určené pro vzdálenou správu počítačů se systémy Unix a Linux. Aplikace JuiceSSH má několik menších nedostatků. Při každém připojení či odpojení klávesnice připojené přes bluetooth se například otevírá nová terminálová relace. Přestože je možné vrátit se k původní relaci a tuto novou relaci prostě jen zavřít, jedná se o zbytečnou komplikaci. Další nevýhodou je, že aplikace přiřazuje nestandardní funkce klávese, kterou Android používá ke skrytí klávesnice nebo k provedení kroku zpět – místo aby se po stisknutí této klávesy skryla klávesnice, aplikace například zavře relaci. Nejdříve se ovšem uživatele zeptá, zda si přeje, aby relace běžela na pozadí.

5.1.1 Shrnutí JuiceSSH je velice užitečný SSH emulátor terminálu pro Android, který nevyžaduje hardwarovou klávesnici. V současnosti se jedná o jednoho z nejlepších SSH klientů pro Android.

19

5.2 ConnectBot ConnectBot je další velice snadno ovladatelný, všestranný SSH klient s funkcionalitou emulátoru terminálu. Je distribuován pod licencí otevřeného software a zdrojové kódy celého projektu jsou volně dostupné29. Poněkud matoucí je fakt, že se v aplikaci obchodu Google Play objevují dvě různé verze této aplikace. První verze je původní aplikací ConnectBot, jejíž poslední dostupná verze 1.7.1 byla vydána v roce 2010. Její testování nemělo valných výsledků, protože tlačítko pro Menu jednoduše nešlo zobrazit. Ačkoliv bylo možné využít alespoň funkčního připojení, text terminálu neroloval a ve chvíli, kdy bylo dosaženo spodního okraje okna, nešlo již zadávat žádný další text. Druhá aplikace nabízená na Google Play pod názvem ConnectBot-SSH Agent se tváří jako aktualizace původní aplikace opravující funkcionalitu ssh agenta 30. Program má shodný název jako předchozí aplikace, pouze doplněný příponou „(ssh-agent)“. Poslední verze 1.7.1 je z února roku 2013. Tento program o sobě prohlašuje, že je prvním emulátorem terminálu pro platformu Android. Přestože lze v archivních datech projektu najít první záznamy pocházející z července roku 2009, tento fakt nemůžeme s určitostí ověřit. Přesto tento program dosáhl úctyhodného počtu stažení - přes jeden milion.31 ConnectBot stejně jako výše popsaná aplikace JuiceSSH rovněž slouží ke vzdálené správě jakéhokoliv serveru s jakýmkoliv operačním systémem umožňujícím správu pomocí příkazové řádky. Typicky se tedy jedná o operační systémy rodin Linux a Unix. Jeho grafické uživatelské rozhraní je minimalistické, založené na seznamech položek, a podporuje uživatelský vstup formou gest (anglicky „screen gestures“). Vertikální gesta umožňují rolovat v textu terminálu a horizontální gesta slouží k přesunu mezi jednotlivými relacemi. Aplikace dokáže udržovat několik SSH relací najednou, a to i při uvedení aplikace do pozadí. Všechny relace jsou zobrazeny a uloženy v seznamu a při dlouhém doteku se otevře panel nabídek umožňující odpojení, úpravu informací a také nabídka pro přesměrování portů. Po zvolení této nabídky je uživatel vyzván ke stisknutí Menu. Aplikace dále nabídne úpravu typu zdrojového portu a jeho čísla. Díky tomu mohou SSH tunel využívat 29 Je dostupný na URL: 30 Ten je odpovědný za správu privátních klíčů na SSH klientovi. 31 Informace dostupná v aplikaci obchodu Google Play. 20

i jiné lokální programy. Nabídka nastavení oblíbených připojení je také zajímavá. Další významnou funkcionalitou, kterou má tato aplikace implementovanou, je možnost využívání metody připojení přes sdílení veřejného klíče. Aplikace umožňuje pár veřejného a privátního klíče generovat, ať už s heslem nebo bez něj. Původně byla tato aplikace známá tím, že intenzivně využívala hardwarová tlačítka, která s vývojem designu chytrých telefonů úplně vymizela. V současné době implementuje dvě funkční tlačítka, která jsou spojena s kontrolními sekvencemi terminálu přímo na obrazovce. Tato tlačítka se krátce objeví po doteku na obrazovku nad softwarovou klávesnicí. Jedná se o o tlačítka control a escape. Pokud shrneme hlavní výhody této aplikace, je nutné vyzdvihnout především její jednoduchost a přímočarost implementace uživatelského rozhraní. Aplikace je zdarma a její instalace je nenáročná. Lze ji stáhnout z obchodu Google Play (dříve Android Market). Velkou výhodou je možnost použití privátních a veřejných klíčů generovaných lokálně. Největší nevýhodou při používání ConnectBotu je absence správy nejčastěji používaných příkazů. Jak už bylo psáno dříve v hodnocení této aplikace, psaní textu do příkazové řádky na klávesnici telefonu je časově náročné a je obzvlášť obtížné v případě delších příkazů.

5.2.1 Shrnutí Až na ojedinělou aktualizaci z roku 2013 je program z pohledu běžného uživatele neaktualizovaný od října roku 2010. Přesto je možné na stránkách projektu vysledovat, že projekt stále žije a jeho tvůrci jsou aktivní.

21

6 Návrh aplikace Před návrhem celé aplikace a dříve než lze přikročit k podrobnějšímu zpracování uživatelských případů bylo nutné sjednotit požadavky kladené na naši aplikaci. Z obecných požadavků je zjevné, že navrhovaná aplikace bude muset implementovat funkcionalitu SSH klienta a terminálu. Zároveň bude potřeba tuto funkční část nějak spojit s grafickým prostředím Androidu. Kvůli omezení komplexnosti aplikace bude potřeba vybrat opravdu jen nejčastější případy užití. Podívejme se proto tedy nejdříve na případy užití, které tak časté nejsou. Prvním případem je generování páru veřejného a privátního klíče. I když je to relativně užitečná funkce, přece jen se jedná o poněkud odlišnou činnost oproti běžnému používání klienta. Klíče je možné generovat na externích platformách a následně distribuovat. Aplikace by však měla podporovat metodu autentizace pomocí veřejných klíčů. Druhým případem je podpora přesměrování portů. Opět jde o užitečnou funkci SSH klienta umožňující tunelovat datový tok pro jinou aplikaci než tu naši, ovšem její využití není tak časté. Typickým příkladem využití je například zajištění bezpečného připojení nějaké naší aplikace k privátní síti přes síť veřejnou. Výběr funkčností našeho terminálu však nijak neomezuje tuto práci ve zkoumání druhého cíle, jímž je její přenositelnost. Následující tabulka shrnuje požadované poskytované funkcionality32. Z pohledu využití funkčnosti SSH terminálu se jedná o celkem fundamentální požadavky.

Typ

Název

F

Aplikace umožní uživateli připojit se pomocí jména a hesla přímo výběrem rychlého připojení.

F

Aplikace umožní uživateli připojit se výběrem z uložených připojení.

F

Aplikace umožní uživateli přidat, odebrat anebo editovat data uložených připojení.

F

Aplikace umožní uživateli pohybovat se mezi jednotlivýma relacemi.

F

Aplikace umožní uživateli zaslání příkazu do serveru ze seznamu uložených příkazů.

F

Aplikace umožní uživateli přidat, odebrat anebo editovat uložené příkazy.

F

Aplikace umožní uživateli zadávat příkazy ručně v okně terminálu.

32 Dle metodiky FURPS 22

U

Aplikace bude podporovat Android API 3.0 a výše.

U

Otevřené SSH relace budou zůstávat aktivní na pozadí.

U

Bude podporována softwarová klávesnice a její otevření na vyžádání.

U

Otevřená relace se zavře až po explicitním požadavku uživatele.

U

Aplikace se ukončí až po explicitním požadavku uživatele.

6.1 Uživatelské případy Následující část podrobně rozebírá jednotlivé požadavky a člení je do logických kroků, díky kterým uživatel získá požadovanou funkci aplikace. Následující obrázek demonstruje uživatelské případy, které tato aplikace bude zajišťovat. Obrázek č. 3

Zdroj: autor 23

V další části budou jednotlivé uživatelské případy blíže specifikovány. Pro snadnější orientaci budou označeny zkratkou UC33 a očíslovány. Je potřeba upřesnit, že fráze „zvolí opustit“ znamená, že uživatel buď zvolil tlačítko34 „zpět“ anebo „domů“

33 UC je anglická zkratka pro Use Case. Česky tedy uživatelský případ. 34 Tlačítka jsou typická pro design platformy Android. 24

6.1.1 UC1.0

Editace - změna parametrů uložené relace

Popis Umožňuje uživateli editovat některou ze zvolených položek ze seznamu uložených relací. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Základní tok Z-1.

Uživatel

Vybere seznam uložených relací.

Z-2.

Systém

Zobrazí seznam relací.

Z-3.

Uživatel

Vybere položku, kterou si přeje editovat.

Z-4.

Systém

Zobrazí detaily relace.

Z-5

Uživatel

Vybere volbu editace položky.

Z-6.

Systém

Zobrazí detaily relace s možností editace jejich parametrů.

Z-7.

Uživatel

Uloží změny.

Z-8.

Systém

Informuje o uložených změnách a obnoví seznam relací.

Alternativní tok A-1.

Uživatel

Všechny kroky – zvolí opustit, UC končí beze změn v systému.

A-2.

Systém

Krok Z-1. Zjistí, že neexistuje žádný seznam relací. Zobrazí příklad jedné relace. UC pokračuje beze změny.

A-3.

Systém

Krok Z-7. Zjistí, že uživatel nevyplnil jednu z povinných položek. Uživatel je upozorněn a základní tok UC pokračuje beze změny.

A-4.

Systém

Krok Z-8. Zjistí, že se uložení seznamu nezdařilo. Informuje uživatele a UC končí.

25

6.1.2 UC1.1

Editace - přidání nové relace do seznamu relací

Popis Umožňuje uživateli přidat novou relaci do seznamu relací. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu relací. Základní tok Z-1.

Uživatel

Zvolí přidat novou relaci.

Z-2.

Systém

Zobrazí se detaily relace s prázdnými parametry.

Z-3.

Uživatel

Vyplní parametry relace a uloží změny.

Z-4.

Systém

Informuje o uložených změnách a obnoví seznam relací.


Uživatel


A-2.

Systém

Krok Z-3. Zjistí, že uživatel nevyplnil jednu z povinných položek. Uživatel je upozorněn a základní tok UC pokračuje beze změny.

A-3.

Systém


26

6.1.3 UC1.2

Editace - mazání relace ze seznamu relací

Popis Umožňuje uživateli smazat relaci ze seznamu relací. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu relací. Základní tok Z-1.

Uživatel

Vybere seznam uložených relací.

Z-2.

Systém

Zobrazí seznam relací.

Z-3.

Uživatel

Vybere položku, kterou si přeje smazat.

Z-4.

Systém

Zobrazí dotaz, jestli si uživatel opravdu přeje smazat relaci.

Z-5

Uživatel

Potvrdí smazání.

Z-6.

Systém

Smaže záznam, informuje o uložených změnách a obnoví seznam relací.


Uživatel


A-2.

Uživatel

Krok Z-4. Zvolí nesmazat položku. UC končí.

A-3.

Systém


27

6.1.4 UC2.0

Editace - přidání příkazu do skupiny příkazů

Popis Umožňuje uživateli přidat příkaz do seznamu uložených příkazů. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Existuje skupina příkazů, do které chce uživatel příkaz přidat. Základní tok Z-1.

Uživatel

Vybere seznam uložených příkazů.

Z-2.

Systém

Zobrazí seznam uložených příkazů.

Z-3.

Uživatel

Vybere skupinu příkazů, ze které si přeje příkaz editovat.

Z-4.

Systém

Zobrazí skupinu příkazů.

Z-5

Uživatel

Vybere příkaz, který si přeje editovat.

Z-6.

Systém

Zobrazí se příkaz a je možné jej editovat.

Z-7.

Uživatel

Uloží změny.

Z-8.

Systém

Informuje o uložených změnách a obnoví seznam příkazů.


Uživatel


A-2.

Systém

Krok Z-7. Zjistí, že je příkaz je prázdný. Upozorní uživatele a UC pokračuje beze změny.

A-3.

Systém

Krok Z-7. Zjistí, že se uložení seznamu příkazů nezdařilo. Informuje uživatele a UC končí.

28

6.1.5 UC2.1

Editace - přidání nové skupiny do seznamu příkazů

Popis Umožňuje uživateli přidat novou skupinu do seznamu příkazů. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu příkazů. Základní tok Z-1.

Uživatel

Zvolí přidat novou skupinu.

Z-2.

Systém

Zobrazí se prázdný název skupiny.

Z-3.

Uživatel

Vyplní název skupiny a uloží změny.

Z-4.

Systém



Uživatel


A-2.

Systém

Krok Z-3. Zjistí, že uživatel zadal prázdný řetězec. Uživatel je upozorněn a základní tok UC pokračuje beze změny.

A-3.

Systém


29

6.1.6 UC2.2

Editace - přejmenování skupiny příkazů

Popis Umožňuje uživateli přejmenovat skupinu příkazů. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu příkazů. Základní tok Z-1.

Uživatel

Zvolí skupinu příkazů.

Z-2.

Systém

Zobrazí se název skupiny s možností editace.

Z-3.

Uživatel

Změní název skupiny a uloží změny.

Z-4.

Systém



Uživatel


A-2.

Systém

Krok Z-3. Zjistí, že uživatel zadal prázdný řetězec. Uživatel je upozorněn a základní tok UC pokračuje beze změny.

A-3.

Systém


30

6.1.7 UC2.3

Editace - mazání skupiny příkazů

Popis Umožňuje uživateli přejmenovat skupinu příkazů. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu příkazů. Základní tok Z-1.

Uživatel

Zvolí skupinu příkazů, kterou chce vymazat.

Z-2.

Systém

Zobrazí žádost o potvrzení vymazání.

Z-3.

Uživatel

Potvrdí vymazání skupiny.

Z-4.

Systém

Systém uloží změny, informuje o uložených změnách a obnoví seznam příkazů.


Uživatel


A-2.

Systém


31

6.1.8 UC2.4

Editace - mazání příkazu ze skupiny příkazů

Popis Umožňuje uživateli smazat příkaz ze seznamu příkazů. Předpoklady Aplikace je úspěšně spuštěna a běží na popředí. Uživatel zvolil zobrazení seznamu příkazů a zvolil skupinu, ze které chce příkaz smazat. Základní tok Z-1.

Uživatel

Zvolí smazat příkaz.

Z-2.

Systém

Zobrazí žádost o potvrzení vymazání příkazu.

Z-3.

Uživatel

Potvrdí vymazání příkazu.

Z-4.

Systém



Uživatel

Všechny kroky – zvolí opustit, UC končí beze změn v systé mu.

A-2.

Systém


32

6.1.9 UC3.0

Přihlášení do vzdáleného systému – rychlou volbou

Popis Umožňuje uživateli přihlásit se do vzdáleného systému zadáním důležitých parametrů relace, aniž by tato relace byla v aplikaci uložená. Předpoklady Aplikace je úspěšně spuštěna, běží na popředí a zařízení má přístup do IP sítě. Základní tok Z-1.

Uživatel

Vybere ze seznamu akcí přípojení rychlou volbou.

Z-2.

Systém

Zobrazí se detaily relace s prázdnými parametry.

Z-3.

Uživatel

Vyplní parametry nezbytné pro uskutečnění relace a potvrdí.

Z-4.

Systém

Zobrazí „fingerprint“ veřejného klíče.

Z-5

Uživatel

Potvrdí validitu veřejného klíče.

Z-6.

Systém

Uloží veřejný klíč.

Z-7.

Systém

Zobrazí žádost o potvrzení hesla.

Z-8.

Uživatel

Potvrdí heslo.

Z-9.

Systém

Zobrazí prompt vzdálenému systému.


Uživatel


A-2.

Systém

Krok Z-3. Zjistí, že některý z povinných parametrů je prázdný. Upozorní uživatele a UC pokračuje beze změny.

A-3.

Systém

A-4.

Uživatel

A-5.

Systém

A-6.

Uživatel

A-7.

Systém

Krok Z-4. Zjistí, že veřejný klíč je již uložen v databázi veřejných klíčů. Pokračuje v sestavování spojení. UC pokračuje beze změny. Krok Z-5. Nepotvrdí validitu klíče. Systém oznámí ukončení spojení. UC končí. Krok Z-6. Zjistí, že uložení klíče selhalo. Upozorní uživatele. UC pokračuje beze změny. Krok Z-7. Heslo nepotvrdí. Systém oznámí ukončení spojení a UC končí. Krok Z-8. Zjistí, že heslo je neplatné. Zobrazí žádost o zadání hesla. UC pokračuje beze změny.

33

6.1.10 UC3.1

Přihlášení do vzdáleného systému – výběrem relace

Popis Umožňuje uživateli přihlásit se do vzdáleného systému vybráním ze seznamu uložených relací. Předpoklady Aplikace je úspěšně spuštěna, běží na popředí a zařízení má přístup do IP sítě. Základní tok Z-1.

Uživatel

Vybere ze seznamu akcí přípojení výběrem ze seznamu relací.

Z-2.

Systém

Zobrazí se seznam relací.

Z-3.

Uživatel

Vybere relaci a potvrdí žádost o připojení.

Z-4.

Systém

Zobrazí „fingerprint“ veřejného klíče.

Z-5

Uživatel

Potvrdí validitu veřejného klíče.

Z-6.

Systém

Uloží veřejný klíč.

Z-7.

Systém

Zobrazí žádost o potvrzení hesla.

Z-8.

Uživatel

Potvrdí heslo.

Z-9.

Systém

Zobrazí prompt vzdálenému systému.


Uživatel


A-2.

Systém

A-3.

Uživatel

A-4.

Systém

A-5.

Uživatel

A-6.

Systém

Krok Z-4. Zjistí, že veřejný klíč je již uložen v databázi veřejných klíčů. Pokračuje v sestavování spojení. UC pokračuje beze změny. Krok Z-5. Nepotvrdí validitu klíče. Systém oznámí ukončení spojení. UC končí. Krok Z-6. Zjistí, že uložení klíče selhalo. Upozorní uživatele. UC pokračuje beze změny. Krok Z-7. Heslo nepotvrdí. Systém oznámí ukončení spojení a UC končí. Krok Z-8. Zjistí, že heslo je neplatné. Zobrazí žádost o zadání hesla. UC pokračuje beze změny.

34

6.1.11 UC4.0

Práce v terminálu – softwarová klávesnice

Popis Umožňuje uživateli pracovat v prostředí terminálu. Předpoklady Aplikace je úspěšně spuštěna a úspěšně proběhl buď UC3.0 nebo UC3.1. Uživatel je připojený. Základní tok Z-1.

Uživatel

Dotkne se obrazovky aktivního připojení.

Z-2.

Systém

Zobrazí klávesnici.

Z-3.

Uživatel

Zadává znaky.

Z-4.

Systém

Zobrazuje znaky přijímané ze strany serveru.


Uživatel


A-2.

Uživatel

Krok Z-2. Zvolí tlačítko schovat klávesnici. UC končí.

A-3.

Systém

Krok Z-4. Zjistí, připojení se přerušilo. Oznámí to uživateli a UC končí.

35

6.1.12 UC4.1

Práce v terminálu – příkaz ze seznamu

Popis Umožňuje uživateli poslat již předem nachystaný uživatelský vstup. Jedná se o výběr příkazu ze seznamu příkazů. Předpoklady Aplikace je úspěšně spuštěna a úspěšně proběhl buď UC3.0 nebo UC3.1. Uživatel je připojený. Základní tok Z-1.

Uživatel

Dotkne se grafického prvku, který identifikuje aktivní připojení.

Z-2.

Systém

Zobrazí se seznam příkazů.

Z-3.

Uživatel

Vybere příkaz.

Z-4.

Systém

Zobrazí odpověď ze strany serveru.


Uživatel


A-2. A-3.

Systém Systém

Krok Z-2. Nezobrazí žádné uložené příkazy. UC končí. Krok Z-4. Zjistí, že se připojení se přerušilo. Oznámí to uživateli a UC končí.

36

6.1.13 UC5.0

Ukončení relace

Popis Umožňuje uživateli ukončit jednu aktivní nebo neaktivní relaci. Předpoklady Aplikace je úspěšně spuštěna, běží na popředí a úspěšně proběhl buď UC3.0 nebo UC3.1. Uživatel je připojený. Základní tok Z-1.

Uživatel

Dotkne se grafického prvku, který identifikuje aktivní připojení.

Z-2.

Systém

Zobrazí se nabídka pro ukončení relace.

Z-3.

Uživatel

Potvrdí ukončení relace.

Z-4.

Systém

Ukončí relaci, vymaže okno terminálu a grafický prvek identifikující uzavřenou relaci.


Uživatel


37

6.1.14 UC6.0

Ukončení všech relací a celé aplikace

Popis Umožňuje uživateli v jednom kroku ukončit všechny relace a běh aplikace. Předpoklady Aplikace běží na popředí. Základní tok Z-1.

Uživatel

V seznamu aktivit zvolí ukončení celé aplikace.

Z-2.

Systém

Požádá o potvrzení volby.

Z-3.

Uživatel

Potvrdí svou volbu.

Z-4.

Systém

Ukončí všechny aktivní i neaktivní relace a ukončí svůj běh.


Uživatel


A-2.

Uživatel

Krok Z-3. Nepotvrdí ukončení běhu aplikace. UC končí beze změn v systému.

38

6.2 Návrh grafického rozhraní aplikace35 6.2.1 Volba vývojového prostředí Vůbec prvním rozhodnutím při vývoji této aplikace byla volba vývojového prostředí. První seznamování se s platformou Android začalo ještě v době 36, kdy existovala v podstatě jen jedna stabilní, plně funkční a vývojářskou komunitou a společností Google podporovaná možnost, a tou bylo IDE37 Eclipse. Existovala sice alternativa v podobě vývojového prostředí Android Studio od společnosti Google, ale tu bylo v dané době možné hodnotit spíše jako experimentální a nestabilní. Ovšem díky integrovanému nástroji pro úpravu GUI, jeho schopnosti kontrolovat kód a našeptávat se nakonec celý vývoj přesunul právě do tohoto nástroje. Ten v nestabilních verzích studia fungoval poměrně spolehlivě i před vydáním první oficiální verze 8. prosince 201438. Jak bude dále ještě popsáno, návrh GUI je záležitostí spíše statického předpisu uloženého v souborech typu xml. Ten definuje polohu, velikost a jiné neměnné vlastnosti těchto prvků (tvar, barva, pozadí), ať již relativně, nebo také absolutně. To je důležité z toho důvodu, že vývojář testuje veškerý svůj kód buď na emulátoru systému Android, nebo na mobilním přístroji. Otestování však znamená aplikaci nainstalovat a spustit. To v případě např. drobných změn v návrhu znamená značnou ztrátu času. Je potřeba dodat, že konstrukce grafických prvků může probíhat i přímo ve zdrojovém kódu a může být dynamicky měněna za běhu programu. Jak již však bylo vysvětleno výše, opakované testování takto navrženého GUI by však bylo zdlouhavou rutinou a navíc ne všechny statické atributy mají definovanou svoji metodu v kódu.

35 Pro zjednodušení a zlepšení přehlednosti textu bude dále v práci používána anglická zkratka GUI (Graphical User Interface, česky „grafické uživatelské rozhraní“). 36 První polovina roku 2013. 37 IDE je anglická zkratka pro Integrated Development Environment, česky „vývojové prostředí“. 38 Android Tools Project Site [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 39

6.2.2 Porovnání vývoje GUI s jinými platformami Z pohledu dalšího cíle této práce je potřeba v krátkosti porovnat vývoj GUI na Androidu s jinými nástroji a platformami. Protože je jich celá řada, budeme se soustředit jen na ten nejrozšířenější, který vychází z programovacího jazyka Java. Ze světa vývoje určeného zejména pro stolní počítače je asi nejznámější knihovna tříd a komponent Swing určený pro vývoj GUI. Od začátku umožňoval všem programům, které jej využívaly, aby působily unifikovaně a nezávisle na platformě. Programy vypadají v podstatě shodně nehledě na to, zda běží na operačních systémech Linux, nebo Windows. Schémata a umístění grafických elementů jsou potom tvořeny přímo ve zdrojovém kódu Javy. Jako příklad nástroje, v němž lze GUI využívající Swing vyvíjet, je editor WindowBuilder. Bývá součástí vývojového prostředí Eclipse a vývojových prostředí vycházejících z něj. Swing je trvalou součástí Java SE již od verze 1.2 a najdeme jej ve jmenném prostoru, javax.swing. Na platformě Android bychom ho však hledali marně. Oproti standardu Java SE využívajícímu JComponents 39 je totiž uživatelské rozhraní Androidu postaveno na používání objektů View40. Navíc, jak bylo zmíněno v úvodu této práce, každá aplikace na Androidu běží v poměrně limitovaném systémovém prostoru definovaném jako aplikační kontext. Z tohoto důvodu musí být reference na jeho instanci předávána každé grafické komponentě Androidu. Všechny třídy grafických prvků určených pro tvorbu uživatelských rozhraní Androidu bychom hledali zejména ve jmenných prostorech android.view, android.widget a android.graphics. Z výše uvedeného explicitně vyplývá, že zdrojový kód Androidu implementující nějaký grafický prvek neumožňuje přímou přenositelnost na jiné platformy využívající virtuální stroje Java SE. Tento vztah platí samozřejmě i obráceně.

6.2.3 Volba Android API Další zásadní otázkou byl výběr minimální podporované verze API. Nejdříve se podívejme na formální definici API. 39 The Java Tutorials [online]. Organizace Oracle. [cit. 2014-12-11]. Dostupné z URL: 40 Android API, View [online]. Organizace Google. [cit. 2014-12-11]. Dostupné z URL: 40

Úroveň API je vyjádřena jedinečnou číselnou hodnotou, která identifikuje revizi aplikačního rámce nabízeného formou nějaké verze platformy Android. Tato platforma tedy poskytuje nějaký souhrnný aplikační rámec, kterému říkáme API. Ten využívají aplikace při interakci s nižšími úrovněmi systému Android. Tento aplikační rámec se skládá z následujících částí: - množiny balíčků a tříd jádra - množiny XML elementů a atributů, které deklarují soubor manifest - množiny XML elementů a atributů, které deklarují a zpřístupňují zdroje - množiny Intents - množiny oprávnění, která aplikace mohou požadovat, stejně tak jako vynucená oprávnění, která jsou součástí systému.41 Všechny aktualizace API jsou navrženy tak, aby si nová API zachovala kompatibilitu s předchozími verzemi. To znamená, že velká většina změn spočívá pouze v uvedení nových funkčností, nebo v jejich náhradě. Často jsou některé starší části odepisovány42, ale nejsou odstraněny. To implikuje fakt, že všechny funkční částí předchozí verze API jsou přeneseny do verze nové. Přesto se ve velmi malém počtu případů přistupuje k tomu, že se některé části odstraní. Důvodem bývá především zvýšení stability a bezpečnosti platformy. Důvodů, proč nezvolit zrovna nejnovější verzi, je ovšem několik. Ten první, a zřejmě i nejdůležitější, je rozšířenost konkrétní verze mezi uživateli. Zájmem vývojáře totiž je, aby aplikace cílila na co nejširší skupinu uživatelů. A jak implikuje předchozí odstavec, platforma negarantuje zpětnou kompatibilitu, nýbrž pouze dopřednou. Program v nejnovější API nemusí fungovat v té předchozí. Nás však v tuto chvíli zajímá vliv našeho rozhodnutí na implementaci GUI. Výběr nejnižší podporované verze je jakýmsi kompromisem mezi vyžadovanou funkčností a složitostí její implementace. V našem případě by teoreticky mohly hrát roli i tzv. styly a témata 43, která jsou pro každé API specifická. Při bližším prozkoumání bylo však rozhodnuto, že aplikace bude navržena nezávisle na hlavním tématu a stylech jakékoliv API a bude se je snažit překrývat. Při podrobnějším zkoumání se nicméně ukázalo, že by byl rozsah takové práce neadekvátní naší aplikaci. 41 API Guides [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 42 Z anglického slova deprecated. 43 Styles and Themes [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 41

Prvním důležitým objevem týkajícím se naší aplikace byl grafický prvek s názvem Action Bar44, který byl uveden počínaje API 3.0. Jedná se o lištu, typicky umístěnou v horní části obrazovky, která může nést grafické prvky, jako jsou záložky (angl. tabs)45. Ty by reprezentovaly všechny otevřené relace naší aplikace a uživatel by díky tomu mohl mezi relacemi snadno přepínat. Dalším důvodem, proč zvolit API 3.0, bylo uvedení takzvaných fragmentů 46. Tyto třídy představují jakousi podmnožinu téměř analogicky vypadajících aktivit. Třída Activity47 představuje jakýsi základní stavební kámen každé aplikace Android. Pro nás je v tuto chvíli důležité vědět, že obě tyto třídy jsou jakýmsi kontejnerem, v němž se grafické prvky tvoří a jenž je zapouzdří z pohledu životního cyklu aplikace. Výše zmíněný prvek Action Bar však k využití fragmentů přímo vybízí díky své metodě addTab(), která jako jeden ze svých argumentů přijímá instanci nějakého fragmentu. Tato konstrukce se stala základem naší aplikace. Při prozkoumání základny uživatelů využívajících nižší API než API 3.0 bylo zjištěno, že se jedná o desetiny procenta48, a proto by využití nižší API ani nemělo význam.

6.2.4 Jazyk aplikace Součástí grafického rozhraní je i jazyk, kterým bude tato aplikace k uživateli promlouvat. Vzhledem k cílové skupině uživatelů byl zvolen jazyk anglický. Je však potřeba zmínit, že vývoj vícejazyčných aplikací je platformou podporován již od samého začátku implementace. Kromě samotných textů je možné lokalizovat i grafická rozvržení, zvuky, grafické prvky a jiná statická data. Způsob provádění lokalizace nazývá Android „přepínáním zdrojů“ (anglicky resource-switching). My si však prozatím vystačíme s jedním zdrojem textových řetězců. Ty budou umístěny v tzv. výchozím souboru řetězců. Ten najdeme pod označením strings.xml v adresáři res/values/. Jedná se o soubor, ze kterého se 44 Action Bar [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 45 Tabs [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 46 Fragments [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 47 Activity [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 48 Top Android SDK version [online]. Organizace Google. [cit. 2014-01]. Dostupné z URL: 42

načtou hodnoty vždy, když není nalezena lokalizovaná alternativa např. strings_cz.xml. Měli bychom ještě dodat, že adresář res obsahuje všechny statické zdroje vyjmenované výše. Dále je důležité říci, že kdykoliv bude zmíněn odkaz na nějaký soubor nebo adresář, bude tím míněna adresářová struktura našeho projektu ve vývojovém prostředí.

6.2.5 Návrh grafických prvků V části práce věnované volbě API jsme narazili na pojem Fragment. Ve zdrojovém kódu se pak ještě setkáváme s třídou FragmentDialog. Ta dědí z třídy fragment a jak sám její název napovídá, je určena pro tvorbu dialogů. Je to tedy fragment implementující dialogové okno, které je zobrazeno v popředí nad stávající aktivitou. Obsahuje objekt Dialog, jehož zobrazení reflektuje stavu fragmentu49. Pro naši práci je FragmentDialog zajímavý právě tím, že při vytvoření vyplňuje jen tolik obrazovky, kolik je velikost grafických prvků v něm zahnízděných, a dále také tím, že je umístěn nad všechny stávající aktivity. Je tedy ideálním kandidátem pro většinu interaktivní komunikace aplikace s uživatelem. Samotná třída Fragment je potom základem pro tvorbu grafických prvků terminálových oken. V další části práci se zaměříme na jednotlivé grafické prvky a strukturu aplikace. Podíváme se na možnosti, které nám Android nabízí, a ty vybrané posléze implementujeme. Zpracováním uživatelských případů byly identifikovány následující grafické prvky, které bude aplikace implementovat. Jedná se o: - seznam aktivit - prvek identifikující otevřené relace - seznam uložených relacích - seznam uložených příkazů - okno terminálu - dialogová okna - tlačítka Seznam aktivit. Jedná se o úvodní část, která se objeví při spuštění programu. Její struktura bude odrážet uživatelské případy tak, jak jsme je identifikovali v předchozí kapitole. 49 FragmentDialog [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: http://developer.android.com/reference/android/app/DialogFragment.html 43

Měla by být co nejjednodušší a přehledná. Budou zde umístěny volby reflektující definované uživatelské případy. Jde tedy o rychlé připojení, přístup do seznamu relací, přístup do seznamu příkazů a volbu ukončení běhu programu. Základním prvkem, který byl vybrán nejen pro tuto část práce, je instance třídy ListView. Jedná se o stěžejní prvek celé platformy Android. Hlavním důvodem toho, proč patří k nejdůležitějším prvkům systému, je vysoká frekvence jeho využití. Bez ohledu na to, zda uživatel právě hledá číslo v telefonním seznamu, čte zprávu elektronické pošty, nebo vybírá z nabídky elektronických knih, vždy při dané aktivitě používá ListView50. Data, která jsou tímto seznamem zobrazená, jsou poskytována třídou SettingsFragmentAdapter, jež je potomkem ArrayAdapter. Prvek identifikující otevřené relace. O tomto prvku jsme se v této práci již zmínili v souvislosti s výběrem API. Odkaz na instanci tohoto prvku získáme přímo v třídě MainActivity. Metoda addTab() přidává nejen zmíněný fragment, ale zejména novou záložku. Seznam uložených relací. Tento seznam je implementován ExpandableListView, který má podobné vlastnosti jako ListView. Navíc však umožňuje jednotlivé řádky seznamu rozevírat. Poměrně komplexní částí je adaptér. Jedná se o třídu SessionViewAdapter, která dědí od BaseExpandableListAdapter. Zde je využito návrhového vzoru Holder. Důvodem je metoda findViewById(), která může hledat grafické prvky kdekoliv ve stromu potomků kořenového zobrazení řádku, a toto volání může znamenat poměrně velký počet instrukcí. Tento návrhový vzor je použit i pro seznam uložených instrukcí51. Seznam uložených příkazů. Je velice podobný předchozímu seznamu. Implementuje ExpandableListView s adaptérem CommandViewAdapter, který též využívá návrhového vzoru Holder. Okno terminálu. Kontejnerem pro toto okno je objekt třídy Fragment. Při bližším pohledu nalezneme dvě třídy: TerminalTextView a DummyTextView. Obě dědí od třídy TextView, ale každá existuje z jiného důvodu. Pokud se podíváme na rozvržení celého okna, zjistíme, DummyTextView zcela překrývá TerminalTextView, a i když se jedná o třídu TextView, je nastavená jako editovatelná. Důvodem je fakt, že implementuje View.OnC50 Allen, G.: Android 4. 1 vyd. Brno: Computer Press, 2013. ISBN 978 80 251 3782. Str. 167. 51 Allen, G.: Android 4. 1 vyd. Brno: Computer Press, 2013. ISBN 978 80 251 3782. Str. 176. 44

lickListener, aby mohl reagovat na dotek uživatele, který znamená žádost o vysunutí softwarové klávesnice. Zároveň tedy přijímá uživatelský vstup ze softwarové klávesnice pomocí třídy TextWatcher. Obě třídy najdeme v DummyTextViewController. Důvodem tohoto řešení jsou dva problémy, které se do této chvíle nepodařilo nijak uspokojivě vyřešit a v konečném důsledku byly příčinou velmi velkého zdržení projektu. Prvním byla potřeba speciální znaků, důležitých pro funkčnost emulátoru terminálu. Díky nim může uživatel řídit chování shell operačního systému a výstup na obrazovku. Jde zejména o možnost zadávat znaky jako je control + C, poslat příkaz escape apod. První myšlenkou bylo využít již existujícího příkladu implementace softwarové klávesnice a přizpůsobit jej vlastním potřebám. Výsledek byl bohužel spíše rozpačitý - klávesnice byla nestabilní a v podstatě nepoužitelná. V konečném důsledku to znamenalo značnou časovou ztrátu. Druhým problémem bylo zachytávání uživatelského vstupu. Intuitivně byl zvolen View.OnKeyListener, který však zdaleka nedělal to, co se od něj očekávalo. Je totiž určený pouze pro zachytávání vstupu přes hardwarovou klávesnici52. Dnes jsou běžné softwarové klávesnice, které uživateli umožňují zadávání vstupu prostřednictvím gest. Uživatel jednoduše spojuje písmena na klávesnici nepřerušovaným „malováním křivky“. Proto byl zvolen zmíněný TextWatcher. Výstupem celého konstruktu je potom objekt CharSequence. Je také důležité vzít v úvahu, že uživatel svůj vstup nevidí a ani nemá vidět. To, co vidí, jsou znaky poslané serverem. Proto je v jednom TextView jeho vstup načten a okamžitě smazán, přičemž druhé TextView (TerminalTextView) zobrazuje znaky poslané serverem. Dialogová okna. Jsou kromě výše uvedených důvodů také využívána jako kontejner pro grafické prvky EditText. Jedná se o třídu dědící z TextView, která je však editovatelná. Umožňují uživateli zadávat parametry relace a připravovat příkazy. Tlačítka. Poslední grafický prvek, který je implementací třídy Button. Je taktéž potomkem třídy TextView a z pohledu uživatele se chová jako softwarová klávesa53. Posledním prvkem, který je potřeba zmínit, je ikona aplikace. Jedná se o fotku sestavy starého terminálu, která byla v grafickém studiu upravena tak, aby odpovídala požadavkům na různá rozlišení obrazovek.

52 View.OnKeyListener [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: 53 Button [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: 45

6.3 Struktura aplikace 6.3.1 Implementace protokolu SSH Vůbec nejdůležitější částí, kterou náš návrh grafického rozhraní zastřešuje, je samotná implementace SSH klienta. Na internetu lze najít celou řadu již hotových, volně šiřitelných knihoven. Výsledkem našeho hledání byly dva projekty, JSch 54 a Ganymed-SSH255 (dále jen Ganymed). Ganymed byl vyvinut jako součást projektu technické univerzity v Curychu 56 a jeho autorem je Christian Plattner a kolektiv studentů. Velkou výhodou knihovny Ganymed je velmi dobře zpracovaná dokumentace, která pro nás byla při hodnocení a výběru knihovny rozhodujícím faktorem. Projekt navíc podporuje SSH požadavky (viz. kapitola SSH), jako jsou např. spuštění vzdáleného příkazu a poskytnutí přístupu do shell prostředí serveru. Umožňuje lokální a vzdálené přesměrování portů, lokální přesměrování datového toku, přesměrování X11, SCP SFTP. Zároveň není závislý na žádném jiném poskytovateli Java Cryptography Extension. Implementace šifer byla provedena za pomoci skupiny Legion of the Bouncy Castle57. Starší projekt (viz. poznámka pod čarou) je knihovna, která SSH protokol implementuje v Java SE verzi 1.5. 58. Použitá verze je velmi zajímavá z pohledu druhého cíle této práce. Teoreticky by tedy mělo být možné bez problému tento kód přenést a spustit v Androidu. Bližším zkoumáním celé knihovny byly nalezeny příklady zdrojových kódů, které celou integraci knihovny usnadňovaly. Na prvním nalezeném příkladu, kterým byly třída Basic.java v adresáři Ganymed-SSH2-build210/examples našeho projektu, bylo možné ověřit, jestli lze tento kód vůbec dál využít. Po úspěšném integrování celé Java knihovny ganymed-ssh2build210.jar do projektu našeho vývojového prostředí nám tato třída umožnila otestovat první základní SSH požadavek spuštění vzdáleného příkazu. Zde je ukázka kódu, který funkčnost ověřil: 54 Dostupné z URL: 55 Původní projekt dostupný z URL: , pokračující je dostupný z URL:< https://code.google.com/p/ganymed-ssh-2/> 56 Přesný název instituce zní Eidgenössische Technische Hochschule Zürich. 57 The Legion of the Bouncy Castle.[online]. [cit. 2014-12-04]. Projekt skupiny dostupný z URL:< http://www.bouncycastle.org/> 58 Plattner, Ch.: Ganymed SSH-2 for Java [online]. Curych: Spolková vysoká technická škola. [cit. 2014-12-04]. Dostupné z URL: 46

Výstup ze serveru Connection conn = new Connection(hostname); /* Now connect */ conn.connect(); boolean isAuthenticated = conn.authenticateWithPassword(username, password); if (isAuthenticated == false){ throw new IOException("Authentication failed.");} Session sess = conn.openSession(); sess.execCommand("uname -a && date && uptime && who"); Naším cílem však bylo získat přístup do prostředí shell vzdáleného serveru. K tomu nám posloužila třída SwingShell.java ze stejného, výše zmíněného adresáře. Bylo ji však nutné adaptovat pro prostředí Android. Jako první úkol bylo potřeba zbavit se všech implementací odkazujících se knihovnu Swing. Zároveň však bylo potřeba zachovat stejnou interakci s uživatelem jako u původního příkladu, a to ze dvou důvodů. Uživatel interaktivně schvaluje veřejný klíč a také zadává nebo potvrzuje heslo. Toho bylo docíleno následovně. Jak již bylo řečeno výše, jakýkoliv grafický prvek v Androidu potřebuje pro svoji existenci vědět, v jakém aplikačním kontextu běží. Ten byl předán referencí na instanci třídy MainActivity a voláním její metody runOnUiThread(). V jejím těle potom nalezneme konstrukci dialogových oken. Dalším problémem byla nutnost zajistit, aby se vlákno, ve kterém naše třída běží, zastavilo a čekalo na uživatelský vstup. Toho bylo docíleno použitím programového idiomu „Guarded Block“. Běh vlákna je blokován do chvíle, než je splněna nějaká podmínka59. Třída byla pojmenována Socket a část její funkcionality, zejména práce s datovými toky, byla přenesena do třídy SessionRecieveSend. Obě třídy můžeme nalézt v balíku ssh v zdrojových kódech aplikace.

59 The Java Tutorials [online]. Organizace Oracle. [cit. 2014-12-11]. Dostupné z URL: 47

6.3.2 Vnitřní komunikace

Zdroj: Autor Obrázek č. 4

Jak je patrné z obrázku č. 4, převážná část komunikace vnitřních objektů je asynchronní. Důvody jsou dva. Pro platformu Android je specifický životní cyklus jakékoliv aplikace. Je normální, že uživatel aktivitu opouští buď stiskem tlačítka zpět, nebo stiskem tlačítka domů. Také je běžné, že komponenta absolvuje celý životní cyklus při konfiguračních změnách, jako je například změna orientace mobilu. Na již jednou zmíněné objekty typu Activity a Fragment jsou zpětně volány metody, které mají za cíl nastavit chování těchto objektů adekvátně stavu životního cyklu. V případě zavolání metod onDestroy() a onDestroyView() ztratí okolní komunikující objekty reference na atributy a metody těchto objektů. Stále 48

však existuje reference na objekt samotný v aplikačním kontextu. Zároveň však bylo cílem práce, aby připojení zůstávala zachována a měla by být tedy relativně nezávislá na těchto cyklech. To se děje díky instanci třídy TerminalService, která je typu Service. Jedná se o aplikační komponent reprezentující zájem aplikace na vykonávání dlouhodobých úkolů, kdy není nezbytně nutné komunikovat s uživatelem, nebo je třeba poskytnout nějakou funkcionalitu jiným aplikacím.60 To implikuje i záměr této aplikace poskytovat v budoucnu funkcionalitu i jiným aplikacím, než je naše implementace GUI. Z toho důvodu je celá komunikace mezi MainActivity a TerminalService zastřešena implementací třídy Messenger. Instance této třídy využívá reference na Handler, přes který si zúčastněné strany komunikace posílají zprávy. Jedná se o objekty typu Message. To umožňuje implementaci komunikace napříč procesy.61 Samotný objekt TerminalService potom komunikuje s objektem Socket pouze pomocí objektu Handler. V prípadě třídy Socket zde najdeme implementaci HandlerThread. V podstatě se jedná o Handler, který začleňuje nové vlákno Thread, Looper a MessageQueue. Je navržen tak, aby se spustil stejně jako Thread. Jakmile je vlákno jednou spuštěno, nastaví řazení do fronty pomocí Looper a MessageQueue a čeká na příchozí zprávy.62 Z pohledu naší aplikace je spuštění dalšího vlákna důležité, protože, jak bylo uvedeno výše, třída Socket využívá blokování vlákna při interakci s uživatelem. Z pohledu druhého cíle této práce je potřeba uvést, že výše uvedené mechanismy jsou vlastní pouze platformě Android a Java SE je neimplementuje.

60 Service [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: 61 Service [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: 62 Görason, Anders: Efficient Android Threading. 1st edition. Sebastopol: O'Reilly Media, 2014-05-21. ISBN: 978-1-449-36413-7. Strana 121. 49

7 Závěr Výsledkem této práce je prototyp SSH klienta, který ještě neimplementuje funkcionalitu emulátoru terminálu a v důsledku výše uvedených zdržení je zatím jen omezeně funkční. Celá aplikace je vnitřně navržena tak, aby ji bylo v budoucnu možné využívat nejen s námi navrženým grafickým rozhraním. Dokázali jsme, že za určitých okolností je zdrojový kód Javy SE přenositelný na platformu Android. Bylo to potvrzeno na netriviální implementaci knihovny využívající kód knihoven Java SE 1.5.

50

8 Seznam použitých zdrojů Allen, G.: Android 4. 1 vyd. Brno: Computer Press, 2013. ISBN 978 80 251 3782. Barret, D., Silverman, E., Byrnes R.: SSH The SecureShell. 2Nd edition, Sebastopol: O'Reilly Media, 2005. ISBN: 978-0-596-00895-6. Drake, J., Fora, P., Lanier, Z., Muller, C., Ridley, S. A., Wichersky, G.: Android Hacker's Handbook. Indianapolis: Wiley&Son, 2014. ISBN: 978-1-118-60864-7. Görason, Anders: Efficient Android Threading. 1st edition. Sebastopol: O'Reilly Media, 2014-05-21. ISBN: 978-1-449-36413-7. Online zdroje: Action Bar [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: Activity [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: Android API, View [online]. Organizace Google. [cit. 2014-12-11]. Dostupné z URL: Android, the world's most popular mobile platform [online]. Google Inc. [cit. 2015-01-02]. Dostupné z URL: Android Tools Project Site [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: Apache Harmony [online]. The Apache Software Foundation. [cit. 2015-01-02]. Dostupné z URL: Button [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: Data Integrity [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: Encryption [online]. Organizace IETF.[cit. 2015-01-02]. Dostupné z URL: FragmentDialog [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: http://developer.android.com/reference/android/app/DialogFragment.html Fragments [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: 51

Getting started with SSH security and configuration [online]. New York: IBM [cit.201501-02]. Dostupné z URL: JuiceSSH-SSH Client [online]. Google. [cit.2014-12-29]. Dostupné z URL: Key Exchange Methods [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: PI Guides [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: Plattner, Ch.: Ganymed SSH-2 for Java [online]. Curych: Spolková vysoká technická škola. [cit. 2014-12-04]. Dostupné z URL: Public Key Algorithms [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: RFC4251, RFC4252, RFC4253, RFC4254, RFC4255, RFC4256 [online]. Organizace IETF. [cit. 2015-01-02]. Dostupné z URL: Service [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL: Styles and Themes [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: Tabs [online]. Organizace Google. [cit. 2015-01-02]. Dostupné z URL: The Java Tutorials [online]. Organizace Oracle. [cit. 2014-12-11]. Dostupné z URL: The Java Tutorials [online]. Organizace Oracle. [cit. 2014-12-11]. Dostupné z URL: The Legion of the Bouncy Castle.[online]. [cit. 2014-12-04]. Projekt skupiny dostupný z URL: Top Android SDK version [online]. Organizace Google. [cit. 2014-01]. Dostupné z URL: View.OnKeyListener [online]. Organizace Google. [cit. 2014-12-04]. Dostupné z URL:

52

Příloha: DVD se zdrojovým kódem

53

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Recommend Documents