OpenSSH kasutamine

Sissejuhatus

OpenSSH http://www.openssh.org/ tarkvara võimaldab turvalist kaugligipääsu võrku ühendatud seadmetele, nt arvutitele ja ruuteritele. OpenSSH on üks OpenBSD projekti ettevõtmistest, mis on osutunud niivõrd populaarseks, et sellest on kujunenud praktiliselt kõigi 2009 aastal kasutuses olevate vabade operatsioonisüsteemide standardne kaugligipääsu korraldamise instrument. Lisaks on OpenSSH kasutuses ka mitmete mitte-vabade lahenduste juures, nt erinevate tootjate ruuterites.

Peale üle võrgu nö teise arvuti käsureale jõudmise sisaldab OpenSSH muu hulga selliseid võimalusi

andmete kopeerimine - sftp, scp
turvaline transport muudele programmidele - rsync, subversion, pppd, X Window System
portide edasisuunamine
SOCKS server
failisüsteemi külgeühendamine - sshfs (FUSE tehnoloogia abil)

Kõik need juhud eeldavad, et teil on kasutajatunnus ka teises masinas. SSH põhineb klient-server mudelil kusjuures ühenduse algatab alati SSH klient. Edaspidises kasutatakse väljendit SSH server, mille all mõeldakse teist masinat ning millel on SSH kliendiga suhtlemiseks sobiv tarkvara.

OpenSSH kasutamist kirjeldatakse Kuutõrvajas kahes tekstis

käesolev tekst on mõeldud nö süsteemi tavakasutajatele oluliste ülesannete lahendamiseks OpenSSH abil
aadressil OpenSSH administreerimine olev tekst kirjeldab OpenSSH serveri haldamist ning keerulisemad kasutusvõimalusi

Teise masinasse sisselogimine ja ühenduse lõpetamine

Kirjeldame lihtsustatult, kuidas toimub SSHga teise masinasse sisselogimine.

Logimisel on kolm etappi:

Protokollide kontroll. Seansi algus ei ole krüptitud. Selle käigus teevad osapooled kindlaks, et nad kasutavad omavahel sobivaid SSH versioone. Klient veendub serveri ehtsuses. Serveril on kaks RSA võtit: salajane ja avalik. Et klient saaks veenduda, serveri ehtsuses peab ta eelnevalt teadma serveri avalikku võtit. Teatavasti on avaliku võtme krüptograafia kõige nõrgemaks kohaks avaliku võtme edastamine selle kasutajale. Selle võib klient saada, nt disketil, serveri administraatori käest isiklikult, kuid levinum on riskantsem viis. Nimelt esmakordsel ühendusevõtmisel usaldab klient serverit. Saades serveri avaliku võtme ning kliendi so kasutaja nõusoleku, lisatakse see faili ~/.ssh/known_hosts. Kui edaspidi võetakse ühendust sama serveriga, siis on võimalik juba kasutada standardset avaliku võtme krüptograafiat:

Server genereerib ja krüptib juhusliku järgnevuse (ingl. k. challenge) oma salajase võtmega ja saadab selle kliendile. Klient püüab saadetist lahti krüptida tema käsutuses oleva vastava avaliku võtmega. Kui see õnnestub, on server ehtne; kui mitte, siis on server võlts või on ta vahepeal endale uud võtmed tekitanud. Klient saadab serverile tagasi ühe võtmega krüptimise shifri nime (DES, 3DES, IDEA) ja serveri avaliku võtmega krüpteeritud sessioonivõtme. Saadetis on avatav ainult vastava salajase võtmega, mis on eeldatavasti vaid õigel serveril. Edasine infovahetus serveri ja kliendi vahel toimub üle krüptitud kanali, kusjuures mõlemad pooled kasutavad kokkulepitud shifrit ja sessioonivõtit.

Andmevahetuse alustamist kirjeldab pilt

kus

Diffe-Hellmani võtmevahetuse protseduuri abil lepitakse kokku salajane võti

Server veendub kliendi ehtsuses. Esmalt püütakse kasutajat autentida automatiseeritud viisil. Kui see ei õnnestu, kontrollitakse kasutaja UNIXi parooli, kasutades loodud turvalist kanalit.

Praktiliselt algatab klient serveriga ühenduse käsuga ssh, näiteks

gnoom~$ ssh -l priit reptilus.zoo.tartu.ee
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'reptilus.zoo.tartu.ee' added to the list of known hosts.
Creating random seed file ~/.ssh/random_seed. This may take a while.
priit@reptilus.zoo.tartu.ee's password:
reptilus~$

Seejuures:

tekitatakse kliendile kataloog ~/.ssh milles sisalduvad SSHle olulised failid,
serveri avalik võti lisatakse faili ~/.ssh/known_hosts,
tekitatakse SSH sisemisteks vajadusteks juhuslikku alget sisaldav fail ~/.ssh/random_seed,
küsitakse kasutaja UNIXi parooli, kuna kasutaja RSA võtmetega automaatne autentimine ebaõnnestus.

Tulemusena saadi äsjases näites ette teise masina viip ja võiks hakata seal toimetama. Sarnase tulemuse oleksite võinud saada telnetiga, kuid SSH abil tekitatud ühendust krüptitakse.

Seansi lõpetamine toimub tavalisel moel välja-logimisega

reptilus~$ logout
gnoom~$

Niisiis, SSH klient teeb SSH serveri avaliku võtme abil kindlaks SSH serveri ehtsuse ja seejärel SSH server autendib kasutaja.

Märkus: Kujutleme olukorda, kus teil on harjumus külastada SSHga mõnda masinat ning te ühtäkki märkate sisselogimisel, et server vastab teile hoiatava veateatega, öeldes, et serveri avalik võti ei klapi, pakkudes aga teile võimalust jätkata sisselogimist. Sama toimub ka igal järgmisel korral. Sel juhul on kaks võimalust:

Te suhtlete võltsserveriga ning ei tohiks sisselogimist jätkata. Tuleks muude vahenditega kindlaks teha, mis täpselt toimub.
Server on õige, kuid ta kasutab uusi RSA võtmeid. Sel juhul peab kasutaja oma ~/.ssh/known_hosts failist vastava serveri avaliku võtme rea käepärase tekstiredaktori abil kustutama. Järgmisel külastusel kirjutatakse sinna faili uus serveri avalik võti.

SSH kliendi seadistamine

SSH klienti tööd saab juhtida kolmel moel, kusjuures esitatud nimekirja lõpupool asuvatel on kõrgem prioriteet

/etc/ssh/ssh_config - globaalne seadistusfail
~/.ssh/config - kasutaja seadistusfail
käsureal kasutatud suvandid

Seadistusfailis saab Host parameetrile järgnevate ja enne järgmist Host parameetrit asuvate direktiividega kehtestada kuidas SSH klient käitub esimese Host parameetriga klappivate arvutite SSH serveritega. Lisaks, toimib esimene direktiivi väärtustamine, st et täpsemad määratlused tuleb teha seadistusfaili alguses ning üldisemad lõpus. Näiteks selline /etc/ssh/ssh_config

Host 192.168.10.0/24
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes

Host *
  ForwardX11 yes
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials no
  SendEnv LANG LC_*
  HashKnownHosts yes

kehtestab, et

Kerberose piletite kasutamine ja edasiandmine on lubatud 192.168.10.0/24 võrku kuuluvate arvutitega
kõigi muude arvutitega suhtelemisel on Kerberose kasutamine keelatud
Kuna LANG ja LC_* keskkonnamuutujate osas ei ole esimeses Host sektsioonis midagi öeldud, siis viimases näidatud direktiivid kehtivad kõigi SSH serverite puhul

Kasututaja autentimine tema RSA võtmetega

Teatavasti pakuvad r-korraldused suhteliselt automaatset, kuid ebaturvalist autentimist. Näitame, kuidas eelmises punktis kirjeldatud sisselogimisele ja seansi krüptimisele lisaks korraldada SSH abil automaatset kasutaja autentimist.

Autentimine toimub kasutaja enda moodustatud RSA võtmepaari abil. Rääkides seonduvalt SSHga RSA võtmetest, tuleb teha vahet, millal kõneldakse SSH serveri RSA võtmepaarist ja kunas kasutaja RSA võtmepaarist.

RSA võtmete moodustamine

Esmalt moodustab kasutaja, näiteks priit@gnoom.zoo.tartu.ee endale RSA võtmepaari käsuga ssh-keygen

 $ ssh-keygen
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/mart/.ssh/id_rsa): 
 Enter passphrase (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/mart/.ssh/id_rsa.
 Your public key has been saved in /home/mart/.ssh/id_rsa.pub.
 The key fingerprint is:
 41:89:34:41:90:c1:6e:27:f1:89:a9:16:09:aa:71:41 mart@moraal
 The key's randomart image is:
 +--[ RSA 2048]----+
 |o.E+o*=o..       |
 |.oo.= .o.        |
 |o.o. +  .        |
 |o+  + o  .       |
 |o  . o  S        |
 |                 |
 |                 |
 |                 |
 |                 |
 +-----------------+

kus võtme moodustamisel päritakse kasutajalt RSA salajase võtme parooli; selle peab ta sisestama iga kord enne oma salajase võtme kasutamist.

Tulemusena tekitatakse kaks võtit:

~/.ssh/id_rsa - kasutaja RSA salajane võti
~/.ssh/id_rsa.pub - kasutaja RSA avalik võti

Pange tähele, et avaliku võtme faili sees teksti lõpus on kirjas, kellele see kuulub. Salajane võti on küll parooliga kaitstud, kuid võti peaks siiski olema vaid kasutajale endale loetav.

ssh-keygen võimaldab kasutada sellised võtmeid

-t rsa või -t dsa - kontrollib, kas moodustatakse rsa või dsa võti
-b 4096 - võtme pikkus
-f failinimi - millega algavad võtmetele vastavad failinimed, vaikimisi .ssh/id_rsa*

RSA avaliku võtme paigutamine SSH serverisse

Oma avaliku võtme peate te lisama külastatava (so. SSH serveri, nt reptilus.zoo.tartu.ee) masina faili ~/.ssh/authorized_keys ja salajase võtme jätma sinna, kuhu ta tekitati. Kuna ~/.ssh/authorized_keys faili sisu on kõigile loetav, pole avaliku võtme edastamisel vaja võtta tarvitusele erilisi ettevaatusabinõusid: peaasi, et võtme sisu jääks muutumatuks. Failis ~/.ssh/authorized_keys võivad sisalduda mitmed avalikud võtmed, igaüks eraldi real ning fail on ASCII kujul. Nii on võimalik külastada SSH serverit erinevatest klient-masinatest. Kõige lihtsam on teha ~/.ssh/identity.pub failist koopia ning see ftp abil SSH serverisse toimetada. Seal andke selle faili lugemis- ja kirjutamisõigus ainult endale

$ chmod 600 ~/.ssh/authorized_keys

Kui te nüüd külastate ssh'ga seda SSH serverit, siis esmalt klient autendib serveri varemkirjeldatud tavapärasel moel. Aga server autendib kliendi selliselt: server genereerib juhusliku järgnevuse baite ja krüptib need talle teadaoleva kasutaja avaliku võtmega klient kasutab ainult tal olemasolevat vastavat sajalast võtit ja krüptib saadetise lahti; tulemus saadetakse serverile tagasi server võrdleb esialgset järgnevust kliendi poolt lahti krüptituga ja nende identsuse korral loeb autentimise õnnestunuks ning kasutajale antakse ette viip.

Lisaks võtmele saab iga authorized_keys faili rea alguses kasutada man sshd tekstis kirjeldatud suvandeid, nt

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,\
  command="~/bin/skriptinimi.sh",from="192.168.96.138" ssh-rsa AAAAB3NzaC1y ....

kasutamise tulemusena peale kasutaja ssh võtmega sisselogimist täidetakse skript ~/bin/skriptinimi.sh.

Avaliku võtme paigutamist teisse arvutisse lihtsustab ssh-copy-id skript, nt

$ ssh-copy-id mart@ns.auul
mart@ns.auul's password: 
Now try logging into the machine, with "ssh 'mart@ns.auul'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

RSA võtmete kasutamine

Näide automaatsest kasutaja RSA võtmetega autentimisest

gnoom~$ ssh -l priit reptilus.zoo.tartu.ee
Enter passphrase for RSA key 'priit@gnoom.zoo.tartu.ee':
Last login: Thu Nov 11 11:16:09 1999 from mammal.zoo.tartu.ee
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of University of California. All rights reserved.
reptilus~$

Kuna kasutaja autentimisel läheb tarvis tema salajast võtit, siis küsitakse salajase võtme parooli; '-l kasutajanimi' on vajalik, kui kasutajal on teises masinas erinev kasutajanimi. Siiski, kui ka kasutajal on erinevad kasutajanimed erinevates 'teistes masinates', siis ei pruugi ta '-l' võtit kasutada. Selle asemel võib ta kasutajanime ja vastava teise masina nime ära näidata failis ~/.ssh/config; võib kirjeldada mitmeid SSH servereid:

Host reptilus.zoo.tartu.ee
User priidu
Host mammal.zoo.tartu.ee
User priidik

Näites autenditakse gnoomi kasutajat 'priit' masinas reptilus kasutajana 'priidu'; ja masinas mammal kasutajana 'priidik'. Niisiis, et gnoomist logida sisse mammalisse kasutajana 'priidik' piisab kirjeldatud konfiguratsioonifaili olemasolul anda käsk

gnoom~$ ssh mammal.zoo.tartu.ee

Niisiis, standardne UNIXi paroolikontroll on asendatud SSH vahenditega. Hoiatuseks märgime, et juhul, kui teine masin võimaldab vaid SSHga sisselogimist ja te olete oma authorized_keys faili seal moodustanud ning te eksite, nt. ei mäleta oma salajase võtme parooli, siis peate kuidagi eemaldama authorized_keys faili; või vähemalt sellele masinale vastava sissekande, kust te SSH serverit ebaõnnestunult külastada püüate. Loodetavasti on seda võimalik FTPga teha. Kui ei, peate paluma SSH serveri administraatorit.

Võtmete mälus hoidmine

Eelmises punktis nägime, kuidas korraldada kasutaja (enda) autentimist. Seejuures võib tunduda ebamugavana vajadus iga kord oma salajase võtme parooli sisestada. Tõsi, tehniliselt võite võtmete moodustamisel ka parooli panemata jätta (vajutades Enterit), kuid see oleks turvaline seni, kuni teie salajane võti kindlalt ainult teie valduses on. Tõsi, reeglina see nii ka on. SSH pakub võimaluse salajasi võtmeid kliendi masina mälus hoida kuigi ka see pole väga turvaline, kuid enamasti piisav praktiliseks kasutamiseks.

Selleks käivitatakse võtmete mälus hoidmise agendi abil programm, millele (ja millest käivitatud uutele programmidele) saab teha kasutaja salajase võtme kättesaadavaks. Näiteks koorik

gnoom~$ ssh-agent bash

kus uues shellis on muu hulgas kaks olulist keskkonnamuutujat kirjeldatud, nt selliste väärtustega

SSH_AGENT_PID=23280
SSH_AUTH_SOCK=/tmp/ssh-AFJwe23279/agent.23279

Kui sama kasutajana ja nende muutujate olemasolul käivitada ssh klient, siis ta automaatselt saab ligi kasutada kasutaja privaatset võtit. Seejuures on oluline, et ssh-agent ei anna võtit ennast nö küsijale välja, aga krüptib esitatud materjali ning tagastab tulemuse küsijale.

Eeldades, et te hoiate oma salajasi võtmeid failis ~/.ssh/indentity, saate nad mällu laadida korraldusega ssh-add

gnoom~$ ssh-add
Need passphrase for /home/priit/.ssh/identity (priit@gnoom.zoo.tartu.ee)
Enter passphrase:
Identity added: /home/priit/.ssh/identity (priit@gnoom.zoo.tartu.ee)

Nüüd saavad kõik uuest koorikust järgnevalt käivitatud programmid, näiteks ssh ja cvs, vajadusel kasutada mällu laaditud SSH RSA sajalasi võtmeid.

Mälus olevate salajaste võtmete vaatamiseks on korraldus

gnoom~$ ssh-add -l

Salajaste võtmete mälust eemaldamiseks on korraldus

gnoom~$ ssh-add -D

Agent forwarding

Kui ssh-agent kasutamisel tavaliselt saab teisse arvutisse siis ja sellega lõpeb, siis agent forwarding kasutamisel tekitatakse peale teisse arvutisse sinna /tmp kataloogi vastav unix soket ning teisest arvutist saab edasi logida kusjuures kasutatakse esimese arvuti ssh-agent'i teenuseid. ssh agent forwarding on tavaliselt vaikimisi välja lülitatud, kävitamiseks tuleb kasutad ssh kliendi juures nt -A võtit (ka serveri poolel peab olema AllowAgentForwarding sisse lülitatud, vaikimisi tavaliselt on)

gnoom~$ ssh -A mart@teine.arvuti

Seejuures tuleb arvestada nn ssh agendi kaaperdamise võimalusega, http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#sec. St kui teises arvutis saab pahatahtlik kasutaja (nt root) ligi /tmp kataloogi tehtud soketile, siis on tal võimalus igale poole sisse logida teie nimel kuhu te oma võtmega saaks (eeldusel, et teisest arvutist on võrguühenduse mõttes ligipääs olemas).

Mitme ssh võtmekomplekti kasutamine

Kui mingil põhjusel kasutaja ei usalda ühte ja sama ssh avalikku võtit kasutada mitmes muus arvutis, siis saab ta kasutada ka erinevaid võtmekomplekte. Täiendava võtmepaari genereerimiseks sobib öelda nt

$ ssh-keygen -b 4096 -t rsa -f .ssh/loomaaed

mille tulemusena tekitatakse kaks faili

.ssh/loomaaed
.ssh/loomaaed.pub

Alternatiivse võtme kasutamiseks tuleb avalik osa loomaaed.pub kopeerida teisse arvutisse ning privaatset osa kasutada nt selliselt

$ ssh loomaaed.tartu.ee -i .ssh/loomaaed

Korralduste täitmine teises masinas

SSH võimaldab lasta korraldusi täita teises masinas, kasutades järgmist süntaksit

ssh -l kasutaja2 teise.masina.nimi käsk käsu-võtmed

kasutaja2 on kasutajanimi teises masinas, kelle õigustes seal tegutsetakse.

Sõltuvalt korralduse iseloomust võib väljund esituda ekraanil. Korralduse täitmisele eelneb varemkirjeldatud autentimine.

Anname näiteks teises masinas korralduse 'hostname -f'

gnoom~$ ssh -l kasutaja2 reptilus.zoo.tartu.ee hostname -f
reptilus.zoo.tartu.ee
gnoom~$

või korralduse 'w'

gnoom~$ ssh kasutaja2@reptilus.zoo.tartu.ee w
12:10PM     up 9 days, 21:18, 8 users, load averages: 0.02, 0.03, 0.00
USER    TTY        FROM       LOGIN@   IDLE       WHAT
mart    tty2       mammal     11:09AM  0:05       bash
gnoom~$

Paralleelselt on lubatud kasutada ka konstruktsiooni kasutajanimi@masina.nimi.

Mõned programmid, nagu näiteks mc eeldavad, et neile eraldatakse kauges masinas terminal, seda peab näitama võtmega -t

gnoom~$ ssh -t kasutaja2@reptilus.zoo.tartu.ee mc

Andmete kopeerimine

SSH võimaldab mitmel viisil andmed arvutite vahel kopeerida

scp
sftp
kasutada ssh stdio võimalusi

SCP

masinate vahel käsuga scp faile kopeerida järgmise süntaksi kohaselt scp võti kasutaja1@masin1.nimi:/kataloog1/failinimi1 kasutaja2@masin2.nimi:./kataloog2/failinimi2

Mõlemad argumendid koosnevad kahest osast, mida eraldab koolon (:)

masina nimi
failinimi

Kui failinimi algab punktiga (.), siis näitab see faili asukohta vastava masina kasutaja kodukataloogi suhtes; muidu on tegu absoluutse nimega.

Esimeseks argumendiks on kopeeritava faili nimi ja teiseks nimi, millega ta teises masinas salvestatakse.

Programm scp näitab kopeerimise ajal progressi. Kasutades võtit -A seda ei tehta.

Korralduse täitmisele eelneb eelkirjeldatud autentimine, kusjuures kehtivad võimalused võtmeid mälus hoida. Näiteks kopeerib kasutaja priit faili priidupilt.jpg teisest masinast kohalikku

gnoom~$ scp priidu@reptilus.zoo.tartu.ee:./public_html/priidupilt.jpg priidupilt.jpg
priidupilt.jpg | 6600 KB | 179.7 kB/s | ETA: 00:03:00 | 83%

Võimalik on kopeerida faile ka nö teise ja kolmanda masina vahel, see tähendab, et ei see, kust fail võetakse ega see, kuhu ta pannakse, pole masin, mille viip teil ees on

gnoom~$ scp priidu@reptilus.zoo.tartu.ee:./pilt.jpg priidik@mammal.zoo.tartu.ee:./pildid/pingu.jpg

SSH STDIO kasutamine

Failide kopeerimisel saab kasutada ka IOga manipuleerimist, näiteks kasutaja arhiveerib kataloogi ~/public_html sisu, pakib andmed ning saadab SSH abil üle võrgu teise masinasse; seal sisenetakse kodukataloogi ning harutatakse arhiiv lahti

 $ tar cf - ~/public_html | gzip | ssh reptilus.zoo.tartu.ee 'cd ~ && cat - > priidu.koduleht.tgz'

SFTP

Iseenesest on SFTP on SSH eraldiseisev protokoll, kuid praktiliselt on suure tõenäosusega kõige populaarsem SFTP protokolli kasutamine just SSH nn alamsüsteemina (ingl. k. subsystem).

Serveri poolel peab olema SFTP alamsüsteem seadistatud, nt

 Subsystem sftp /usr/lib/openssh/sftp-server

Enamasti on see juba kasutaja eest paika pandud

ja kliendi poolt kasutamiseks sobib öelda

 $ sftp arvutinimi
 sftp>

SFTP erinevusteks võrreldes scp'ga on

muuta teise arvuti failide metaandmeid, nt omanikke ja loabitte
peatada ja jätkata kopeerimist
põhimõtteliselt töötab andmevahetus pisut aeglasemalt

Lisaks nö käsureakliendile on mitmeid graafilise SFTP kliente, Windows operatsioonisüsteemile WinSCP nint Linuxile nt Filezilla

Oma RSA salajase võtme parooli muutmine

Oma salajase võtme parooli muutmiseks kasutage käsku ssh-keygen võtmega -p

gnoom~$ ssh-keygen -p
Enter file key is in (/home/priit/.ssh/identity):
Enter old passphrase:
Key has comment 'priit@gnoom.zoo.tartu.ee'
Enter new passphrase:
Enter the same passphrase again:
Your identification has been saved with the new passphrase.

Parooli muutmiseks on vaja vana parooli teada. Kui see on unustatud, tuleb genereerida uus RSA võtmepaar ning seda kasutama asuda.

Pordi edasisuunamine

Mitmetel põhjustel, näiteks turvalisus või kasutusmugavus võib olla abiks selle asemel, et pöörduda otse teenuse poole üle interneti aadress:port, pöörduda aadressile localhost:port.

Eemal asuva serveri pordi suunamine kohaliku masina localhost porti toimub käsuga

bash$ ssh priit@gnoom.zoo.tartu.ee -L 6565:localhost:5432

Selle tulemusena saab pöörduda localhost:6565 poole ning kasutada eemal asuva masina pordil localhost:5432 olevat teenust. Näiteks võiks sellest olla kasu kui gnoom.zoo.tartu.ee asub otse avalikus võrgus, aga seal töötav PostgreSQL andmebaas kuulab localhostil ning soovite andmebaasi kasutada kohalikus masinas töötava PgAdmin klientprogrammiga.

Kohaliku masin pordi 192.168.1.3:3306 suunamine eemal asuva arvuti gnoom.zoo.tartu.ee porti localhost:6565 toimub käsuga

bash$ ssh priit@gnoom.zoo.tartu.ee -R 6565:192.168.1.3:3306

Selle tulemusena saab eemal oleva masina kasutaja pöörduda enda arvuti localhost:6565 poole ning kasutaja teie kohaliku arvuti pordil 192.168.1.3:3306 töötavat teenust. Näiteks võiks sellest kasu olla kui teie töökohaarvutil ei ole avalikku ip aadressi ning te soovite kellelegi tutvustada mõnda oma arvutis töötavat programmi. Kusjuures 192.168.1.3 arvuti võib olla ka nö kolmas arvuti, st mitte see kus ssh programm käivitatakse. Nii saab kahe arvuti, millel otseselt ei ole üksteisele ligipääsu, vahel tekitada tcp ühenduse kolmanda arvuti (kus töötab ssh klient) abil.

NB! Tundub, et selline suunamine ei tööta kui ssh kliendi käivitamisel minnakse käsitsi üle hoiatustest, tõtt-öelda viimasel real nii öeldakse ka

Port forwarding is disabled to avoid man-in-the-middle attacks.

# ssh root@10.0.13.173 -R 1521:10.0.23.66:1521
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
41:9f:3f:2d:1b:c4:14:be:35:67:53:9d:59:cf:4c:06 [MD5].
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:730
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Port forwarding is disabled to avoid man-in-the-middle attacks.

Uuemad SSH versioonid võimaldavad lisaks localhostile seostada nii suunatud porte ka muude võrguliidestega.

Kuna portide suunamisel -L võtme kasutamisel hakkab ssh kuulama täiendavalt kohalik masina sellel pordil ning -R võtme kasutamisel hakkab kuulama täiendavalt kauge arvuti näidatud pordil, siis tuleb arvestada, et privilegeerimata kasutaja ei saa kasutada alla 1024 porte; -L puhul saab sarnase teate

 $ ssh mart@loomaaed.tartu.ee -L 222:localhost:22
 Privileged ports can only be forwarded by root.

Sessioonide multipleksimine

Kui ühel või teisel põhjusel on tarvis kasutada üle ühe tcp ühenduse (ingl. k. tcp connection) mitut ssh sessiooni, st mitu korda ühest ja samast ühest arvutist ühte ja samasse teise arvutisse pöörduda, siis sobib seda teha nn ssh ControlMaster abil. Esmalt moodustatakse ControlMaster ühendus, mille käigus tekitatakse soket failisüsteemi

ns:~$ ssh -Mt -S /tmp/ssh.imre.fs imre@fs.loomaaed.tartu.ee
fs:~$

Ning seejärel saab ssh ühendusi tekitada sarnaselt, nagu näha toimub järgmise ühenduse moodustamine oluliselt väiksema vaevaga

ns:~$ ssh -S /tmp/ssh.imre.fs imre@fs.loomaaed.tartu.ee -v
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: mux_client_request_session: master session id: 3
Last login: Mon Aug 22 20:34:14 2011 from moraal.auul
fs:~$

Sellisele asjakorraldusele on iseloomulik

järgmiste ühenduste tekitamine toimub kiiremini
võrgus on üks tcp ühendus
server poolel töötab vaid ühs sshd protsess

fs:~$ ps aux | grep 'sshd:'
imre     19383  0.0  0.3   8264  2744 ?        Ss   20:33   0:00 sshd: imre@pts/0,pts/1,pts/2

X rakenduste kasutamine üle võrgu

Teatavasti on Xi akende so programmide üle võrgu vedamine ebaturvaline, lisaks ka ebamugav, kuna peab paika sättima DISPLAY keskkonnamuutujat või näitama selle ära käsureal, näiteks

gnoom~$ gimp -display reptilus.zoo.tartu.ee:0

Peale selle on vaja Xserveris ära näidata käsuga xhost, milline kasutaja ja millisest masinast võib seal aknaid avada.

SSH teeb asja turvalisemaks ja lihtsamaks. Näiteks käivitame teise masina programmi xterm nii, et programm avaneb kohalikus Xserveris aknana: retpilus~$ ssh gnoom.zoo.tartu.ee /usr/X11R6/bin/xterm

Ning kui avanenud xterm'ist käivitada järgnevalt programme, toimub andmete liikumine samuti üle üle SSH kanali ning aknad avatakse selles Xserveris, kus see xtermi aken asub.

ssh serveri kasutamine läbi https proksi

ProxyTunnel http://proxytunnel.sourceforge.net/ tarkvara abil saab ssh kliendiga pöörduda ssh serveri poole läbi https proksi. See võib olla vajalik nt juhtumil kui klient asub võrgus, millest ei saa pöörduda välja muul viisil kui https proksi kaudu. Seejuures võib proksi küsida ka kasutajalt parooli. Kasutamiseks tuleb operatsioonisüsteemi vahenditega paigaldada pakett proxytunnel ning seejärel lisada ssh kliendi seadistusfaili

$ cat .ssh/config
...
Host ssh-tla
  ServerAliveInterval 30
  ProxyCommand /usr/bin/proxytunnel -p cache.teenusepakkuja.ee:3128 -d ssh.loomaaed.tartu.ee:443

kus

-p - teenusepakkuja host:port
-d - ssh serveri host:port

Kasutamiseks tuleb pöörduda ssh serveri poole kasutades config failis kasutatud Host väärtust

$ ssh priit@ssh-tla
Via cache.teenusepakkuja.ee:3128 -> ssh.loomaaed.tartu.ee:443
Linux ssh 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64
...
priit@rakendus:~$

Sellisele asjakorraldusele on iseloomulik, et ssh serveri poole peab saama pöörduda 443/tcp pordi kaudu, vastasel korral ei pruugi proksi ühendust moodustada. Lisaks, erinevalt nt httptunnel tarkvarast, millega saab sammuti kasutada http proksit tcp ühenduste pidamiseks, on ProxyTunnel puhul tarvis ainult nö kliendi poolel teha täiendavaid pingutusi.

Proks logis vastab ühele ssh ühendusele üks rida, nt

1331413631.677 180240 10.5.5.5 TCP_MISS/200 3570489 CONNECT ssh.loomaaed.tartu.ee:443 - DIRECT/10.47.218.19 -

kus

10.5.5.5 - kliendi ip
ssh.loomaaed.tartu.ee - nö veebiserveri st ssh serveri domeeninimi kuhu pöörduti
10.47.218.19 - nö veebiserveri st ssh serveri ip kuhu pöörduti
ProxyTunnel kasutab oma tööks http proxy CONNECT meetodit

Märkused

man ssh_config suvandeid saab kasutada käsurealt -o võtme abil, nt

 $ ssh -o UserKnownHostsFile=/tmp/known_hosts root@10.0.6.227

salvestab hosti avaliku võtme ~/.ssh/known_hosts asemel faili /tmp/known_hosts, et ühekordse sisselogimise vajaduse pärast mitte risustada kasutaja known_hosts faili.

Kui võrk ssh kliendi ja serveri vahel nö tapab idle olekus ssh ühendusi, maksab kasutada kliendi /etc/ssh/ssh_config failis parameetrit

ServerAliveInterval 30

Võtmevahetuse ja krüptimise algoritmid

Paistab, et 2017 aastal kasutatakse vaikimisi igasugustes linux distributsioonides ssh kliendi ja serveri vahel

võtmevahetuse algoritm (KexAlgorithms) - curve25519-sha256
host key algorithm (HostKeyAlgorithms) - ecdsa-sha2-nistp256
sümmeetrilise krüptimise algoritm (Ciphers) - chacha20-poly1305@openssh.com
sümmeetrilise krüptimise juures kasutatav räsimise algoritm (MACs) - <implicit> peaks tähendama, et see tuleneb chacha20-poly1305@openssh.com algoritmist

Vaikimisi

$ ssh  imre@192.168.10.123 -v
...
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

Konkreetsete algoritmide kasutamist saab täpsustada nt selliselt (lisaks on sisse lülitatud pakkimine)

$ ssh -C imre@192.168.10.123 -v -o Ciphers=aes128-ctr -o KexAlgorithms=diffie-hellman-group-exchange-sha256 -o MACs=hmac-sha2-512
...
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-512 compression: zlib@openssh.com
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-512 compression: zlib@openssh.com

Tundub, et nende kolme parameetri suvalisi väärtusi ei saa omavahel kombineerida. Võimalike väärtuste nimekirja saab esitada

võtmevahetus

$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256@libssh.org

sümmeetriline krüptimine

$ ssh -Q cipher
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

sümmeetrilise krüptimise juures kasutatav räsimine

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

digital signature scheme

$ ssh -Q key
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com

Kasulikud lisamaterjalid

Fetchmail
SSH üle PPP kanali
PGP
SSH kasutajate chrootimine libpam-chroot mooduli abil Debian Lennyga
WinSCP kasutamine
Openssh chroot Kasutaja chrootimine openssh patchi kasutades kodukataloogi
OpenSSH_administreerimine
http://www.snailbook.com/index.html