Secure your connections with SSH

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:

AboutTheAuthor

Bernard, 1972'den beri CNRS ( Fransız Ulusal Araştrma Merkezi )'nde Sistem ve Ağ Mühendisi olarak çalışmaktadır."Institut National de Physique Nucléaire et de Physique des Particules" (In2p3)'de bilgisayar sistemleri güvenliği ile görevlidir.Şu an, Fizik ve Matematik Bölümü'nün Matematik Araştırma Enstitüsü'nde çalışıyor.

Abstract

Bu makale ilk defa Linux Magazine France'ın güvenlik üzerine olan bölümünde yayınlanmıştır.Editör, yazarlar ve tercümanlar, bu konu hakkındaki her makalenin LinuxFocus'ta yayınlanmasına izin vermişlerdir.LinuxFocus, bunları İngilizce'ye çevirir çevirmez size sunar.Bu işle ilgili bütün kişilere teşekkür ederim.Bu tanıtım, bu kökene ait bütün makalelerde yer alacaktır.
Bu makalede size SSH'i ve onun nasıl kullanıldığını anlatacağız.Bu bir kullanma klavuzu ya da yükleme prosedürü değildir.Daha çok özel sözcüklerin anlamını ve SSH'in özelliklerini anlatır.Verilen linkler ve dökümanlar, SSH'in kullanımı hakkındaki bütün bilgileri içerir.

ArticleIllustration:

ArticleBody:

SSH Ne İçin Kullanılır ?

Öncelikle ( ve kronolojik olarak), SSH (ssh komutu), rsh ( ve rlogin ) komutlarının güvenli biçimidir.rsh'ın "Remote SHell ( uzak kabuk )" anlamına geldiği gibi ssh de "Secure SHell ( güvenli kabuk )" anlamına gelir.rsh size kullanıcı yetkilendirmesi istemeden uzak kabuğa izin verir.ssh de aynı servisi sağlar ancak yüksek ve çoklu seviyeli güvenlik içerir.
Eğer bu konu hakkında fazla bilginiz yoksa, yapcağınız tek şey telnet,rsh ve rlogin gibi komutların yerine ssh kullanmaktır.Herşey aynı şekilda çalışacaktır ancak daha güvenli bir şekilde.
Yani,

% rlogin serveur.org (or telnet serveur.org)

yerine

% ssh serveur.org

kullanacaksınız.
SSH'in basit kullanımından kaynaklanan güvenlik kazaları daha çok kurbanların ihmallerinin sonucudur.

Gerekenler Nelerdir ?

Aşağıda bağlantıların bazı çok önemli durumları hakkında öneriler vardır:

Ağ üzerinden şifre göndermekten kaçının.
Bağlı sistemlerde güçli yetkilendirme kullanın.
Uzak komutları tam güvenlik içinde çalıtırın.
Dosya transferini koruyun.
Güvenliği zayıf olan X11 oturunlarının güvenliğini artırın.

Bunlara karşlık yeterli olmayan bazı çözümler:

"R-komutları" : BU komutlar şifreyi açık şekilde göndermez ancak "rhosts" mekanizması güvenlik sorunlarına sebep olur.
"Tek kullanımlık Şifreler": Sadece yetkilendirmeyi komtrol eder, veri akışını değil.Bu yöntemin çekici bir önü olmasına rağmen kullanıcılara kabul ettirmek zordur.
Şİfrelenmiş(encrypted) telnet: BU sadece telnet ile işe yarar.Bunun dışındakileri (X11 gibi) kapsamaz.

Ve işte SSH, güzel bir çözüm:

R-komutlarını değiştirir: rsh ve rlogin yerine ssh, rcp yerine scp, ftp yerine sftp.
Sıkı yetkilendirme kullanır.Açık anahtarlar kullanarak şifreleme algoritmalarına dayanır (ister sistemler için, ister kullanıcılar için).
X11 ve "tünel" otumunda TCP veri akışını yönlendirme.Bu otomatik olarak yapılabilir.
Tüneli şifreleme.İstenildiğinde sıkıştırma da yapar.

SSH Sürüm 1 ve SSH Sürüm 2

Bu dünyada hiçbir şeyin mükemmler olmadığı gibi iki uyumsuz SSH protokolü sürümü vardır: 1.x sürümü (1.3 ve 1.5) ve 2.0 sürümü.Kullanıcı için bir versiyonda diğerin geçmek zor değildir.Hem sunucuda hem istemcide aynı versiyonun olması yeterli.
SSH sürüm 1 birleşiktir ancak SSH sürüm 2 üç katmandan oluşur:

SSH Ulaşım Katmanı Protokolü (SSH-TRANS)
SSH Yetki Protokolü (SSH-AUTH)
SSH (Bağlantı Protokolü (SSH_CONN)

Her protokol katmanı, IETF ile normalleştirilmiş dökümanlarda tanımlanmıştır.Yapıyı açıklayan dört döküman vardır.Bunları http://www.ietf.org/html.charters/secsh-charter.html
Detaylara girmeden SSHv2'de neler var bir bakalım:

Ulaşım katmanı, bütünlüğü, şifrelemeyi, sıkıştırmayı ve sistemin yetkilendirmesini sağlar.
Yetkilendirme katmanı yetkilendirmeyi sağlar ( şifreler,açık anahtarlar )
Bağlantı katmanı, tüneli (kabuk, SHH-agent,port yönlendirme, akış kontrolü) yönetir.

SSH sürüm 1 ve 2 arasındakü teknik farklar şunlardır:


SSH sürüm 1	SSH sürüm 2
Monolitik ( bütünleşik ) dizayn	Yetkilendirmeyi, ulaşımı ve bağlantıyı katmanlara ayırma
CRC32 aracılığı ile bütünleşme (güvenli değil)	HMAC (hash şifrelemesi) ile şifreleme
Her oturum için yalnız bir oturum	Her oturum için sınırsız oturum sayısı
Sadece simetrik gizli sistem ile anlaşma, her iki tarafta yalnız bir anahtar ile tanımlama	Daha ayrıntılı anlaşma ( simerik gizli sistem, açık nahtar, sıkıştırma, ...) ve ayrı oturum anahtarları, her iki tarafta sıkıştırma ve bütünleşme
Açık anahtar için sadece RSA algoritması	Açık anahtar için RSA ve DSA algoritmaları
İstemci tarafından gönderilen oturum anahtarı	Oturum anahtarı için Diffle-Hellman protokolü aracılığıyla anlaşma
Oturum anahtarı bütün oturum boyunca geçerli	Yenilenebilir oturum anahtarı

Bir Sürü Anahtar ile Uğraşma

SSH anahtar türlerini hızlıca açıklayalım:

Kullanıcı anahtarı: Açık anahatarın ve gizli anahtarın (her ikisi de asimetriktir) derlemesinden oluşur. Kullanıcı tanımlamıştır ve kalıcıdır (diskte tutulur).Eğer açık anahtar yöntemi(ileride açıklanacaktır) kullanılmışsa bu anahtar kullanıcı yetkilenidirmesi için kullanılır.
Makina anahtarı: Açık anahatarın ve gizli anahtarın (her ikisi de asimetriktir) derlemesinden oluşur. Sunucu yönetici tarafından kurulum veya ayarlanma anında oluşuturulur ve kalıcıdır (diskte saklanır). Bu anahtar sistemler arası yetkilendirmede kullanılır.
Sunucu anahtarı: Açık anahatarın ve gizli anahtarın (her ikisi de asimetriktir) derlemesinden oluşur.Bir deamon tarafından oluşturulur ve her çalıştırılmada ve düzenli olarak değişir.Bu anahtar SSHv1'de oturum anahtarları değişimini güvenli yapmak için hafızada saklanır ( SSHv2'de, sunucu anahatarı yoktur.Değişimim güvenligi Diffle-Hellman protokolü tarafından sağlanır.)
Oturum anahtarı: Bu anahtar, iletişim kanalının güvenliğini sağlamak için simetrik şifreleme algoritması kullanılarak oluşturulur.Modern şifreleme ürünlerinde olduğu gibi, bu anahtar rastlantısal ve kısa ömürlüdür.SSHv1'de, her oturum için bir anahtar vardır ve her iki tarafta da bulunur.SSHv2'de, her iki tarafta farklı olan iki anahtar bulunur.

Kullanıcı, yukarıdaki anahtarların gizli anahtar kısmını koruyan bir geçişdeyimi(passphrase) atar.Bu koruma gizli anahtarı içeren dosyanı simetrik algoritmayla şifrelenmesiyle garantilenir.Bu dosyayı şifreleyen gizli anahtar, geçişdeyiminden türetilir.

Yetkilendirme Yöntemleri

Birçok kullanıcı yetkilendirme yöntemi vardır.Seçim, güvenlik politikalarında tanımlanan gereksinilere göre yapılır.Burada temel kategoriler bulunmaktadır:

"telnet benzeri":

Bu, geleneksel şifre yöntemidir:Bağlantı yapıldıktan ve kullanıcı kendisini tanımladıktan sonra şifre girmesi istenir.Bu şlifre, sunucu üzerinde daha önce bu kullanıcıya atanmış şifre ile karşılaştırılır.Buradaki problem (internet üzerinde astronomik sayılara ulaşan çalıntılara sebep olan) şifrenin neredeyse açık şekilde gönderilmesi.Elinde basit bir "sniffer" programı olna herkes bu şifreyi görebilir.Burada SSH de aynı şekilde çalışır (yeni başlayanlar için SSH'e geçmenin basit bir yolu,öğrenilmesi gereken daha fazla şey yoktur) ancak SSH'de şifre şifrelenerek gönderilir.

Bu yöntemden daha güvenli olanı ise "Tek kullanımlık şifre"dir:BU açıkça daha iyi ve daha güvenlidir.Fakat kullanım kısıtları yüzünden heryerde kullanılamaz.Şu şekilde çalışır:Kullanıcı ismini girdikten sonra sunucu sabit bir şifre sormak yerine bir "soru" sorar.Bu soru her seferinde farklıdır ve cevap da değişir.Cevabın öğrenilmesi önemli değildir çünkü bir daha kullanılmayacaktır.

"rhosts benzeri"

Bu durumda, tanımlama R-komutlarında olduğu gibi /etc/rhosts ya da ~/.rhosts gibi istemciyi doğrulayan dosyalardır.SSH, daha iyi tanımlama ve daha özel bir dosya (shosts) kullanır.Bu yeterince güveni değildir ve eğer tek çözüm değilse kullanılmasını tevsiye etmem.

Açık anahtar kullanılması :

Burada, yetkilendirme asimetrik şifrelemeye dayanır (arıntılar için şifreleme makalesine bakın; basitçe, SSHv1 RSA kullanır ve SSHv2 DSA kullanır).Kullanıcının açık anahtarı sunucuda, gizli anahtarı ise istemcide saklanır.Bu yöntemle, hiçbir gizli bilgi ağda görünmez ve asla sunuya gönderilmez.

Hala mükemmel güvenliğe ulşamdık çünkü bu yöntemde güvenlik kullanıcının ciddyetine bağlıdır ( bu sadece SSH'e özgü değildir, açık anahtarı olan bütün sistemlerde vardır); Açık anahtarın istemcide sıkıştırlımasından kaçınmak için, anahtar bir şifre (genellikle geçişdeyimi denir) ile korunur.Eğer kullanıcı kendi gizli anahtarını korumazsa, buna sahip olan kişi her yere ulaşabilir.Bu yüzden güvenlik kullanıcın ciddiyetine bağlıdır ve sunucu yöneticisinin gizli anahtarın düzgün korunup korunmadığından haberdar olması mümkün değildir.Bugün SSH ciddiyeti kontrol etmez.Örneğin;Eğer bir gizli şifre ev bilgisayarında geçişdeyimi kullanılmadan saklanırsa (evde kötü niyetli kişiler olmayacağından neden geçişdeyimiyle uğraşalım ki !!) ve bir gün bu bilgisayar tamire giderse ( gülmeyim, elektronik imzalar yaygınlaştıkça bunlar olacaktır), tamirci (oğlu veya arkadaşı) gizli şifreyi alabilecektir.

SSH'i ayarlamak SSHv1, SSHV2 ya da OpenSSH kullanımına ve hatta MacOS^tm ya da Windows^tm kullanımına göre değişir.Temel prensipleri ve adımları hatırlatalım:

Asimetrik anahtar çiftinin nasıl üertileceği (bunlar açık/gizli RSA veya DSA anahtar çiftidir), genellikle istemci üzerinde tanımlanır (eğer birden fazla istemci varsa birinde anahtar çiftini üretip diğrelerine kopyalabilirsiniz).Bazı MacOS^tm ya da Windows^tm istemcileri bu anahtarları üretecek programlara sahip değildir.Bunu için önce bir Unix istemcide bunları üretip sonra diğre istemcilere kopyalanmalıdır.
Yetkilendirme yapacak sunucuya açık anahtarın kopyalanması.Bunun için kullanıcının ~/.ssh dosyasındaki gerekli satırları, sunucuda aynı yere kopyalamak yeterlidir (dosya ismi SSH versiyonuna göre değişir,autorized_keys yada autorization gibi).
Hepsi bu...Eğer ayarlar sunucu seviyesinde daha fazla yetkilendirmeye gereksinim duyarsa, kullanıcı bağlanırken geçişdeyimini girmek zorunda kalacaktır.

Yetkilendirmeyi ilgilendiren bir kaç elemana göz atalım:

ssh-agent

Bir kişinin gizli anahtarını korumamasını bir nedeni de her bağlantı kurulduğunda anahtarın tekrar girilmesidir.Bağlantı arkaplanda çalışan scriptlerle kurulduğunda, anahtar kullanılamaz.Çaresi SSH ajanı(ssh-agent)'dır.Bu servis, sizin tarafınızdan çalıştırılır ve sizin kimlik bilgilerinizi (kullanıcı ismi/makina ismi/geçişdeyimi) saklar, bağlatı gerektiğinde bu bilgileri sizin için gönderir.İstemci tarafında, şifre sadece bir defa sorulur.

Kimsenin sizi gizli anahtarınızı korumak için zorlayamacağını biliyorsunuz ama bu ihmali yaptığınızda olacaklardan siz sorumlu olursunuz.

"ayrıntı" modu

Bazen bağlantı kullanıcının bilmediği bir sebepten dolayı kopar.Bu durumlarda -v (verbose/ayrıntı modu) seçeneğini ssh komutuna ekleyin.Bu durumda birçok ayrıntılı ileti alacaksınız.Birçok durumda giriş yapamamanız ve bağlantı kopmasının sebebini bulabilirsiniz.

Şifreleme Algoritmaları

Şimdi, iletişim kanalını şifreleme (saklı anahtar kullanarak) ve kullanıcı yetkilendirme (açık anahtar ile şifreleme) arasındaki farkı anlatalım.
Yetkilendirme için, sürüm 2 için RSA'yı veya DSA'yı seçebiliriz ve sürüm 1 için sadece RSA'yı seçebiliriz.Tarihsel olarak,bazı ülkelerde RSA patentli olduğundan DSA kullanılacaktı.2000 yılının yazı sonunda RSA'nın kullanımı serbestleştive kısıt ortadan kalkmış oldu.Hangisinin iyi hangisinin kötü olduğun hakkında bir fikrim yok (yalnızca DSA, "saf" NSA ürünüdür).
Simetrik şifreleme için, birçok seçenek vardır.Protokol, tek bir ortak algoritma kullanmaya zorlar:Üç anahtarlı üçlü-DES.Eğer sunucu ve iştemci ağlantı kuramazlarsa bu yöntemi kullanırlar.3DES, en az peformanslı algoritma olduğundan, önce daha iyi bir algoritma kullanmayı denerler.Bazı gereksiz ve eski (arc4,DES,RC4...) algoritmaları bir kenar koyup şunlarla kendmizi sınırlayacağız:

IDEA: 3DES'den daha performaslıdır.Lisans için bazı şartları vardır (Unix versiyonlarında neredeyse default alogritmadır.)
Blowfish: Çok hızlı ve güvenlidir.
AES: yeni standart (DES yerine gelmiştir).Ever her iki taraftada varsa bunu kullanın.Bu iş için yapılmıştır.

Protokolün "özel bir algoritma" kullanmaya izinvermise karşılık neden bu kadar çok algoritma olduğunu anlamamışımdır.Sence, zamanlan, AES standart olacaktır.

Port Yönlendirme, Tüneller

SSH, SSH oturumunda her TCP veri akışının yönlendirmesini "tünel" aracılığıyla yapabilir.Veri akışını, istemci ve sunucu portlarını yönetmek yerine, bağlantı sırasında oluşturuluan tünel ile yapar (takip eden diyagrama bakınız).
X11 protokolü için fazladan güç harcamadan yapılır.
Diğre akışlar için, her ikli tarafta komut satırı seçenekleri vardır:

Sunucu ve istemci arasında doğrudan bağlatı

(örnek: user@alice% telnet bob.org)

Yerel port yönlendirme(istemciden sunucuya)

örnek:user@alice% ssh -L 1234:bob.org:143 bob.org
Bu sistem, aliceçoeg'dan IMAP sunucusu olan bob.org'a ulaşımı sağlar.Dışarıdan yapılacak bağlantılar engellenecektir.Bağlantılar sadece alice.org üzerinde çalıştılıan IMAP istemcisinden yerel makinaların 1234. portuna yapılabilir.

(1) alice.org üzerindeki kullanıcı, SSH tünelini (bağlantısını) açar.
(2) alice.org üzerindeki kullanıcı, istemcinin yerel IMAP'ini yerel makinanın 1234. portuna erişecek şekilde ayarlar.

Uzaktaki portu yerel porta yönlendirme

örnek: root@alice% ssh -R 1234:bob.org:143 bob.org

Bu örnek de yukarıdakiyle aynıdır ancak uzak makinadaki port yönlendirilmiştir.Sadece root kullanıcı bu komutu kullanabilir ancak bütün kullanıcılar oluşturulan tüneli kullanabilir.

SSH'in bu özelliği bazen "zavallılar için tünel" diye adlandırılır.Buradaki zavallılığın anlamı, istemci tarafında yönetim yapamaktır.Sacede belirli durumlarda yerel portlar (port > 1024) çok az haklarla yönlendirilebilir.Diğer yönden, bazı haklar verilmiş prot yönlendirme yapmak için root hesabına ya da root haklarına sahip bir kullanıcı olmak gerekir.
IP ile olduğu gibi, herşeyi herşeyin içine koymak mümkündür.Sadece TCP akışını değil, PPP bağlantısını da yönlendirebilirsiniz.Bu IP içinde "gerçek" IP tüneli yapmamıza izin verir (şifrelenmiş olduğundan güvenlidir).Konu, bu makalenin sınırların aşar, ayrıntılı bilgi için Linux VPN-HOWTO yazısını okyabilirsiniz.
İlk akılda tutulacak şey telnet akışını yönlendirmek:Bu gereksiz görünebilir, SSH zaten telneh yerine bir bağlantı sunuyor.Bu yöntemle istenilen istemciye ulaşlabilir çünkü SSH, Windows^tm ve MacOS^tm gibi ortamlarda çalışmıyor olabilir.Örneğin,"Mindterm"'ün "terminal emülasyonu" (Java'nın SSH istemcisi, bütün modern sistemlerde çalışır) Java'nın performans dşüklüğünden yakınır:Bu istemciyi sadece SSH tüneli oluşturmak için kullanabilirsiniz.
Aynı şekilde, "xterm" gibi ( örneğin SSH'in otomatik X11 yönlendirmesi kullanarak) uzak bir istemci başlatarak, SSH'i X terminallerde kullanabilirsiniz.
Tünel, veri akışı -veriyi tüneli başlatan kişi göndermiyor olsa bile- olduğu sürece açık kalır.Bu yüzden "sleep" komutu yeni TCP bağlantısını yönlendiren SSH tüneli açarken yararlı olur.

% ssh -n -f -L 2323:serveur.org:23 serveur.org sleep 60

% telnet localhost 2323

... welcome to serveur.org ...
İlk komut bir tünel açar, sunucuda sleep 60 komutunu çalıştırır ve yerel 2323. portu uzaktaki 23. porta (telnet) yönlendirir.İkinci komut, yerel 2323. portta telne istemcisi çalıştırır ve sunucuya bağlanırken
şifrelenmiş tüneli kullanır.Sleep komutu birdakika sonra duracaktır.Telnet komutunu çalıştırabilmek için sadece bir dakikanız var.Ama tünel son istemci işini bitirene kadar açık kalacaktır.

Ana Dağıtımlar: ücretsiz olanlar

Farklı platformda farklı sunucu ve/veya istemci kullanacaksınız ve SSHv1 ile SSHv2 uyumsuzdur.Makalenin sonundaki referansalar diğer uygulamaları bulmanızda yardımcı olacaktır.Buradaki tabloda sadece ücretsiz ve yeterince stabil olanlar vardır.


ürün	platform	protokol	link	notlar
OpenSSH	Unix	sürüm 1 ve 2	www.openssh.com	ayrıntılar aşağıdadır
TTSSH	Windows^tm	sürüm 1	www.zip.com.au/~roca/ttssh.html
Putty	Windows^tm	sürüm 1 ve 2	www.chiark.greenend.org.uk/~sgtatham/putty	sadece beta sürümü
Tealnet	Windows^tm	sürüm 1 ve 2	telneat.lipetsk.ru
SSH secure shell	Windows^tm	sürüm 1 ve 2	www.ssh.com	ticari amaçlar dışında ücretsiz
NiftytelnetSSH	MacOS^tm	sürüm 1	www.lysator.liu.se/~jonasw/freeware/niftyssh/
MacSSH	MacOS^tm	sürüm 2	www.macssh.com
MindTerm	Java	sürüm 1	www.mindbright.se	sürüm 2 ticaridir

MindTerm'ün Java'nın platformdan bağımsız uygulamasıdır (sadece Jav runtime'a gereksinim vardır) ve iyi tasarlanmış WEB tarayıcında çalıştırlıbilen bir servlet'dir.Maalesef, bu mükemmel ürünün son sürümü ticaridir.

OpenSSH

Büyük ihtimalle unix/linux ortamlarında kullanılan tek dağıtımdır ( sürekli destek, kısa cevap süresi, açık-kod ve ücretsiz).

OpenSSH'in gelişimi, OpenBSD projesinde Tatu Ylonen'nin orjinal sürüm ile başladı (SSH 1.2.12).Şu an OpenSSH üserşnde iki grup çalışmakta.Biri sadace OpenBSD projesi için, diğeri ise diğer dağıtımları çıkarmak için çalışıyor.

Açık ve okunabilir kodları olmasına rağmen, beni rahatsız eden iki nokta var:

OpenSSH kendi şifreleme kütüphanesini, OpenSSL'i kullanır ve genelde bu kütüphane dinamik olarak bağlanmıştır.Bizim durumumuzda, bu şifreleme paketi iyi güvenlik seviyesine ve güvenilir özelliklere sahiptir ve bu paket, bana göre, bir önceki yaklaşımı tamamen yanlış kılar.Tabii ki bu kütüphaneye yapılacak bir saldırı pakete yapılmış olur.
OpenSSH, kendisine ait bazı hassah servileri kullanır ( örneğin, ratgele sayı üreteci).OpenSSL de olduğu gibi buradaki dış bağımlılar hakkında uyarıda bulunacağım.

Bence ( ki yalnız değilim), çokluplotrofm şifreleme ürünleri, platform ne olursa olsun kararlı ve sabit olmalıdır.Hatta paltformun belirli karakteristiklerini de göz önüne almalıdır.
Diğer rakiplerin ürünlerinin çok ve çekici olamamalarını normal karşılamalıyız.Eğer diğer ürünleri ele almazsak, OpenSSH en kötü ürün.Kodun tekrar tasarlanıf yazılması toplum için daha faydalı olacaktır.

Kötü Haber ...

SSH mucize yaratmaz.O ne için yapıldı ise onu en iyi şekilde yapar.Daha fazlası beklenmemelidir.Yetkilendirilmiş bağlantıları korumaz.Eğer hesap paylaşılmışsa, bir saldırgan aynı hesaptan bilgisayarınıza bağlanabilir.SSH, diğre pratik ve kolay güvenlik politikalarıyla birlikte mükemmeldir.Eğer biri SSH'i heryerde kullanmıyorsa, potansiyel bir risk oluşturur.Bir saldırgan bu şifreyi kullanup SSH ile bağlantı kurarsa hiçbir şekilde iz bırakmayacatır.
Saldırganlara kapılar açacak olan SSH deamonlarının sebep olacağı tehlikelerin kişileri endişelenmemesi gerekir:IP'de herşeyi herşeyin içine koymak mümkün.Firewall aracılığıyla önemli protokollerin uygunsuzluğunu da içerir: HTML tünelleri, ICMP tünelleri, DNS tünelleri...Eğer %100 güvenlik istiyorsanız, bilgisayarınızı açmayın.SSH, kullanımından kaynaklanan bazı "delik"leri vardır (mükemmle program olmadığından bazıları geçmişte düzeltilmiştir).Bazıları da protokolden kaynaklanmaktadır.Bu "delik"ler -bazılarının çok önemli oldukları bildirilmişse de- düzeltilmesi teknik olarak karmaşık olan zayıflıklardır.SSH kullanılarak kaçınılan güvenlik kazaları günlüktür ve SSH'in zayıflılığından kaynaklananlar bazen teoriktir.Şu yazıyı okumak inginç olacaktır: http://www.hsc.fr/ressources/presentations/mitm/index.html . Bununla birlikte yüksek güvenlik isteyen uygulamalar (bankacılık, askeriye..) bazı potansiyel açıkları göz önüne almalıdırlar.

"Man in the middle (ortadaki adam)" saldırısı:

Saldırgan, her iki tarafın da paketlerini durdurur ve kendi paketlerini gönderir.( senaryoları artırmak mümkündür: aradaki bağlantıyı kesip kendisinin gerçek istemci olduğuna inandırmak)

Sonuç

Girişte yazdığımı tekrarlyacağım:SSH, ne mucizeler yaratır ne de tek başına bütün güvenliği sağlar.Ama temel bağlanma yolarından (telnet, rsh...) daah iyidir.

Önemli Linkler

İlk iki kita SSHv1 ve v2'yi kapsar.

SSH: the Secure Shell

Daniel J. Barret & Richard E. Silverman
O'Reilly - ISBN 0-596-00011-1

Unix Secure Shell

Anne Carasik
McGraw-Hill - ISBN 0-07-134933-2

openssh: http://www.openssh.com

Eğer harcayacak paranız varsa, iyi bir başlangıç...

http://www.ssh.com

Korunan Kanalı Kötüye Kullanmak (SSHv1'deki rastgle padding kullanılarak yapılmış)

Burada, SSHv1'de (ve v2'de) rastgele padding kullanılarak yapılmış bir korunan kanalı nasıl kaldıracağımızı açıklayağız.Pranoyakları etkileyecek kalp krizlerinde sorumlu değilim.
SSHv1'in paketleri şu yapıdadır:


offset (byte)	isim	uzunluk (bytes)	tanımlama
0	boyut	4	paket boyutu,padding'siz alan boyutu,yani boyut=uzunluk(tip)+uzunluk(veri)+uzunluk(CRC)
4	padding	p =1 to 8	rastgele padding: boyut sekizin katı olacak şekilde ayarlanır
4+p	tip	1	paket tipi
5+p	veri	n (değişken >= 0)
5+p+n	doğrulama	4	CRC32

Sadece bir alan şifrelenmez: boyut.Şifrelen kısmın uzunluğu, paddingler kullanılarak daima sekizin katı yapılır.Paddingler daima kullanılır.Eğer son üç alanın boyutu sekizin katı ise 8 byte uzunluğunda padding kullanılır ( 5+p+n, modül 8'e göre kalan 0'dır).Şifreleme fonksiyonu C, simetrik ve CBC modunda olsun ve deşifreleme fonksiyonu C^-1 olsun.Kolay olsun diye sadece 8 byte paddingli paketleri alacağız.Bir paket geldiğinde, onu rastegele sayı ile padding yapmak yerine, C^-1(M) değerini yerleştireceğiz.M mesajını C fonksiyonuyla deşifre etmek ile kanalı şifrelemek aynı anlamdadır (aslında Mnin şifrelenmeden deşifre edilmesi matematiksel açıdan bi anlan içermez, ama pratik kullanımda bu konun detaylarına inmeyeceğim).Sonra paketin diğre işlemlerine devam ederiz, yani 8 bytelık şifreleme.

Sonuç şu olacaktır:

offset içerik
notlar

0 boyut
4 byte şifrelenmedi

4 8 byte padding (şifrelenmiş) yani C(C^-1 (M))

12... son tip,veri,CRC

Burada ilginç olan ne?İlk şifrelenmiş blok C(C^-1(M))'i içerir. C simetrik şifreleme fonksiyonu olduğundan C(C^-1(M)) =M
dir.İlk blok, şifrelenmiş veride deşifrelenmiş olarak gönderilir.Bunun anlamı, ağ üzerinde iletişimi dinleyebilen biri bilgileri nasıl kullanacağını bilir.
Üçlü-DES(168 bit) oturumunda, bu tip paketlerin sayısı üçtür.Bu bilgilerle bir ağ dinleyicisi bütün iletişimi deşifre edebilir.Anahtar gönderildiğinde, paddingleri pakete sokmadan önce "ön-şifreleme"ye artık gerek kalmz.Eğer biri daha çok bilgi eklemek isterse, herhangi boyutta padding kullanması mümkündür.
Bu korunmuş kanalın kullanımının bulunması asla mümkün değildir! Daha önce de belirtiğim gibi iletinin her elemanı şifrelerken dikkatlı olunmalıdır.Bulunamaz çünkü paddingler rastgeledir, doğruluk testini kullanamazsınız. Şifreleme ürünlerinde asla rastgele paddingler kullanmayınız.
Bu kanalı diğerlerinde daha tehlikeli yapan şey, SSH_MSG_IGNORE gibi şifrelenmiş anahtar bilgisin sahip olmadan kullanabileceğiniz iletilerdir.
Rastgele paddinglerin kötü etkilerinden korunmak için, kararlı paddingler kullanılmalıdır: genellikle " kendini tanımlayan paddingler" denir ve n. offset byte'ı n'i içerir.Rasgele paddingler, SSHv2'de vardır.Bir şeçimdir.
Sonuç olarak,burada sadece korunmuş kanalı eleştirdim.Çünkü SSH gibi çok güvenli olduğunu iddia eden bir ürünün gerçekten en üst düzeyde güvenlik sunması gerekir. Artık ticari ürünlerin bir çok açık içerdiklerini biliyorsunuz:Sadece açık-kod ürünleri birincil gereksinime izin verir.O da kodun incelenmesi ve bu incelem gerçekten gereklidir.

offset	içerik	notlar
0	boyut	4 byte şifrelenmedi
4	8 byte padding (şifrelenmiş)	yani C(C^-1 (M))
12... son	tip,veri,CRC