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; her iki yöntem de parolanızı ağ üzerinden okunabilir metin olarak gönderiyordu. Ağ trafiğini izleyebilen herkes parolayı okuyabiliyordu ve 1990'ların başlarında insanlar tam olarak bunu, geniş ölçekte yapıyorlardı.

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 inşa edildi 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 aslında 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 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 özellik eklemiştir: ana bilgisayar tabanlı güven (host-based trust). Bir sunucuya, belirli bir ana bilgisayardan gelen girişleri parola sormadan kabul etmesi talimatı verilebiliyordu. RFC, "Bir Uyarı Hikayesi" başlıklı bir bölümde şunları belirtir: "Güvenilir ana bilgisayarlardan parola kimlik doğrulamasını atlamak, sadece bir sistemin güvenliği ihlal edildiğinde, bu şekilde yapılandırılmış TÜM sistemleri savunmasız bırakır." Ayrıca bu güvenin ana bilgisayar adlarına (hostname) dayalı olduğunu, dolayısıyla bir DNS (alan adı sistemi) ihlalinin veya sahte bir adresin bu güveni geçersiz kıldığını belirtir.

Her iki tasarım da doğdukları ağ yapısına uygundu. İlk dönem Ethernet, paylaşımlı bir ortamdı: bir segmentteki her makine her çerçeveyi (frame) alır ve kendisine adreslenmemiş olanları 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, güvenliği ihlal edilen tek bir hesap, tüm bölüm için bir parola toplayıcısına dönüşüyordu.

Düzeltme içermeyen 1994 tarihli güvenlik uyarısı

3 Şubat 1994 tarihinde CERT, CA-94:01 numaralı "Devam Eden Ağ İzleme Saldırıları" başlıklı güvenlik uyarısını 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ı, yani kullanıcı adı ve parolanın taşındığı kısmı kaydediyordu.

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 düzeltme mevcut değildi, çü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 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 Temmuz 1995'te bunu ü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ılı olmasını sağladı. Oturum şifrelendiği için ağ segmentindeki bir dinleyici hiçbir işe yarar bilgi elde edemiyordu. Ayrıca sunucu, 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, iş akışını değil sadece alışkanlığı değiştirmeyi gerektiriyordu. 1995 yılının sonunda kullanıcı tabanı elli ülkede yaklaşık 20.000 kullanıcıya ulaştı. O yılın Aralık ayında Ylönen, yazılımı geliştirmek ve satmak amacıyla SSH Communications Security şirketini kurdu.

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

SSH bir iş koluna 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 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 üzerine 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, o 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 işini üstlendi. Sonuç, 1 Aralık 1999 tarihinde OpenBSD 2.6 ile birlikte sunulan OpenSSH 1.2.2 oldu.

Küçük bir işletim sistemi projesinin yaptığı 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ği, herhangi bir kısıtlama içermeyen bir lisans altında bu temel sistemin bir parçası olmak zorundaydı. Denetlenmiş kod ve kısıtlamasız bir lisans, diğer tüm işletim sistemi satıcılarının da tam olarak istediği ş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 sunuldu.

SSH-2 neden bir sürüm güncellemesi değil de yeni bir protokoldür

SSH-1, şifrelenmiş akışın bütünlüğünü, saldırılara 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 kullanıldığında, 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. Uygulamalar bunun yerine, deattack.c adlı bir dosyada saldırıyı gerçekleştiği anda tanımaya çalışan bir tespit mekanizması (detector) ile dağıtıldı. Şubat 2001'de bu tespit mekanizmasının kendi içinde bir tamsayı taşması (integer overflow) barındırdığı keşfedildi (CVE-2001-0144); 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 bu yamalar kendi hatalarını da 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 hale gelmiştir. Bu tarihin geri kalanının büyük bir kısmı, 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 (hash tabanlı mesaj kimlik doğrulama kodu) taşındı; böylece MAC hesaplayamayan bir saldırgan paketi taklit edemez hale geldi. Anahtar anlaşması ise Diffie-Hellman yöntemine geçti. SSH-1'de istemci oturum anahtarını seçer ve sunucunun RSA anahtarlarıyla şifreleyerek 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 sayede trafiği bugün kaydedip ana bilgisayar anahtarını daha sonra çalmak hiçbir sonuç vermez. Bu özelliğe ileri yönlü gizlilik (forward secrecy) denir.

SSH-2, SSH-1 ile hiçbir ağ uyumluluğuna sahip değildir. Sayının ondalık bir artış yerine 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 gerçekleştirildi. 11 Ağustos 2015 tarihli 7.0 sürümü, protokol 1'i derleme aşamasında varsayılan olarak devre dışı bıraktı. 19 Aralık 2016 tarihli 7.4 sürümü, sunucu tarafındaki desteği tamamen kaldırdı. 3 Ekim 2017 tarihli 7.6 sürümü ise istemci tarafını, ilgili yapılandırma seçeneklerini ve dokümantasyonu sildi.

Eski ekipmanlar için bir seçenek olarak tutulması daha kullanıcı dostu bir tercih olabilirdi; ancak CRC-32 tespit mekanizması bu tercihin neden reddedildiğini açıklamaktadır. Taşma (overflow) hatasına yalnızca protokol 1 kodu derlendiğinde erişilebiliyordu ve bu kod, çoğu sistem yöneticisinin kendi sistemlerinde pasif durumda olduğunu düşündüğü bir yolda yer alıyordu. Dağıtılan (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 yanıt 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 teknik işleyişini merak ediyorsanız, SSH bağlantısı açıldığında ne olur bölümüne bakın.

İlk bağlantıda bir "önceki sefer" bulunmadığından, 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 uyuşmazlık durumunda programın verebileceği en yüksek sesli uyarıyı üretir:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 yapıldığı 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 istemi kontrol etmeden kabul eder; bu konuda dürüst olmakta fayda vardır.

Açık anahtarlar parolaları nasıl devre dışı bıraktı

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 bunun tam tersini yapar. SSH, parolayı şifreli kanal içinde taşısa bile sunucu gerçek gizli veriyi alır; bu nedenle ele geçirilmiş veya kötü niyetli bir sunucu, başka yerlerde size karşı kullanabileceği bir veriye sahip olur.

İkinci neden aritmetiktir. Genel bir IP adresi üzerinde 22 numaralı portu açık olan her sunucu, günün her saati otomatik giriş denemeleri alır ve parola tahmin edilebilir bir dizidir. Bir anahtar ise pratik anlamda tahmin edilemez. PasswordAuthentication no ayarının yapılması, bu tür saldırıların tamamını sona erdirir; bu nedenle her güvenlik sıkılaştırma kontrol listesinde yer alır. Anahtar oluşturma ve döndürme işlemleri SSH anahtar yönetimi temelleri bölümünde, sunucu tarafı ayarları ise bir VPS üzerinde SSH sıkılaştırma bölümünde ele alınmıştır.

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

Katmanlı bir protokol, yeni bir protokole ihtiyaç duymadan algoritmaların emekliye ayrılmasına olanak tanır. OpenSSH bu esnekliği sürekli kullanmaktadır ve sürüm tarihleri bu hızı göstermektedir.

Ed25519, 30 Ocak 2014 tarihinde OpenSSH 6.5 ile birlikte, chacha20-poly1305 şifreleyicisi ve bcrypt ile korunan özel anahtar formatıyla kullanıma sunulmuştur. 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 ilerlemiştir. OpenSSH 7.0, algoritmanın 160 bitlik ö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ırakmıştır. 1 Temmuz 2024 tarihli 9.8 sürümü, DSA'yı derleme zamanında devre dışı bırakmıştır. 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ırmıştır. Devre dışı bırakılmasından silinmesine kadar geçen süre on yıldır.

RSA ortadan kalkmamış ancak eski imza formatı kaldırılmıştır. 26 Eylül 2021 tarihli OpenSSH 8.8, SHA-1 ile oluşturulan RSA imzalarını varsayılan olarak kabul etmeyi durdurmuştur. 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 çakışmaları 50.000 USD'nin altında bir maliyetle elde edilebilmektedir. Eski bir sunucuya bağlanırken sign_and_send_pubkey: no mutual signature supported hatasıyla karşılaştıysanız, bunun nedeni bu değişikliktir. 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, bu kez tehdit ortaya çıkmadan önce işletilmektedir. Bugün yakalanan trafik, yeterli kapasiteye sahip bir kuantum bilgisayara sahip olan herhangi biri tarafından yıllar sonra saklanıp şifresi çözülebilir; bu nedenle anahtar anlaşma yönteminin, böyle bir makine var olmadan önce değişmesi gerekiyordu. 8 Nisan 2022 tarihli OpenSSH 9.0, hibrit anahtar değişimini varsayılan hale getirmiştir: sntrup761x25519-sha512@openssh.com, kuantum sonrası bir algoritmayı X25519 değişimi ile eşleştirir; böylece yeni algoritma beklentileri 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 kurulu mlkem768x25519-sha256 algoritmasını eklemiştir. OpenSSH 10.0 bunu anahtar anlaşması için varsayılan hale getirmiş ve projenin kuantum sonrası sayfası bu kararın gerekçesini açıklamıştır. 6 Ekim 2025 tarihli OpenSSH 10.1, karşı tarafın bu işlemi gerçekleştiremediği durumlarda uyarı vermeye başlamıştır:

** 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 dosyasındaki WarnWeakCrypto seçeneği ile kontrol edilir. Bunun pratikte ne anlama geldiği ve bu uyarıyı tetikleyen bir sunucuya karşı ne yapılması gerektiği kuantum sonrası SSH anahtar değişimi varsayılanları bölümünde ele alınmıştır.

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, sürümünün o dönem 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ınlanan 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. Bunu kontrol etmek, yeni bir VPS üzerindeki ilk on dakika içinde yapılması gerekenler arasındadır.

FAQ

SSH'i kim ve neden oluşturdu?

Helsinki Teknoloji Üniversitesi'nde araştırmacı olan Tatu Ylönen, 1995 yılında üniversite ağında gerçekleşen bir parola dinleme saldırısının ardından SSH'i yazdı. Dönemin uzak bağlantı araçları olan telnet ve rlogin, parolaları ağ üzerinden okunabilir metin olarak gönderiyordu; bu nedenle paylaşımlı bir ağ segmentini izleyen herkes, geçen kimlik bilgilerini toplayabiliyordu. Ylönen, programı Temmuz 1995'te ücretsiz yazılım olarak yayınladı. O yılın sonuna gelindiğinde 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 tek parça bir protokoldü. SSH-2 ise işi bir taşıma katmanı, bir kimlik doğrulama katmanı ve bir bağlantı katmanına (Ocak 2006, RFC 4251-4254) böler, bütünlük için HMAC kullanır ve oturum anahtarlarını Diffie-Hellman ile türetir. Bu sayede, ana bilgisayar anahtarı (host key) 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ştirilmesi 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 adıyla yeniden canlandırdı. OpenBSD ekibi ise OSSH'i çatallayarak (fork) OpenSSH'i oluşturdu ve 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 de taşınabilir (portable) dal aracılığıyla aynı uygulamayı kullanmasını sağladı.

SSH neden ilk bağlantıda ana bilgisayar anahtarını (host key) sorar?

Çünkü istemci o sunucuyu daha önce hiç görmemiştir ve anahtarını karşılaştırabileceği hiç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 dosyasında kayıt altına alır. İ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. Daha sonra karşılaşacağınız REMOTE HOST IDENTIFICATION HAS CHANGED mesajı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 bağlanırken sign_and_send_pubkey: no mutual signature supported hatası olarak görünür. Ocak 2014'te OpenSSH 6.5 ile kullanıma sunulan Ed25519 anahtarı, her iki sorunu da ortadan kaldırır.