SSH tarihçesi: Telnet'ten OpenSSH'e geçiş süreci

SSH tarihçesinin başlangıcı

SSH tarihçesi, çalınan parolalarla başlar. 1995 yılından önce uzak bir Unix makinesine giriş yapmak, telnet veya rlogin kullanmak anlamına geliyordu ve her ikisi de parolanızı ağ üzerinden okunabilir metin olarak gönderiyordu. Hattı izleyebilen herkes parolayı okuyabiliyordu ve 1990'ların başlarında insanlar tam olarak bunu, geniş ölçekte yapıyordu.

SSH, 1995 yılında yazılan ve ücretsiz olarak sunulan, bu soruna yönelik tek kişilik bir yanıttı. Protokol o tarihten bu yana bir kez yeniden oluşturuldu ve bugün neredeyse herkesin çalıştırdığı program, bir çatalın (fork) çatalıdır. Aşağıdaki tarihler önemlidir, çünkü atılan her adım belirli bir başarısızlığa verilmiş bir yanıttı.

Telnet ve rlogin gerçekte ne gönderiyordu

Telnet, Jon Postel ve Joyce Reynolds tarafından Mayıs 1983'te yayımlanan RFC 854 içerisinde tanımlanmıştır. TCP üzerinden taşınan bir terminal oturumunu tarif eder ve hiçbir şekilde şifreleme içermez. Yazdığınız her bayt, parolanız da dahil olmak üzere, yol üzerindeki herhangi bir cihazın okuyabileceği düz metin baytları olarak iletilir.

rlogin, Berkeley Unix'ten çıkmış ve daha sonra RFC 1282 (BSD Rlogin, B. Kantor, Aralık 1991) içerisinde belgelenmiştir. Okunabilir bir paroladan daha kötü bir şey eklemiştir: ana bilgisayar tabanlı güven (host-based trust). Bir sunucuya, belirli bir ana bilgisayardan gelen oturum açma isteklerini parola sormaksızın kabul etmesi talimatı verilebilirdi. RFC, "Uyarıcı Bir Hikaye" başlıklı bir bölümde şunları belirtir: "Güvenilen ana bilgisayarlardan parola kimlik doğrulamasını atlamak, sadece bir sistemin ele geçirilmesi durumunda bu şekilde yapılandırılmış TÜM sistemleri savunmasız bırakır." Ayrıca güvenin ana bilgisayar adlarına dayalı olduğunu, bu nedenle bir DNS (alan adı sistemi) ihlalinin veya sahte bir adresin bu korumayı etkisiz kıldığını da not eder.

Her iki tasarım da ortaya çıktıkları ağ yapısına uygundu. İlk dönem Ethernet, paylaşımlı bir ortamdı: bir segmentteki her makine her çerçeveyi alır ve kendisine gönderilmeyenleri görmezden gelmesi beklenirdi. Promiscuous mode (gelişigüzel mod) anlamına gelen, bu çerçeveleri görmezden gelmeyi bırakan bir makine, diğer herkesin trafiğini görebiliyordu. Binlerce öğrenciye shell hesabı veren bir üniversite ortamı eklendiğinde, ele geçirilen tek bir hesap tüm bölüm için bir parola toplayıcısına dönüşüyordu.

Çözüm içermeyen 1994 tarihli uyarı

3 Şubat 1994 tarihinde CERT, CA-94:01 numaralı "Devam Eden Ağ İzleme Saldırıları" başlıklı uyarıyı yayımladı. Bu uyarı, saldırganların internet genelinde on binlerce sistemin erişim bilgilerini ele geçirdiğini bildirdi. Saldırganların kullandığı araç, ağ arayüzünü promiscuous moda alıyor ve her yeni telnet, rlogin ve FTP oturumunun başlangıcını kaydediyordu; bu kısım kullanıcı adı ve parolayı taşıyan bölümdür.

CERT, sitelere ağ üzerinden erişilen tüm hesapların parolalarını değiştirmelerini tavsiye etti. Bu tavsiyeyi ilgili protokoller bağlamında değerlendirdiğinizde tuzak netleşir: Yeni parola, ilk kullanıldığı anda aynı hat üzerinden açık metin olarak geçer. telnet veya rlogin içerisinde herhangi bir çözüm bulunmuyordu, çünkü her iki protokolün de bu tür bir güvenlik önlemini uygulayabileceği bir mekanizması yoktu.

Helsinki'deki bir koklama saldırısı neden SSH'i doğurdu

1995 yılında Helsinki Teknoloji Üniversitesi'ndeki ağ, CERT'in daha önce tanımladığı türden bir parola koklama (sniffing) saldırısına uğradı. Orada araştırmacı olan Tatu Ylönen, bir alternatif yazdı ve bunu Temmuz 1995'te ücretsiz yazılım olarak yayınladı. Yazılıma Secure Shell adını verdi.

İki tasarım kararı yazılımın başarısını sağladı. Oturum şifrelendiği için ağ segmentindeki bir dinleyici hiçbir işe yarar bilgi elde edemiyordu. Sunucu ise kimliğini bir anahtar ile kanıtlıyordu; böylece istemci, doğru makineye ulaşıp ulaşmadığını anlayabiliyordu. Bu, rlogin'in ana bilgisayar adı güveninin açık bıraktığı bir güvenlik açığıydı.

Yazılımın yayılmasının bir diğer nedeni de komutların insanların zaten kullandığı komutlarla eşleşmesiydi. ssh, rsh ve rlogin yerine; scp ise rcp yerine kullanılıyordu. Geçiş yapmak bir iş akışı değişikliği değil, sadece bir alışkanlık değişimi gerektiriyordu. 1995 yılının sonuna gelindiğinde kullanıcı tabanı elli ülkede yaklaşık 20.000 kullanıcıya ulaşmıştı. O yılın Aralık ayında Ylönen, yazılımı geliştirmek ve satmak için SSH Communications Security şirketini kurdu.

Ücretsiz bir sürümden ticari bir ürüne

SSH bir ticari girişime dönüştükçe, kaynak kodun lisansı da değişti. Daha sonraki sürümler, diğer kişilerin kod üzerinde yapabileceklerini kısıtlayan hükümler içeriyordu ve herkesin özgürce yeniden kullanabildiği son sürüm ssh 1.2.12 oldu. Bunda uygunsuz hiçbir durum yoktur. Bu durum sadece dünyanın geri kalanının üzerine inşa edebileceği SSH sürümünün gelişiminin durduğu, ancak geliştirme sürecinin dünyanın geri kalanının takip edemeyeceği bir yerde devam ettiği anlamına geliyordu. Lisanslar hangi kodun hayatta kalacağına karar verir; bu, açık kaynak lisanslamanın modern altyapıyı nasıl şekillendirdiği konusunda okunmaya değer bir modeldir.

OpenBSD neden 1999 yılında OpenSSH'i çatalladı

1999 yılının başlarında Björn Grönvall, son özgür sürüme geri döndü ve içindeki hataları gidermeye başladı. OSSH olarak adlandırılan bu sürüm, yalnızca SSH 1.3 protokolünü destekliyordu.

OpenBSD projesi OSSH'i devraldı ve yeniden inşa etti. Projenin kendi beyanına göre; Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell ve Dug Song kodun temizlenmesi, denetlenmesi ve genişletilmesi çalışmalarını yürüttü. Ortaya çıkan OpenSSH 1.2.2 sürümü, 1 Aralık 1999 tarihinde OpenBSD 2.6 ile birlikte dağıtıldı.

Küçük bir işletim sistemi projesi tarafından yapılan bir çatallama neden neredeyse her makinede yerini aldı? Çünkü OpenBSD'nin ondan beklentisi buydu. OpenBSD, varsayılan yapılandırmasında güvenli olması amaçlanan denetlenmiş bir temel sistem sunar; bu nedenle şifreli uzaktan oturum açma özelliğinin, herhangi bir kısıtlama içermeyen bir lisans altında bu temel sistemde yer alması gerekiyordu. Kısıtlamasız bir lisans altındaki denetlenmiş kod, diğer tüm işletim sistemi satıcılarının da tam olarak ihtiyaç duyduğu şeydi. Damien Miller, Philip Hands ve diğerleri neredeyse hemen taşınabilir bir dal (portable branch) oluşturmaya başladılar; 10.5p1 gibi bir sürümdeki p ifadesi de buradan gelmektedir. OpenBSD temiz sürümü geliştirir, taşınabilir dal ise diğer her şey için gerekli olan yapıştırıcı kodları ekler. Unix'in bugün kullandığımız sistemlere bölünme süreci, bu yapıştırıcıya neden ihtiyaç duyulduğunun temel nedenidir.

İkinci protokol sürümü için destek kısa süre sonra geldi. OpenSSH 2.0, 15 Haziran 2000 tarihinde OpenBSD 2.7 ile birlikte dağıtıldı.

SSH-2 neden bir sürüm yükseltmesi değil de yeni bir protokoldür

SSH-1, şifrelenmiş akışın bütünlüğünü, saldırganlara karşı koymaktan ziyade iletim hatalarını yakalamak için tasarlanmış bir sağlama toplamı olan CRC-32 ile koruyordu. 1998 yılında CORE SDI'dan Ariel Futoransky ve Emiliano Kargieman, bunun maliyetini ortaya koydu. CBC veya CFB şifreleme modları ve bir CRC-32 denetimi ile, düz metnin sadece 16 baytını bilen bir saldırgan, alıcının gerçek olarak kabul edeceği seçilmiş şifreli metni araya ekleyebilir; bu da sunucuda komut çalıştırmak anlamına gelir.

Kusur protokolün kendisinde olduğu için, uyumluluğu bozmadan düzeltilmesi mümkün değildi. Yazılım sürümleri bunun yerine deattack.c adlı bir dosyada, saldırıyı gerçekleştiği anda tanımaya çalışan bir algılayıcı kodu ile dağıtıldı. Şubat 2001'de bu algılayıcının kendi içinde bir tamsayı taşması (integer overflow) içerdiği, yani CVE-2001-0144 olduğu keşfedildi; bu durum yamayı uygulayan sunucular ve istemciler üzerinde uzaktan kod yürütülmesine olanak tanıdı. Onarılamayan bir tasarım yamalar biriktirir ve yamalar da kendi hatalarını beraberinde getirir.

SSH-2, secsh adlı bir IETF çalışma grubunda geliştirildi ve Ocak 2006'da RFC olarak yayımlandı: mimari RFC 4251, taşıma katmanı RFC 4253, kullanıcı kimlik doğrulaması RFC 4252 ve bağlantı katmanı RFC 4254'te tanımlandı. Katmanlara ayrılma en önemli kısımdır, çünkü her katman kendi başına değiştirilebilir. Bu tarihin geri kalanının çoğu, bu değişimin gerçekleşmesidir.

İki değişiklik öne çıkmaktadır. Bütünlük denetimi CRC-32'den, paylaşılan bir gizli anahtarla oluşturulan HMAC'e (karma tabanlı mesaj kimlik doğrulama kodu) taşındı; böylece MAC'i hesaplayamayan bir saldırgan paketi taklit edemez. Anahtar anlaşması ise Diffie-Hellman yöntemine taşındı. SSH-1'de istemci oturum anahtarını seçer ve sunucunun RSA anahtarlarıyla şifrelenmiş olarak gönderirdi; bu nedenle daha sonra bu özel anahtarları ele geçiren herkes kaydedilmiş bir oturumun şifresini çözebilirdi. Diffie-Hellman, oturum başına asla iletilmeyen yeni bir gizli anahtar türetir; bu nedenle trafiği bugün kaydedip ana bilgisayar anahtarını daha sonra çalmak hiçbir sonuç vermez. Bu özelliğe ileri gizlilik (forward secrecy) denir.

SSH-2, SSH-1 ile hiçbir kablo uyumluluğuna sahip değildir. Sayının ondalık olarak değil de tam sayı olarak değişmesinin nedeni budur.

SSH-1 neden onarılmak yerine kaldırıldı

Kaldırma işlemi üç OpenSSH sürümü boyunca sürdü. 11 Ağustos 2015 tarihli 7.0 sürümü, protokol 1'i derleme zamanında varsayılan olarak devre dışı bıraktı. 19 Aralık 2016 tarihli 7.4 sürümü, sunucu tarafındaki desteği kaldırdı. 3 Ekim 2017 tarihli 7.6 sürümü ise istemci tarafını, yapılandırma seçeneklerini ve belgelerini tamamen sildi.

Eski ekipmanlar için bir seçenek olarak tutmak daha kullanıcı dostu bir tercih olabilirdi; ancak CRC-32 dedektörü, bu tercihin neden reddedildiğini açıklamaktadır. Taşma (overflow) durumu, yalnızca protokol 1 kodu derlendiği için erişilebilirdi ve bu kod, çoğu sistem yöneticisinin kendi sistemlerinde pasif olduğunu düşündüğü bir yolda duruyordu. Yayınlanan (ships) koda erişilebilir. Silinen koda ise erişilemez.

İlk SSH bağlantınızda neden host key uyarısı alırsınız

Şifreleme, trafiğin gizli olduğunu size bildirir. Ancak karşı tarafta kimin olduğunu doğrulamaz. Eğer bir saldırgan araya girer ve sunucunuzun yerine cevap verirse, saldırganla mükemmel şekilde şifrelenmiş bir oturum kurmuş olursunuz; buna machine-in-the-middle saldırısı denir. SSH buna bir host key ile yanıt verir: sunucu, bir anahtar çiftinin özel kısmına sahip olduğunu kanıtlar ve istemci, bu anahtarı bir önceki seferde kaydettiği değerle karşılaştırır. Bağlantının mekaniği hakkında bilgi almak isterseniz, SSH bağlantısı açıldığında ne olur bölümüne bakabilirsiniz.

İlk bağlantıda bir "önceki sefer" bulunmadığı için istemcinin karşılaştıracak bir verisi yoktur ve size şu soruyu sormak zorundadır:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Evet yanıtını vermek, bu anahtarı ~/.ssh/known_hosts içinde saklar. Sonraki her bağlantı, saklanan değerle karşılaştırma yapar ve bir uyumsuzluk durumunda programın verebileceği en yüksek sesli mesaj üretilir:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Bu ilk istemin dürüst bir okuması, protokolün tek zayıf anını kabul ettiğidir. "İlk kullanımda güven" (Trust on first use) prensibi, ilk bağlantının yalnızca üzerinde bulunduğunuz ağ kadar güvenli olduğu anlamına gelir. Bu açığı kapatabilirsiniz. Bağlanmadan önce sağlayıcınızın konsolundan veya sunucunun derleme günlüğünden (build log) parmak izini (fingerprint) okuyun. Bunu DNS üzerinde bir SSHFP kaydı (RFC 4255) olarak yayınlayın; ancak bu yalnızca DNSSEC kullanıyorsanız anlamlıdır. Alternatif olarak, host key'leri kendi sertifika yetkiliniz (CA) ile imzalayın; böylece istemciler her bir anahtara değil, CA'ya güvenir. Uygulamada çoğu kişi bu istemi kontrol etmeden kabul eder; bu konuda dürüst olmakta fayda vardır.

Açık anahtarlar parolaların yerini nasıl aldı

Açık anahtar kimlik doğrulaması, SSH'in ilk sürümlerinden beri mevcuttu ancak standart bir alışkanlık haline gelmesi yıllar sürdü. Mekanizma asimetriktir: istemci, bir sınamayı imzalayarak özel anahtara sahip olduğunu kanıtlar ve özel anahtar hiçbir zaman istemciden ayrılmaz. Parola ise tam tersini yapar. SSH, parolayı şifreli kanal içinde taşısa bile sunucu gerçek parolayı alır; bu nedenle ele geçirilmiş veya kötü niyetli bir sunucu, başka yerlerde size karşı kullanabileceği bir sırrı elde etmiş olur.

İkinci neden aritmetiktir. Herkese açık bir adreste 22 numaralı portu açık olan her sunucu, günün her saati otomatik oturum açma denemeleri alır; parola ise tahmin edilebilir bir karakter dizisidir. Kriptografik anahtar pratikte tahmin edilemez. PasswordAuthentication no ayarının yapılması bu saldırı kategorisinin tamamını ortadan kaldırır. Bu nedenle her güvenlik sıkılaştırma kontrol listesinde yer alır. Ancak anahtar çalışmadığında sizi kurtaran geri dönüş seçeneğini de kaldırır. Bu yüzden erişimi kilitlenen kişi olmadan önce, tümü Permission denied (publickey) bildiren çeşitli hataları birbirinden ayırt etmeyi öğrenin. Parola kullanmadan çalışmak, zamanla çok sayıda anahtar biriktirmek anlamına da gelir. Bir düzine anahtarı tutan bir agent, sunucu deneme sınırına ulaşıp bağlantıyı kapatana kadar her anahtarı sırayla dener. Bu durum, doğru anahtar yüklü olsa bile oturum açmanın neden Too many authentication failures hatasıyla başarısız olabileceğini açıklar. Anahtar oluşturma ve döndürme işlemleri SSH anahtar yönetiminin temelleri bölümünde, sunucu tarafı ayarları ise bir VPS üzerinde SSH güvenliğini sıkılaştırma bölümünde ele alınır.

SSH algoritma listesi neden sürekli değişiyor

Katmanlı bir protokol, yeni bir protokole gerek kalmadan algoritmaların emekliye ayrılmasına olanak tanır. OpenSSH bu esnekliği düzenli olarak kullanmaktadır ve sürüm tarihleri bu hızın göstergesidir.

Ed25519, 30 Ocak 2014 tarihinde OpenSSH 6.5 ile birlikte, chacha20-poly1305 şifreleyicisi ve bcrypt ile korunan özel anahtar formatıyla kullanıma sunuldu. Ed25519 imzaları, imza başına düşen nonce değerini deterministik olarak türetir; bu sayede imzalama anındaki zayıf bir rastgele sayı üreteci özel anahtarın sızmasına neden olamaz. DSA ve ECDSA özel anahtarlarının gerçek olaylarda ele geçirilme yöntemi tam olarak budur.

DSA ise ters yönde ilerledi. OpenSSH 7.0, algoritmanın 160-bit özel anahtar ve SHA-1 ile sınırlı olması nedeniyle 2015 yılında ssh-dss ana bilgisayar ve kullanıcı anahtarlarını çalışma zamanında devre dışı bıraktı. 1 Temmuz 2024 tarihli 9.8 sürümü, DSA'yı derleme zamanında devre dışı bıraktı. 9 Nisan 2025 tarihli 10.0 sürümü ise projenin kendi ifadesiyle "2015'te başlayan kullanımdan kaldırma sürecini tamamlayarak" algoritmayı tamamen kaldırdı. Devre dışı bırakılmasından silinmesine kadar geçen süre on yıl oldu.

RSA ortadan kalkmadı ancak eski imza formatı kaldırıldı. 26 Eylül 2021 tarihli OpenSSH 8.8, SHA-1 ile oluşturulan RSA imzalarını varsayılan olarak kabul etmeyi bıraktı. Sürüm notlarında bunun nedeni açıkça belirtilmiştir: SHA-1 kriptografik olarak kırılmıştır ve seçilmiş önek çarpışmaları 50.000 USD'nin altında bir maliyetle gerçekleştirilebilir durumdadır. Eski bir sunucuya bağlanırken sign_and_send_pubkey: no mutual signature supported hatası ile karşılaştıysanız, bu durum söz konusu değişikliğin sonucudur. Anahtarınızda bir sorun yoktur; karşı tarafın talep ettiği imza algoritması artık desteklenmemektedir.

Aynı süreç şu anda anahtar değişimi için de işlemektedir ve bu kez tehdit ortaya çıkmadan önlem alınmaktadır. Bugün yakalanan trafik depolanabilir ve gelecekte yeterli kapasiteye sahip bir kuantum bilgisayara sahip olan herhangi biri tarafından şifresi çözülebilir; bu nedenle anahtar anlaşma yöntemlerinin, böyle bir makine henüz mevcut değilken değiştirilmesi gerekiyordu. 8 Nisan 2022 tarihli OpenSSH 9.0, hibrit anahtar değişimini varsayılan hale getirdi: sntrup761x25519-sha512@openssh.com, kuantum sonrası bir algoritmayı X25519 değişimi ile eşleştirir; böylece yeni algoritma beklentiyi karşılamasa bile sonuç, klasik kısımdan daha zayıf olmaz. 19 Eylül 2024 tarihli OpenSSH 9.9, NIST tarafından 2024 yılında standartlaştırılan ML-KEM (modül kafes anahtar kapsülleme mekanizması) üzerine inşa edilen mlkem768x25519-sha256 desteğini ekledi. OpenSSH 10.0 bunu anahtar anlaşması için varsayılan hale getirdi ve projenin kuantum sonrası sayfası bu kararın gerekçelerini açıklamaktadır. 6 Ekim 2025 tarihli OpenSSH 10.1, karşı tarafın bu işlemi gerçekleştiremediği durumlarda uyarı vermeye başladı:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Bu uyarı varsayılan olarak etkindir ve ssh_config içindeki WarnWeakCrypto seçeneği tarafından denetlenir. Pratikte ne anlama geldiği ve bu uyarıyı tetikleyen bir sunucu için ne yapılması gerektiği post-quantum SSH anahtar değişimi varsayılanları başlıklı yazıda ele alınır. Uyarının kendisi sunucuyu işaret eder; ancak kendi istemci yapılandırmanızdaki bir KexAlgorithms satırı da post-quantum seçeneklerini aynı ölçüde devre dışı bırakabilir. Bu nedenle herhangi bir yükseltme yapmadan önce bağlantınızın gerçekte hangi anahtar değişimini müzakere ettiğini kontrol edin.

Bu geçmişin önünüzdeki sunucu için anlamı

Yazdığınız komut 1995 yılından bu yana neredeyse hiç değişmedi. Ancak altındaki hemen hemen her şey yenilendi: bütünlük denetimi, anahtar değişimi, imza algoritmaları ve kod tabanının kendisi. Bu durum, her yenilemenin bilinçli bir kaldırma işlemiyle sonuçlanması ve her kaldırma işleminin birileri için bir şeyleri bozması sayesinde mümkün oldu.

Dolayısıyla SSH güvenliğiniz büyük ölçüde sürümünüze bağlıdır. Varsayılan ayarlar; hangi algoritmaların sunulacağı, hangilerinin reddedileceği ve hangi uyarıları göreceğiniz konusundaki kararları içerir. Eski bir sunucu, kendi sürümünün izin verdiği her şeyi sunmaya devam eder ve eski bir istemciyle bağlantı kurmak için güvenlik seviyesini düşürmeye devam eder. Ağustos 2026 itibarıyla güncel sürüm, 11 Ağustos 2026 tarihinde yayımlanan OpenSSH 10.5'tir. Bu sürüm ile üç yıldır kimsenin dokunmadığı bir makinedeki sürüm arasındaki fark, sorunun boyutunu oluşturur. Bu sürümü kontrol etmek, yeni bir VPS üzerindeki ilk on dakika içinde yapılması gerekenler arasındadır.

FAQ

SSH kim tarafından ve neden geliştirildi?

Helsinki Teknoloji Üniversitesi'nde araştırmacı olan Tatu Ylönen, üniversite ağındaki bir parola dinleme saldırısının ardından 1995 yılında SSH'i yazdı. O dönemde kullanılan uzak oturum açma araçları telnet ve rlogin, parolaları ağ üzerinden okunabilir metin olarak gönderiyordu; bu nedenle paylaşımlı bir ağ segmentini izleyen herkes kimlik bilgilerini ele geçirebiliyordu. Ylönen, programı Temmuz 1995'te ücretsiz yazılım olarak yayınladı. Aynı yılın sonunda elli ülkede yaklaşık 20.000 kullanıcısı vardı ve Aralık 1995'te SSH Communications Security şirketini kurdu.

SSH-1 ve SSH-2 arasındaki fark nedir?

Bunlar, ağ üzerinde birbirleriyle uyumlu olmayan farklı protokollerdir. SSH-1, bütünlük için CRC-32 kullanan ve istemcinin sunucunun RSA anahtarlarıyla şifrelenmiş bir oturum anahtarı göndermesini sağlayan monolitik bir protokoldü. SSH-2 ise işi bir taşıma katmanı, bir kimlik doğrulama katmanı ve bir bağlantı katmanına (RFC 4251 - 4254, Ocak 2006) böler, bütünlük için HMAC kullanır ve oturum anahtarlarını Diffie-Hellman ile türetir; böylece ana bilgisayar anahtarı daha sonra çalınsa bile kaydedilen trafik gizli kalır. SSH-1, Ekim 2017'deki 7.6 sürümüyle birlikte OpenSSH'ten aşamalı olarak tamamen kaldırıldı.

OpenSSH neden orijinal SSH uygulamasının yerini aldı?

Orijinal SSH'in geliştirme süreci kısıtlayıcı bir lisansa sahip ticari bir ürüne dönüştü ve özgürce kullanılabilen son sürüm ssh 1.2.12 idi. 1999'un başlarında Björn Grönvall bu sürümü OSSH olarak yeniden canlandırdı ve OpenBSD ekibi OSSH'i çatallayarak (fork) OpenSSH'i oluşturdu; bu sürüm 1 Aralık 1999'da OpenBSD 2.6 ile birlikte dağıtıldı. OpenBSD'nin temel sistemi için kısıtlamasız bir lisans altında denetlenmiş koda ihtiyacı vardı; bu iki özellik, diğer tüm işletim sistemlerinin aynı uygulamayı taşınabilir dal (portable branch) üzerinden dağıtmasına olanak tanıdı.

SSH neden ilk bağlantıda ana bilgisayar anahtarını sorar?

Çünkü istemci o sunucuyu daha önce hiç görmemiştir ve anahtarını karşılaştırabileceği bir veri yoktur. Şifreleme tek başına dürüst bir sunucuyu yolun ortasında duran bir makineden ayıramaz; bu nedenle SSH, sunucuları anahtar ile tanımlar ve gördüğü değeri ~/.ssh/known_hosts içinde kaydeder. İlk bağlantı, kontrol edilecek kayıtlı bir değerin olmadığı tek andır; bu yüzden istemci size sorar. Parmak izini sağlayıcı konsolundan veya sunucunun kendisinden aldığınız değerle karşılaştırın ve daha sonra karşılaşabileceğiniz REMOTE HOST IDENTIFICATION HAS CHANGED mesajlarını, nedenini açıklayana kadar gerçek bir güvenlik olayı olarak değerlendirin.

Eski SSH anahtarları yükseltme sonrasında neden çalışmayı durdurur?

Çünkü OpenSSH, algoritmaları yayınlanmış bir takvime göre kullanımdan kaldırır. DSA (ssh-dss) anahtarları 2015 yılında OpenSSH 7.0 ile varsayılan olarak devre dışı bırakıldı ve 9 Nisan 2025'te OpenSSH 10.0 ile tamamen kaldırıldı. RSA anahtarları çalışmaya devam etmektedir, ancak SHA-1 ile oluşturulan imzalar Eylül 2021'de OpenSSH 8.8 ile varsayılan olarak devre dışı bırakılmıştır; bu durum eski bir sunucuya eriştiğinizde sign_and_send_pubkey: no mutual signature supported hatası olarak görünür. Ocak 2014'teki OpenSSH 6.5 sürümünden beri mevcut olan Ed25519 anahtarı, her iki sorunu da ortadan kaldırır.