OpenSSH - více než jen Secure Shell

3. 9. 2007 | Pavel Šimerda

Články - OpenSSH - více než jen Secure Shell  

V minulém článku jste si mohli přečíst, jak nastavit OpenSSH, aby bylo bezpečné a přitom použitelné. Dneska trochu opustíme téma bezpečnosti a podíváme se, co nám OpenSSH nabízí kromě vzdáleného shellu. Pro větší pohodlí ještě projdeme některá užitečná nastavení.

Konfigurace klienta

Příkaz ssh (stejně jako i další související programy) čte globální konfiguraci z /etc/ssh/ssh_config a uživatelskou konfiguraci z ~/.ssh/config. Poslední slovo mají parametry příkazové řádky.

Globální i uživatelský soubor se skládá ze sekcí podle jednotlivých serverů. Sekce začínají direktivou Host, za kterou následuje název serveru, který zadáváte jako parametr ssh. Nastavení, která mají platit pro všechny servery, patří do sekce Host *.

Pro začátek vám ukáži, jak si ulehčit zadávání serverů s dlouhým názvem a alternativním portem.

cat ~/.ssh/config

Host prace
  HostName server.oddeleni.example.net
  User uzivatel_b00
  Port 1111

$ ssh prace

Bash completion

Přečtěte si článek Bash: chytré doplňování od Michala Vyskočila (nebo se podívejte po dalších zdrojích v odkazech na konci článku) a nastavte si doplňování příkazů i pro OpenSSH.

OpenSSH umí doplňovat názvy SSH serverů po stisku tabulátoru podle sekcí v konfiguraci a ~/.ssh/known_hosts (seznam známých serverů a jejich klíčů).

$ ssh p<tab>

Komprese

SSH přenosy můžou být datově náročné. Pokud jsou oba počítače rychlé a práci zdržuje kapacita linky mezi nimi, může pomoct zapnutí komprese přepínačem -C.

$ ssh -C uzivatel@example.net

Alternativně můžete nastavit kompresi v konfiguračním souboru ~/.ssh/config.

Host *
  Compression yes

Komprese musí být povolena na serveru. Výchozí nastavení OpenSSH serveru (/etc/ssh/sshd_config) ji odkládá do úspěšného dokončení autentizace.

Compression delayed

Pouštíme grafické aplikace – X Forwarding

Jedním z takových datově náročnějších použití SSH je spouštění vzdálených grafických aplikací (zapíná se přepínačem -X). Zkuste si takhle na serveru pustit nejdříve jednodušší aplikace a pak zkuste třeba Inkscape.

$ ssh -C -X uzivatel@example.net xclock
$ ssh -C -X uzivatel@example.net inkscape

Opět můžete upravit konfiguraci a nastavit, pro které servery chcete používat X Forwarding automaticky.

Host xserver
  HostName server.example.net
  ForwardX11 yes

Spouštění grafických aplikací musí být povolené v konfiguraci SSH serveru (což většinou je).

X11Forwarding yes

File transfer – scp, sftp

Přenosy souborů zajišťuje SFTP protokol (nebo starší SCP protokol). Oba se používají ve spojení s SSH. K dispozici jsou dva konzolové programy: scp (ovládá se podobně jako cp (relativní cesty na vzdáleném stroji se vztahují k domovskému adresáři) a sftp (nabízí podobné rozhraní jako klasický příkaz ftp).

$ scp clanek.html uzivatel@example.net:
$ scp clanek.html uzivatel@example.net:work/
$ scp uzivatel@example.net:/etc/hosts hosts.example
$ scp hosts.example root@example.net:/etc/hosts
$ sftp uzivatel@example.net

Přenos souborů pomocí SSH (a SFTP) je podporován mnoha grafickými aplikacemi. Patří mezi ně všechny aplikace založené na KDE (KIO), lepší správci souborů, systémy pro správu verzí a další. Za zmínku stojí i WinSCP (nápadně podobný Total Commanderu), který se hodí, pokud se potřebujete k souborům dostat z Windows nebo po někom chcete, ať vám uloží soubory do počítače.

SFTP subsystém musí být nastaven na serveru (většinou je).

Subsystem       sftp    /usr/lib/misc/sftp-server

Uživatel připojuje vzdálený adresář – sshfs

Pro pohodlnější práci se někdy hodí připojit si vzdálený adresář do lokálního filesystému. K tomu slouží FUSE a na něm postavený sshfs (který používá SFTP protokol). Nainstalujte si ho a zkuste připojit nějaký vzdálený adresář (to můžete i jako běžný uživatel, pokud vám přípojný bod patří). Samozřejmě můžete vzdálený filesystém zase odpojit.

$ mkdir pripojny_bod
$ sshfs uzivatel@example.net:/adresar/ktery/chcete pripojny_bod
$ ls pripojny_bod
$ fusermount -u pripojny_bod
$ rmdir pripojny_bod

I když je váš počítač za IP maškarádou (často zjednodušeně nazývanou NAT), můžete pomocí SSH připojit váš lokální disk do adresáře na serveru (tzn. opačně než v předchozím příkladu). Využívá se k tomu přesměrování portů pomocí SSH, kterým se bude zabývat příští článek.

Administrátor zpřístupňuje síťový adresář – sshfs a fstab

Pokud chcete zpřístupnit nějaký adresář při startu systému, využijte konfigurační soubor /etc/fstab.

Pokud root nemá ssh klíč, měli byste ho vygenerovat (aby vše fungovalo, nesmí být klíč chráněný passphrase). Na straně serveru pak doporučuji založit pro tyto účely samostatný účet a přidat mu veřejný klíč serveru. Tentokrát výjimečně provádíme všechny příkazy za roota. Ten poslední je jen pro budoucí kontrolu.

# ssh-keygen -t dsa -N ''
# scp /root/.ssh/id_dsa.pub root@example.net:root_id_dsa.pub
# ssh root@example.net
root@example.net# adduser ssh_share --system --home /data --shell `find /usr -iname sftp-server | head -1` --group
root@example.net# mkdir -p ~ssh_share/.ssh
root@example.net# cat /root/root_id_dsa.pub >> ~ssh_share/.ssh/authorized_keys
root@example.net# touch ~ssh_share/funguje_to

Samozřejmě za adresář /data můžete dosadit, co chcete. Teď vyzkoušíme, jestli je konfigurace v pořádku. Všechny příkazy voláme za roota na klientovi a musí projít bez zadávání hesla nebo passphrase.

# mkdir test_sshfs
# sshfs ssh_share@example.net: test_sshfs
# ls test_sshfs
funguje_to
# fusermount -u test_sshfs
# rmdir test_sshfs

Vypsání souboru funguje_to ukazuje, že vše funguje, jak má. Už zbývá jen přidat příslušný řádek do /etc/fstab.

sshfs#ssh_share@example.net: /mnt/data fuse allow_other 0 0

Místo /mnt/data můžete vybrat přípojný bod, který se vám hodí. Volba allow_other znamená, že bude filesystém čitelný i pro ostatní uživatele.

# mount -a

Pokud vše proběhlo v pořádku, gratuluju vám k úspěšnému spuštění síťového filesystému na bázi SSH. V některých případech je použití sshfs jednodušší a účelnější než konfigurace plnohodnotného síťového filesystému.

Závěrem

Další aplikace zabezpečují pomocí SSH svoji komunikaci. Systém pro správu verzí Git používá SSH jako výchozí protokol pro operace se vzdálenými repozitáři. Program rsync pro synchronizaci vzdálených adresářů standardně také používá SSH ke spojení se vzdálenými stroji.

Příště si zkusíme prostřednictvím OpenSSH přesměrovávat TCP porty (jak jsem už slíbil) a také spojit fyzické sítě ve VPN.

Diskuse k tomuto článku

[the.max]

moc dobra "referencni prirucka". konecne sem pochopil par veci jak pouzit spravne parametry

[mykhal]

neví někdo o nějaké ssh implementaci v GnuTLS ?

[netservis]

Perfektní článek, dík.

[hanc]

moc hezkej clanek, diky ! jen tak dal :)

[pavlix]

Díky všem za pochvaly, jj, jakmile bude čas, navážu dalším povídáním.

[pet]

XForwarding u ssh je velice dobra vec, bohuzel pro nektere aplikace nefunguje. Podle mych zkusenosti jsou to aplikace pouzivajici gtk2. Pokud nekdo vi co s tim, tak bych byl mooc rad.

[phax7]

Mi to funguje normálně z krabice... teď jsem zkusil na Gimpovi

[Petr "Glubo" Sýkora]

Běžně xforwarduji aplikace používající gtk2, nenarazil jsem na žádný problém. Jak se ta chyba projevuje?

[SigTERM]

tohle ti mozna pomuze, mluvi se tam cosi o ssh -Y hostname misto ssh -X hostname

http://gentoo-wiki.com/HOWTO_X-forwarding

[Peter Šantavý]

XForvarding funguje aj s gtk2 aplikaciami (u mna s Fedora a CentOS v roznych verziach).

Problemom bude nieco ine...

[pto]

Někde mi při problémech s gtk2 pomohlo přidat do cfg kromě:

ForwardX11 yes

ješte:

ForwardX11Trusted yes

[jiri.b]

jen podotykam, ze FUSE a sshfs neni a nikdy nebude soucasti OpenSSH projektu!

jinak, co jsme se dozvedeli? nic zajimaveho... skoda.

[diverman]

tak napis pokracovani, kde se teda dozvime neco zajimaveho...

[jiri.b]

na konci I. dilu autor zadal o tipy na temata, dostal jich kopec... bohuzel zustal u zakladu, ktery zna kazdy uzivatel unixu, co neklika, jak zbesily :)

takze staci mrknout do diskuse k I. dilu...

napriklad jeste technicka... pri vyhradnim pouzivani sftp-serveru nefunguje scp, protoze scp neni nic jineho nez vstup presmerovany pres pipe (ssh) a vystup do remote shellu. upozornuji na slovo 'vyhradnim', ctenar muze sam vyzkouset pri pouziti ForceCommand :)

hehe... kolega mi rekl, "kdo pouziva scp...?"... wow, ja tedy osobne pouzivam, vetsinou pouze scp :)

[diverman]

tady nekdo sezral vsechnu moudrost sveta

[Michal Kubeček]

na konci I. dilu autor zadal o tipy na temata, dostal jich kopec... bohuzel zustal u zakladu, ktery zna kazdy uzivatel unixu, co neklika, jak zbesily

Vy v tom článku někde vidíte napsáno, že je tento díl poslední? Já tam naopak na konci vidím zmínku o tom, co bude v příštím dílu, očekával bych tedy, že nejméně jeden ještě bude. Takže by asi bylo lepší s hodnocením, u čeho autor zůstal nebo nezůstal, počkat až na konec seriálu…

[jiri.b]

no... pro mene chapave a ty, jenz se citi stale ukrivdeni a maji pocit, ze jim nekdo ublizuje (coz neni autor, ale nekteri ctenari) :), bych rad objasnil to, co jsem napsal...

...zatim je to porad dokola, coz je praveze skoda. aktualni dil ci podobne variace najdeme na root.cz, krypta.cz ci linuxsoft.cz - ten je povedeny dle meho nazoru - http://www.linuxsoft.cz/article.php?id_article=265

ten, kdo ssh pouziva kazdy den, a tipuji, ze hodne lidi, to vse zna. ten, kdo nezna, tak si vystaci s prvnim dilem...

(zde bych osobne napsal o srovnani openssh clienta a putty, napriklad v praci jsem jediny, kdo zavrhl putty a pouziva X/Cygwin...; pocity a pouzitelnost)

napriklad je tu porad dokola dotaz na ssh a chroot. doufam, ze tohle bude neco, co autor rozhrabne, a bude to originalni clanek na poli ceskeho unix internetu. snad se to ale nezvrhne v 15minutovou pripravu se zaverem pouzivejte rssh...

proste chtel jsem rict, ze tu chybi neco originalniho, neco co jde do hloubky, neco co resi ruzne pohledy a co je i trochu provokativni a atakuje neustale stereotypy. kvalitni clanky, plne informaci a zamysleni, jsou to, co dela jeden portal dobrym a druhym prumernym :)

[Michal Kubeček]

A pro ty ještě méně chápavé: hodnotit hloubku seriálu po druhém dílu, když nevím, kolik jich bude, je blbost. Howgh.

[pavlix]

Ve chvíli, kdy jsem dostal tipy, byl tento díl už sepsán a bohužel autor neměl na změny ve článku čas.

[LFCIB]

jinak, co jsme se dozvedeli? nic zajimaveho... skoda.

Proč to množné číslo? Mluv za sebe laskavě. Nebo je vás tam víc? Víc machýrků co už všechno uměj, tak čtou abclinuxu?

[pavlix]

Jinak na hloubkové poznání SSH doporučuju číst manuál.

A nepamatuju si, že bych tvrdil, že sshfs je součástí OpenSSH. V článku zmiňuju i WinSCP a toho jsi se kupodivu nechytil.

[AsciiWolf]

Skvělý článek,hned jsem vyměnil mé vsftpd za sftp

[disorder]

tomuto nerozumiem? vsftpd umoznuje povolit len sifrovane spojenia (skus miesto obycajneho ftp nainstalovat ftp-ssl)

[AsciiWolf]

No,jde o to,že jsem vsftpd provozoval na stroji z 32MB ram + mi tam běžel ořezaný ssh server (dropbear)...

Takže mi přišlo o moc lepší nainstalovat tam sftp modul pro sshd a odinstalovat vsftpd,který bral zbytečně 6MB RAM - ušetřil jsem 6 MB RAM :)

[petr_p]

vsftpd-2.0.3 na i686 mi zabira v pameti 1740 kB.

[AsciiWolf]

Btw. navíc na co používat 2 démony (sshd + vsftpd s šifrovaným spojením,když mohu mít jen jednoho démona (sshd) s sftp modulem ;)

[disorder]

ssh a ftp nie su volne zamenitelne sluzby :)

[jaja]

v tomto se ale vsftp s sftp potkava. a o tom tu je rec.

duvodem proc to nedelat je rychlost. sftp je temer o rad pomalejsi. coz se vsak u beznych operaci neprojevuje. pouze pokud sdilite velky objem dat je sftp nevyhodne - je vsak pravdou, ze tam uz nedostacuje ani vsftp. obvykle se tam pouziva nfs. jakmile do toho jeste zamichame spotrebu syst. zdroju (ram,cpu) tak nalezeni vhodne technologie je netrivialni.

[Michal Kubeček]

sftp je temer o rad pomalejsi. coz se vsak u beznych operaci neprojevuje.

V jakém smyslu je "téměř o řád pomalejší"?

[pavlix]

Dík, jsem rád, že pomohlo, btw, co to provozuješ za mašinu?

[Radek Hladik]

Reším takový "jednoduchý" problém. Chtěl bych, aby se root mohl přihlásit jenom z localhostu. Nebo alespoň aby se ze sítě mohl přihlásit jen klíčem a z localhostu i heslem.

Myslel jsem si, že to bude poměrně jednoduché, OpenSSH má přece AllowUsers direktivy a spol... Jenže po chvíli laborování a koukání do zdrojáků, se mi zdá, že to nepůjde.

Zjistil jsem totiž, že OpenSSH u vyhodnocování direktiv *Users víceméně ignoruje znak ! jako negaci. U vyhodnocení části s username se volá funkce match_pattern, která ! už nevyhodnocuje. U vyhodnocení adresy se sice volá fce match_patterns, která sice ! v potaz bere, ale poměrně zamotaně, což ve finále vede k tomu, že to také nefunguje.

Takže nápady jako AllowUsers root@localhost !root nebo DenyUsers root@!localhost bohužel nefungují.

Stejně tak omezení uživatele pomocí direktivy Match mi nepomůže, protože nemůžu omezit nic významného.

Neřešil jste někdo podobný problém? Rád bych to vyřešil přímo v sshd, vím že to můžu udělat třeba přes pam_access, ale tohle by přece SSH daemon mohl zvládnout...

Radek

[jiri.b]

novejsi verze OpenSSH maji Match v man sshd_config

a posledni verze OpenSSH to rozsiruje i pro definovani zpusobu autentifikace.

[jiri.b]

http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config

Match   Introduces a conditional block.  If all of the criteria on the
        Match line are satisfied, the keywords on the following lines
        override those set in the global section of the config file, un-
        til either another Match line or the end of the file.  The argu-
        ments to Match are one or more criteria-pattern pairs.  The
        available criteria are User, Group, Host, and Address.  Only a
        keyword.  Available keywords are AllowTcpForwarding, Banner,
        ForceCommand, GatewayPorts, GSSApiAuthentication,
        KbdInteractiveAuthentication, KerberosAuthentication,
        PasswordAuthentication, PermitOpen, RhostsRSAAuthentication,
        RSAAuthentication, X11DisplayOffset, X11Forwarding, and
        X11UseLocalHost.

[Radek Hladik]

Tuhle man page na netu jsem taky potkal, leč ve Fedoře 5,6 a 7, ve kterých to potřebuju, je bohužel zatím jen toto:

Available keywords are AllowTcpForwarding, ForceCommand,GatewayPorts, PermitOpen, X11DisplayOffset, X11Forwarding, and X11UseLocalHost.

Nevím proč to tak je, ale obávám se, že balíček s novou verzí pro všechny verze Fedory asi nebude. A použití nedistribučních balíčků bych se rád vyhnul. Na druhou stranu, pokud už se rozhodnu použít jiný, tak si tam můžu přidat i patch na podporu LDAPu, který by se mi tam docela taky hodil

Radek

[jiri.b]

no tak to se musis rozhodnout sam, jestli pouzivat distro s obstarozni verzi OpenSSH nebo ne :)

myslim, ze ./configure && make install funguje stale :)

patch na LDAP? no nevim, ale na Linuxech se to resi pres PAM...

$ uname -sr ; ssh -V
OpenBSD 4.1
OpenSSH_4.6, OpenSSL 0.9.7j 04 May 2006

[jiri.b]

no a taky by to snad slo (pouze prihlaseni) pres /etc/hosts.allow, pokud je sshd zkompilovano proti TCPWrappers

$ ldd /usr/sbin/sshd  | grep wrap
        libwrap.so.0 => /lib/libwrap.so.0 (0xb7f54000)

[Jouda]

s/autentifikace/autentizace/

to první je nesmysl pane jiří

[pavlix]

Spíš drobná chybka, když jde jen o komentář :).

[Filip Jirsák]

A chcete, aby se root z localhost u připojoval přes ssh? Pokud ne, stačí PermitRootLogin no. Pokud z nějakého důvodu potřebujete povolit lokální přihlášení roota přes ssh, asi bude dobré prozdradit důvod, proč to tak potřebujete (třeba se najde jiné řešení).

[Radek Hladik]

Právě, že bych rád aby se přihlašoval přes SSH. Protože bych tak poměrně elegatně obešel su. V současnosti řešíme administraci serverů tak, že se přihlásí uživatel a pak si udělá su. K tomu musí znát rootovské heslo. Já bych rád, aby se to udělalo tak, že se uživatel přihlásí svým klíčem a potom udělá ssh root@localhost a root bude mít nastavené klíče, které se smí přihlásit. Půjde tak lépe hlídat kdo se smí přihlásit a lépe půjde odebrat někomu možnost přihlásit se jako root, než mu mlátit do hlavy, aby zapoměl heslo. Na druhou stranu bych chtěl nechat možnost přihlásit se heslem, pokud tohle nějak selže.

Když tak teď o tom přemýšlím, tak možná bude stačit, když zapnu PermitRootLogin without-password a to su zůstane jako ta nouzovka. Ale pak se půjde ze sítě přihlásit jako root rovnou, bez použití neroot uživatele... Ale to by možná nemuselo zas až tak vadit...

Radek

[Filip Jirsák]

A nebylo by jednodušší použít pam_wheel, které přesně k tomuhle slouží?

[Radek Hladik]

Tak a jsem zase jednou za debila Tolik jsem se soustředil na použití SSH a klíčů, že jsem znova vymýšlel kolo (a to doslova ) A přitom pam_wheel používáme na omezení, kdo vůbec smí udělat su. Tak mu jen nahodim sufficient a bude to. Díky za nakopnutí...

Radek

[CentrinO]

Ahoj,
jeste bych pridal ze podobnou zalezitost je asi vhodne resit i pomoci sudo, ktere je na neco podobneho taky delane. Hezky den preje

[jiri.b]

sudo je dobre, ale ne vselekem. jestli ma nekdo blbe napsany /etc/sudoers, tak nekdo muze z povoleneho programu ziskat root shell a je po logovani :)

takze, bud verime, a mame tu nejakou dohodu s uzivateli... nebo holt se podivame po paranoidnim resenim - tj. auditing a RBAC a MAC.

[moira]

A kdyz udela su - tak nebude mit root shell? IMHO je v tomto mnohem lepsi pouzit sudo nez dat uzivateli moznost prihlasit se suckem. Kdyz ma nekdo blbe napsany sudoers tak to je jeho problem. To uz muzete taky argumentovat, ze kdyz nekdo nema na roota heslo, tak nekdo taky muze ziskat root shell :)

[Milan "Nemo" Cingroš]

Příkazem sudo -s dostaneme root shell a uživatel zadává vlastní heslo. Ale pravidla bezpečnosti stejně říkají, že pokud měl někdo přístup k root shellu, tak jediná možnost, jak zajistit bezpečnost po jeho odchodu je přeinstalovat počítač...

[Michal Kubeček]

Na systému se standardním bezpečnostním modelem… Takový SELinux nebo LIDS dokážou i toho roota docela efektivně přidusit. Vlastně i AppArmor…

[jiri.b]

no bylo to mysleno tak, ze spousty programu maji moznost jit do shellu - vi/vim, ftp atd...

tyhle pravidla bezpecnosti jsou vtipny :) u nas v praci ma rootshell desitka lidi, no nevsiml, jsem si ze to porad preinstalovavaji :)

[Milan "Nemo" Cingroš]

Vždycky se musí udělat kompromis mezi "absolutní" bezpečností a použitelností. Obvykle se po prvním průšvihu snižuje použitelnost a zvyšuje bezpečnost A když má rootshell desítka lidí, tak je to asi stejně jedno

[pavlix]

Dá se to nakonfigurovat i bez hesla.

[disorder]

     -Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
             subjected to the X11 SECURITY extension controls.

vsetko je v manuale

[Dr.Tič]

Mne se ten clanek taky libi. I kdyz programy z baliku OpenSSH (a z doplnkovych baliku) pouzivam kazdy den a podobnych clanku jsem uz par cetl, tak i presto jsem tu nasel nekolik veci, ktere pro me byly nove nebo jsem si aspon upresnil nektere informace. Takze celkovy dojem - dobry clanek.

[laoce]

Aj mne sa ten clanok velmi pacil ..ssh pouzivam denne v praci ale mnohe veci tu uvadzane mi boli nie uplne jasne :o) takze moc diki za clanok a pevne nervy v pokracovani :o) drzim palce!!! :o))

[alanos]

Pokud si spustím nějakou aplikaci přes ssh -C -X , dá se nějak udělat aby aplikace běžela dál na vzdáleném počítač i po ukončení na mém X.? Konkrétně když si ze vzdáleného počítače pustím třeba GFTP a dám něco stahovat aby to běželo dál . Já to sice řeším přes VNC ale jen se chci zeptat jestli to jde nějak přes ssh.

[jiri.b]

rekl bych, ze ne. X client je svazan s urcitym displayem a ten by zmizel...

[alanos]

Já si to myslel ale za optáni člověk nic nedá :o) . V navodech jsem taky nic nevyčetl.

[Abraxis]

Co takhle "nohup"? Ale uz se asi k aplikaci znovu nepripojis...

[jiri.b]

to je podle me nesmysl, X client musi mit platny X display...

...vsak si zkuste spustit X aplikaci v konzoli, skocite na X diplay problemu

[pavlix]

Neznám způsob, ale neřekl bych, že je to úplně nemožné.

[fabian]

Pekny clanek. O sshfs jsem nevedel a hned se mi to hodi. Diky:)

[y]

Peknej clanek. Akorat je skoda ze tu neni vic informaci o sftp. Na vsftpd pouzivam chroot uzivatelu, ale u sftp se mi nic podobneho zatim nepodarilo. Byl bych rad kdyby se o to v pokracovani clanku neco objevilo.

[Michal Kubeček]

Měl by to umět scponly.

[pavlix]

Taky už jsem přemýšlel o tom chrootu, díky.

[statybosabc]

Baigti darbą statybosabc.lt Gaisro atkūrimas Kadravimas: Mediena ir metalas Žaliasis pastatas Istorinis išsaugojimas Institucinės / mokyklos Interjero dizainas Tapyba Šalčio statybos statybos paslaugosVandentiekiavimas Remodeling Atsinaujinančiosios energijos projektai Stogų Saulės Atšaka Plieno pastatai Plieno Smeigės/Gipskartonio Struktūrinis remontas / armatūra

Kai kurios su darbu susijusių paslaugų ir techninės priežiūros darbų paslaugų apimtis apima (bet jomis neapsiribojame):

Tvoros įrenginiai Sienų demo/statyba Dailidžių ir (arba) remonto įrenginiai. Lubų remontas/įrenginiai Betono remontas Leidžiantis Tapyba Durų remontas ir (arba) įrengin