Anda di halaman 1dari 4

Secure Shell atau SSH adalah protokol jaringan yang memungkinkan pertukaran data melalui saluran

aman antara dua perangkat jaringan. Terutama banyak digunakan pada sistem berbasis Linux dan Unix
untuk mengakses akun shell, SSH dirancang sebagai pengganti Telnet dan shell remote tak aman lainnya,
yang mengirim informasi, terutama kata sandi, dalam bentuk teks sederhana yang membuatnya mudah
untuk dicegat. Enkripsi yang digunakan oleh SSH menyediakan kerahasiaan dan integritas data melalui
jaringan yang tidak aman seperti Internet.

Definisi
SSH menggunakan kriptografi kunci publik untuk mengotentikasi komputer remote dan biarkan
komputer remote untuk mengotentikasi pengguna, jika perlu. SSH biasanya digunakan untuk
login ke mesin remote dan mengeksekusi berbagai perintah, tetapi juga mendukung tunneling,
forwarding TCP port dan X11 connections; itu dapat mentransfer file menggunakan terkait SFTP
atau SCP protocols. SSH menggunakan klien-server model. Yang standar TCP port 22 telah
ditetapkan untuk menghubungi server SSH. Sebuah klien program SSH ini biasanya digunakan
untuk membangun koneksi ke SSH daemon untuk dapat diremote. Keduanya biasanya terdapat
pada sistem operasi modern, termasuk Mac OS X, Linux, FreeBSD, Solaris dan OpenVMS.
Tersedia versi berpemilik, freeware dan open source untuk berbagai tingkat kerumitan dan
kelengkapan.

[sunting] Sejarah
Pada tahun 1995, Tatu Ylönen, seorang peneliti di Helsinki University of Technology, Finlandia,
merancang versi pertama protokol (sekarang disebut SSH-1) karena didorong oleh peristiwa
serangan pembongkaran sandi di jaringan universitas. Tujuan dari pembuatan SSH adalah untuk
menggantikan fungsi rlogin, TELNET, dan rsh protokol, yang tidak memberikan otentikasi kuat
atau menjamin kerahasiaan. Ylönen merilis SSH sebagai freeware pada bulan Juli 1995, dan tool
tersebut berkembang dengan cepat untuk mendapatkan popularitas. Menjelang akhir 1995, basis
pengguna SSH telah tumbuh hingga 20.000 pengguna di lima puluh negara.

Pada bulan Desember 1995, Ylönen mendirikan SSH Communications Security untuk
memasarkan dan mengembangkan SSH. Versi asli dari software yang digunakan SSH adalah
berbagai potongan perangkat lunak bebas, seperti GNU libgmp, tetapi versi yang dikeluarkan
oleh Secure SSH Communications semakin berkembang menjadi perangkat lunak berpemilik.

Pada tahun 1996, sebuah versi revisi protokol dirancang, SSH-2, yang tidak cocok dengan SSH-
1. Fitur SSH-2 mencakup kedua fitur keamanan dan peningkatan perbaikan atas SSH-1.
Keamanan yang lebih baik, misalnya, datang melalui algoritma pertukaran kunci Diffie-Hellman
dan pemeriksaan dengan integritas yang kuat melalui kode otentikasi pesan. Fitur baru dari SSH-
2 mencakup kemampuan untuk menjalankan sejumlah sesi shell melalui satu koneksi SSH.

Pada tahun 1998 ditemukan kerentanan yang digambarkan dalam 1,5 SSH sehingga
memungkinkan masuknya konten yang tidak sah ke dalam aliran data SSH terenkripsi karena
integritas data tidak mencukupi perlindungan dari CRC-32 yang digunakan dalam protokol versi
ini. Sebuah perbaikan (SSH Compentation Attack Detector) diperkenalkan ke dalam banyak
implementasi.

Pada tahun 1999, pengembang menginginkan versi perangkat lunak bebas untuk tersedia kembali
seperti rilis 1.2.12, yang lebih tua dari program ssh asli, yang terakhir dirilis di bawah lisensi
open source. OSSH Björn Grönvall ini kemudian dikembangkan berdasarkan basis kode ini. Tak
lama kemudian, para pengembang OpenBSD menggunakan kode Grönvall untuk melakukan
pengembanga yang lebih luas di atasnya, sehingga terciptalah OpenSSH, yang dimasukkan
dalam rilis OpenBSD 2.6. Dari versi ini, sebuah cabang "portable" dibentuk untuk dapat
memportingkan OpenSSH pada sistem operasi lain.

Diperkirakan, sejak tahun 2000, terdapat lebih dari 2.000.000 pengguna SSH.

Pada tahun 2005, OpenSSH adalah satu-satunya aplikasi ssh yang paling populer, yang diinstal
secara default dalam sejumlah besar sistem operasi. Sementara itu, OSSH telah menjadi usang.

Pada tahun 2006, protokol SSH-2 yang telah disebutkan di atas, diusulkan untuk menjadi Standar
Internet dengan penerbitan oleh IETF "secsh" work group dari RFC (lihat referensi).

Pada tahun 2008 sebuah kelemahan kriptografi ditemukan pada SSH-2 yang memungkinkan
pengambilan sampai 4 byte plaintext dari aliran data SSH tunggal di bawah kondisi khusus.
Namun hal ini telah diperbaiki dengan mengubah mode enkripsi standar OpenSSH 5,2.

[sunting] Penggunaan SSH


SSH adalah sebuah protokol yang dapat digunakan untuk berbagai aplikasi. Beberapa aplikasi di
bawah ini mungkin membutuhkan fitur-fitur yang hanya tersedia atau yang kompatibel dengan
klien atau server SSH yang spesifik. Sebagai contoh, menggunakan protokol SSH untuk
mengimplementasikan VPN adalah dimungkinkan, tapi sekarang hanya dapat dengan
implementasi server dan klien OpenSSH.

 untuk login ke shell pada remote host (menggantikan Telnet dan rlogin)
 untuk mengeksekusi satu perintah pada remote host (menggantikan rsh)
 untuk menyalin file dari server lokal ke remote host. Lihat SCP, sebagai alternatif untuk
rcp
 dalam kombinasi dengan SFTP, sebagai alternatif yang aman untuk FTP transfer file
 dalam kombinasi dengan rsync untuk mem-backup, menyalin dan me-mirror file secara
efisien dan aman
 untuk port forwarding atau tunneling port (jangan dikelirukan dengan VPN yang rute
paket antara jaringan yang berbeda atau menyambung dua wilayah broadcast menjadi
satu)
 untuk digunakan sebagai VPN yang terenkripsi penuh. Perhatikan bahwa hanya
OpenSSH server dan klien yang mendukung fitur ini
 untuk meneruskan X11 melalui beberapa host
 untuk browsing web melalui koneksi proxy yang dienkripsi dengan klien SSH yang
mendukung protokol SOCKS
 untuk mengamankan mounting direktori di server remote sebagai sebuah sistem file di
komputer lokal dengan menggunakan SSHFS
 untuk mengotomasi remote monitoring dan pengelolaan server melalui satu atau lebih
dari mekanisme seperti yang dibahas di atas

[sunting] Arsitektur SSH


SSH-2 protokol memiliki arsitektur internal (didefinisikan dalam RFC 4.251) pada lapisan
terpisah dengan baik. Yaitu:

 Lapisan transportasi (RFC 4253). Lapisan ini menangani pertukaran kunci awal dan
server otentikasi dan set up enkripsi, kompresi dan integritas verifikasi. Lapisan ini
memperlihatkan ke lapisan atas sebuah antarmuka untuk mengirim dan menerima paket
teks terang hingga masing-masing 32.768 byte (atau lebih yang diperbolehkan oleh
implementasi). Lapisan transportasi juga mengatur ulang pertukaran kunci, biasanya
setelah 1 GB data yang ditransfer atau setelah 1 jam telah berlalu, tergantung mana yang
lebih cepat.
 Lapisan otentikasi pengguna (RFC 4252). Lapisan ini menangani otentikasi klien dan
menyediakan sejumlah metode otentikasi. Otentikasi client-driven: ketika seseorang
diminta untuk memasukkan password, mungkin diminta oleh klien SSH, bukan
servernya. Server hanya menanggapi permintaan otentikasi klien. Metode otentikasi
pengguna yang sering digunakan meliputi:
o password: sebuah metode untuk otentikasi password secara langsung, termasuk
fasilitas yang memungkinkan sandi untuk diubah. Metode ini tidak
diimplementasikan pada semua program.
o kunci publik: sebuah metode untuk otentikasi berbasis kunci publik, biasanya
mendukung setidaknya pasangan kunci DSA atau RSA, pada implementasi lain
juga mendukung sertifikat X.509.
o keyboard-interactive (RFC 4256): sebuah metode serbaguna di mana server akan
mengirimkan satu atau lebih prompt untuk memasukkan informasi sehingga klien
menampilkannya dan mengirimkan kembali tanggapan oleh pengguna. Digunakan
untuk menyediakan otentikasi password sekali-waktu seperti S/Key atau SecurID.
Digunakan oleh beberapa konfigurasi OpenSSH dimana PAM bertindak sebagai
penyedia otentikasi host yang mendasar agar secara efektif dapat menyediakan
otentikasi password, namun kadang-kadang menyebabkan kegagalan untuk login
dengan klien yang hanya mendukung metode otentikasi password biasa.
o metode otentikasi GSSAPI yang menyediakan sebuah skema extensible untuk
melakukan otentikasi SSH menggunakan mekanisme eksternal seperti Kerberos 5
atau NTLM, menyediakan satu kemampuan sign on untuk sesi SSH. These
methods are usually implemented by commercial SSH implementations for use in
organizations, though OpenSSH does have a working GSSAPI implementation.
Metode ini biasanya digunakan pada implementasikan SSH komersial untuk
digunakan dalam organisasi, meskipun OpenSSH memang memiliki implementasi
kerja GSSAPI.
 Lapisan koneksi. Lapisan ini mendefinisikan konsep kanal, kanal permintaan dan
permintaan global menggunakan layanan yang disediakan SSH. Sebuah koneksi SSH
dapat melayani beberapa kanal secara bersamaan, masing-masing mentransfer data dalam
dua arah. Permintaan kanal tersebut digunakan untuk menyambungkan saluran data
spesifik secara out-of-band, seperti perubahan ukuran jendela terminal atau exit code dari
sebuah proses server-side. Klien SSH meminta sebuah port server-side untuk diteruskan
menggunakan sebuah permintaan global. Jenis saluran standar yang tersedia adalah:
o shell untuk terminal, SFTP dan request exec (termasuk transfer SCP)
o direct-tcpip untuk koneksi klien-ke-server yang diteruskan
o forwarded-tcpip for server-to-client forwarded connections forwarded-tcpip untuk
koneksi server-ke-klien yang diteruskan
 SSHFP DNS record (RFC 4255) menyediakan sidik jari kunci publik untuk membantu
memverifikasi keaslian host.

Fungsi lapisan transportasi sendiri sebanding dengan TLS; lapisan otentikasi pengguna sangat
extensible dengan metode otentikasi khusus; dan lapisan sambungan menyediakan kemampuan
untuk membuat banyak sesi sekunder ke dalam satu koneksi SSH, sebuah fitur yang sebanding
dengan BIP dan tidak tersedia di TLS.

[sunting] Peringatan keamanan


Sejak SSH-1 memiliki kelemahan desain yang melekat dan membuatnya rentan (misalnya,
terhadap serangan man-in-the-middle), sekarang umumnya dianggap usang dan harus dihindari
pengguannya dengan menonaktifkan fallback ke SSH-1 secara eksplisit. Sementara server dan
klien modern telah mendukung SSH-2, beberapa organisasi masih menggunakan perangkat lunak
tanpa dukungan untuk SSH-2, dan dengan demikian SSH-1 tidak selalu dapat dihindari.

Dalam semua versi SSH, penting untuk memverifikasi kunci publik sebelum menerimanya
secara valid. Menerima seorang kunci publik atttacker sebagai kunci publik yang valid memiliki
efek membuka password yang ditransmisikan dan memungkinkan serangan man in-the-middle.

Anda mungkin juga menyukai