SSH Nedir? Şifreli Yönetim ve Anahtar Tabanlı Giriş

SSH, uzaktaki bir cihazı yönetmenin bugünkü standart yoludur ve Telnet’in bıraktığı boşluğu doldurmak için değil, onun hiç taşıyamadığı güvenceleri getirmek için tasarlanmıştır. Şifreleme en görünür özelliğidir ama tek özelliği değil: bağlandığınız cihazın gerçekten o cihaz olduğunu da kanıtlar, ve parolayı hiç yazmadan giriş yapmanızı mümkün kılar.

Bu rehber protokolün mekanizmasına odaklanıyor: el sıkışmada ne olduğuna, cihazın kimliğini neyle kanıtladığına ve hangi varsayılan ayarın neden tehlikeli olduğuna. Kurulum adımları burada değil; ağ cihazında SSH’ı açıp Telnet’i kapatma sırası Telnet rehberimizde, Linux sunucuda sshd_config yapılandırması ise Ubuntu Server rehberimizde duruyor.

SSH Nedir ve Nasıl Çalışır?

SSH, açılımıyla Secure Shell, iki cihaz arasında şifreli bir yönetim kanalı kuran protokoldür. Adındaki “kabuk” kelimesi ne yaptığını da söylüyor: bir sunucunun ya da ağ cihazının komut kabuğunu kendi ekranınıza getirir. Dosya aktarımı da aynı kanaldan yürür ve tüm bunlar olurken hattı dinleyen birine hiçbir şey verilmez. Protokolün bugünkü sürümünü Ocak 2006 tarihli dört belge tanımlar: mimariyi RFC 4251, kimlik doğrulamayı RFC 4252, aktarım katmanını RFC 4253, bağlantı katmanını RFC 4254.

Telgrafın ilk yıllarında operatörlerin birbirini tanımak için kullandığı bir yöntem vardı. Her operatörün tuşa basış ritmi kendine özgüydü ve buna “el” denirdi. Karşı istasyondaki kişi konuşmayı okumadan önce, ritmi duyar duymaz kimin gönderdiğini anlardı. Ritim değiştiğinde ise anlaşılırdı: tuşun başında başka biri var.

SSH iki işi birden bu şekilde yapar. Mesajı kimsenin okuyamayacağı bir hatta sokar, ve karşı tarafın gerçekten o taraf olduğunu ritminden tanır. Bu yazının tamamı o ikinci iş üzerine, çünkü birincisi herkesin anlattığı, ikincisi ise neredeyse kimsenin girmediği taraf.

Protokolün üç ayrı görevi var ve bunları ayırmak, sonraki her bölümü kolaylaştırıyor:

1. Gizlilik. Kanal şifrelenir, hattı dinleyen bir şey okuyamaz.
2. Sunucu kimliği. Cihaz kendini kanıtlar, siz doğru makineye bağlandığınızı bilirsiniz.
3. Kullanıcı kimliği. Siz kendinizi kanıtlarsınız, parolayla ya da anahtarla.

Bu yazının bulduğu şey şu: SSH’ı açan kurumların çoğu birinci görevi çalışır hale getiriyor, ikinci ve üçüncüyü varsayılan haline bırakıyor. Ve varsayılan hal, göreceğiniz gibi, düşündüğünüz kadar iyi değil.

Port 22: El Sıkışma ve Anahtar Değişimi

SSH, TCP’nin 22 numaralı portunu kullanır. Bu da 0-1023 aralığındaki iyi bilinen portlardan biridir, yani tahsis edilmiş ve onlarca yıldır değişmemiştir. Pratik sonucu şu: bir tarama sonucunda ya da güvenlik duvarı kaydında karşınıza çıkan açık bir 22, neredeyse her zaman bir yönetim kapısıdır.

Bir cihazda portun açık olup olmadığını, hiçbir araç kurmadan da öğrenebilirsiniz:

timeout 3 bash -c "echo > /dev/tcp/192.168.1.2/22" && echo "acik" || echo "kapali"

Windows tarafında aynı işi PowerShell yapar:

Test-NetConnection 192.168.1.2 -Port 22

SSH portunu değiştirmeli misiniz?

Bu, hakkında en çok kesin konuşulan ve en az ölçülen sorulardan biri. Cevabı iki parçalı, ve iki parçayı karıştırmak yanlış karara götürüyor.

Değiştirmenin gerçek faydası gürültü azaltmaktır. İnternete açık her 22 portu, sürekli olarak otomatik tarayıcıların ve deneme botlarının hedefidir. Portu taşıdığınızda bu trafiğin büyük kısmı size ulaşmaz, kayıtlarınız okunabilir hale gelir ve gerçek bir olayı fark etme şansınız artar. Bu somut bir kazançtır.

Ama bir güvenlik denetimi değildir. Sizi hedef alan biri portu saniyeler içinde bulur; port taraması zaten bunun için var. Yani “portu değiştirdim, artık güvendeyim” cümlesi yanlıştır ve tehlikelidir, çünkü asıl işi yapması gereken üç ayarı ertelemenize sebep olur: anahtar tabanlı kimlik doğrulama, kabul edilen protokol sürümünün sınırlanması, ve erişimin nereden gelebileceğinin daraltılması. Üçü de bu yazının ilerleyen bölümlerinde.

Ağ cihazlarında da bu ayar mevcut. Lab switch’inde ip ssh altındaki seçenekler arasında port duruyor, yani yönetilebilir bir switch’te de portu taşımak mümkün. Taşıyacaksanız tek bir uyarı: yeni portu, eskisini kapatmadan önce deneyin. Aksi halde kendinizi cihazın dışında bırakırsınız, ki bu tuzağı Telnet rehberimizde yaşanmış bir örnekle anlattık.

Bağlantı üç aşamada kurulur ve sırası önemli, çünkü ilk aşama şifreli değildir.

Birinci aşama, sürüm anonsu. TCP el sıkışması biter bitmez iki taraf birbirine kendini tanıtan bir satır gönderir. Bu satır düz metindir, yani hattı dinleyen biri hangi yazılımın hangi sürümünü çalıştırdığınızı görebilir. Şaşırtıcı gelir ama tasarım gereğidir: taraflar hangi kuralları konuşacaklarına karar vermeden şifreleme başlayamaz.

Lab switch’inin 22 numaralı portuna hiçbir kimlik vermeden bağlanıp ilk satırı okuduğumuzda gelen cevap şu:

SSH-1.99-OpenSSH_6.5

Bu satır üç şeyi birden söylüyor ve üçü de giriş yapılmadan öğrenilebiliyor. Cihaz OpenSSH kullanıyor, sürümü 6.5, ve baştaki 1.99 bir uyarı işareti. 1.99 özel bir değerdir: “hem sürüm 1 hem sürüm 2 konuşabilirim” demektir. Yalnızca sürüm 2 destekleyen bir sunucu kendini SSH-2.0- diye tanıtır. Yani bu cihaz, kimse oturum açmadan önce, kırık kabul edilen sürümü desteklediğini ağa duyuruyor. Bu noktaya aşağıda geri döneceğiz.

İkinci aşama, algoritma müzakeresi. Burada iki taraf üç ayrı konuda mutabakata varır: anahtar değişiminin hangi yöntemle yapılacağı, sunucunun kimliğini hangi imza algoritmasıyla kanıtlayacağı, ve trafiğin hangi şifreyle korunacağı.

Mutabakatın kuralı üçünde de aynıdır. Her iki taraf da desteklediği seçenekleri tercih sırasına göre sunar, ortak kümeye bakılır ve o kümedeki en güçlü seçenekte anlaşılır. Yani sonucu tek bir taraf belirlemez; zayıf olan taraf tavanı belirler.

Bu cümle bu bölümün sonunda döneceğimiz tuzağın da özeti. Taraflardan biri eskiyse ortak küme daralır: müzakere ya iki tarafın da desteklediği eski bir seçenekte anlaşır, ya da hiç anlaşamaz ve bağlantı kurulmadan düşer.

Üçüncü aşama, anahtar değişimi. Asıl marifet burada. İki taraf, hattı dinleyen biri her baytı görse bile, ortak bir gizli anahtar üzerinde anlaşır. Gizli anahtarın kendisi hiçbir zaman gönderilmez; iki taraf da onu kendi tarafında hesaplar. Bu andan itibaren trafik şifrelidir.

Sonucu Telnet karşılaştırmamızda ölçmüştük. Aynı cihaza aynı hesapla yapılan iki girişten SSH olanında, istemciden çıkan paket şöyle görünüyor:

03:20:45.550885 IP 192.168.1.15.46766 > 192.168.1.2.22: Flags [P.], length 44
E..`.@@.@...........................FA.....
+..>.....Jf0. I...-.).Lz1..'..@.5.,	...oa.x.&. .....

Aynı girişin Telnet ile alınmış halinde kullanıcı adı ve parola olduğu gibi okunuyordu. Karşılaştırmanın tamamı ve iki dökümde yapılan arama Telnet rehberimizde.

Sunucu Kimliği: Ana Bilgisayar Anahtarı ve Parmak İzi

Şimdi makalenin en az anlatılan ve en çok işinize yarayacak kısmına geldik.

Bir sunucuya ilk kez bağlandığınızda karşınıza şu çıkar:

The authenticity of host '192.168.1.30' can't be established.
ED25519 key fingerprint is SHA256:....
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Çoğu kişi buraya refleksle yes yazar ve geçer. Oysa bu soru, SSH’ın en önemli güvencesini size devrettiği andır.

Sorunun arkasındaki mekanizma şu. Her SSH sunucusunun bir ana bilgisayar anahtarı vardır: bir özel, bir açık anahtar çifti. Özel anahtar cihazdan hiç çıkmaz. Cihaz her bağlantıda o özel anahtarla bir imza atar, istemci de açık anahtarla o imzayı doğrular. Yani cihaz “ben oyum” demez, kanıtlar. Parmak izi dediğimiz şey ise o açık anahtarın kısa özetidir, insanın karşılaştırabilmesi için.

Bu anahtar kullanıcı anahtarınızla aynı şey değildir, ve bu karıştırma en yaygın olanı. Ana bilgisayar anahtarı sunucunun kimliğidir; parola yerine anahtarla giriş yapmanızı sağlayan anahtar ise sizin kimliğinizdir. İkisi ayrı bölümlerde ele alınıyor çünkü ayrı işler.

Parmak izini bağlanmadan da öğrenebilirsiniz

Bir cihazın ana bilgisayar anahtarını, oturum açmadan, ssh-keyscan ile çekebilirsiniz. Lab switch’ine sorduğumuzda dönen tek anahtar ve onun parmak izi şu:

ssh-keyscan 192.168.1.2 > anahtarlar.txt
ssh-keygen -lf anahtarlar.txt

1024 SHA256:9Uw/V4h+wfWpGJkdjUW86Rubnjk9818k8Uw0dBS2Kxc 192.168.1.2 (RSA)

Bu tek satır iki şey söylüyor:

1. Karşılaştırılabilir bir parmak izi. Asıl amaç da bu. Yeni bir yöneticiye cihaz teslim ederken ya da bir cihaza ilk kez bağlanacak birine talimat verirken doğru yol “çıkan soruya evet de” değil, “parmak izi şu olmalı” demektir.
2. Beklemediğimiz bir bulgu. Satırın başındaki 1024 anahtarın uzunluğu ve bu bugünün ölçütlerine göre yetersiz, çünkü RSA’da alt sınır uzun süredir 2048 kabul ediliyor. Üstelik ssh-keyscan yalnızca tek bir anahtar döndürdü: cihazda ne ed25519 ne ECDSA var, sadece eski bir RSA anahtarı.

Ölçtüm: anahtar makineyi tanımlar, adresi değil

Bunu lab ortamımızda kazara ölçmüş olduk. İstemcinin sakladığı ana bilgisayar anahtarı kayıtlarına baktığımızda iki çift dikkat çekti:

ssh-ed25519@22:192.168.1.102   →  0x3ae8fff682a604ccb9d6721d8ce9d3b43451...
ssh-ed25519@22:192.168.1.15    →  0x3ae8fff682a604ccb9d6721d8ce9d3b43451...

ssh-ed25519@22:192.168.1.107   →  0x50875a52acd5ee50f35394ce9b6138bfb06f...
ssh-ed25519@22:192.168.1.30    →  0x50875a52acd5ee50f35394ce9b6138bfb06f...

Dört ayrı adres, ama anahtarlar ikişer ikişer birebir aynı. Sebebi kayıtlarımızda duruyor: iki lab sunucusu da bir tarihte DHCP adresinden statik adrese taşındı. Makineler aynı kaldı, adresleri değişti, anahtarları değişmedi.

Buradan iki pratik kural çıkıyor ve ikisi de sahada işinize yarar:

• Yeni bir adreste tanıdık bir parmak izi görüyorsanız, makine aynı makinedir. Adres değişmiş, cihaz değişmemiştir.
• Bilinen bir adreste parmak izi değişmişse, iki ihtimal vardır: cihaz yeniden kurulmuş ya da anahtarı yenilenmiştir, veya bağlandığınız şey o cihaz değildir. İstemcinin o noktada verdiği sert uyarı tam da bunun içindir ve geçiştirilmemelidir.

Peki istemci bu kaydı nerede tutuyor? Linux ve macOS’ta ev dizininizdeki ~/.ssh/known_hosts dosyasında, Windows’ta ise kullandığınız istemcinin kendi deposunda. Her satır bir adres ve o adreste tanınan anahtardır. Yukarıdaki ölçüm de zaten bu dosyanın içeriğinden çıktı.

Kaydın adrese göre tutuluyor olması, aynı makineye yeni adresinden bağlandığınızda sorunun yeniden sorulmasının sebebi. Bu bir arıza değil; istemci o adreste daha önce kimseyi tanımıyordu. Aynı sebeple, bir cihaz yeniden kurulduğunda known_hosts içindeki eski satır artık yanlıştır ve istemci sert bir uyarı verir; doğru refleks satırı silmek değil, önce neden değiştiğini öğrenmektir.

Sertifika ile SSH Aynı Şey Değil: İki Güven Modeli

HTTPS ile bir siteye girdiğinizde tarayıcınız size “bu parmak izine güveniyor musunuz?” diye sormaz. SSH sorar. Aynı matematik çalışıyorken neden biri soruyor da diğeri sormuyor?

Cevap güven modelinde. İkisi de açık anahtar ve imza kullanır, ama kefil farklıdır.

Sertifika dünyasında üçüncü bir taraf kefil olur. Sunucunun açık anahtarı, adı ve geçerlilik süresiyle birlikte bir belgeye konur ve bir sertifika otoritesi o belgeyi imzalar. O otoritenin kök sertifikası zaten bilgisayarınızda kayıtlıdır, dolayısıyla tarayıcı doğrulamayı kendi başına yapar ve size soru sormaz. İmzanın neden taklit edilemediğini ve bu zincirin nasıl kurulduğunu sertifika otoritesi yazımızda ele aldık.

SSH’ta böyle bir kefil yoktur. Cihaz kendi kefilidir. Elinde bir belge değil, yalnız kendi anahtar çifti vardır. Bu yüzden ilk karşılaşmada kararı size devreder: “bu ritmi tanıyor musunuz?”

Buradan çıkan ayrım, iki kavramın karıştırıldığı yeri de netleştiriyor:

Bir ağ cihazında crypto key generate rsa çalıştırdığınızda sertifika üretmezsiniz, yalnız anahtar çifti üretirsiniz. Ortada ne belge vardır ne otorite. Telgraf benzetmesiyle: elinizde kimlik kartı yoktur, yalnız tanınabilir bir ritminiz vardır.

Buradaki söz dizimi lab ortamımızdaki switch’e ait ve komut üreticiden üreticiye, hatta aynı üreticinin farklı yazılım sürümünde bile değişir. Kendi cihazınızdaki karşılığını yapılandırma kipinde ? yazarak bulabilirsiniz. Değişmeyen şey komutun adı değil, ne ürettiği: hangi cihazda çalıştırırsanız çalıştırın sonuç bir anahtar çiftidir, sertifika değil.

SSH Sürüm 1 ve 2: Sürümü Neden Sınırlamalısınız?

Bu konudaki her kaynak aynı şeyi söylüyor: SSH sürüm 1 kriptografik olarak kırıktır ve kullanımdan kaldırılmıştır. Doğru, ve tekrar etmenin bir faydası yok.

Faydalı olan başka bir soru: sizin cihazınız hâlâ kabul ediyor mu?

Lab ortamımızdaki yönetilebilir switch’e sorduğumuzda çıkan cevap şu:

SSH Server enabled.  Port: 22
Protocol Levels: Versions 1 and 2.
SSH Connections Currently in Use: 1
Maximum number of SSH Sessions Allowed: 5
SSH Session Timeout: 600
RSA key was generated.
DSA key was generated.
SSH Public Key Authentication is disabled.

Versions 1 and 2. Yani canlıda kullanılan bir yönetilebilir switch, 2026 yılında hâlâ SSH Version 1 ile konuşmayı kabul ediyor. Kimse bunu açmadı; varsayılan böyle geldi ve kimse bakmadı.

Daha rahatsız edici olan şu: bunu öğrenmek için cihaza giriş yapmaya bile gerek yok. Yukarıda okuduğumuz SSH-1.99-OpenSSH_6.5 bannerındaki 1.99, aynı bilgiyi kimlik doğrulanmadan, düz metin olarak veriyor. Ağı tarayan biri hangi cihazların hâlâ eski sürümü kabul ettiğini tek bir bağlantıyla listeleyebilir. Yani bu ayar yalnızca bir zafiyet değil, aynı zamanda ilan edilmiş bir zafiyet.

Kendi cihazınızda kontrol etmenin iki yolu var. Cihaza girip durumu sorabilirsiniz, ya da dışarıdan bannerına bakabilirsiniz; ikincisi daha hızlıdır ve envanterdeki tüm cihazlar için tekrarlanabilir. Aynı switch’te 1. sürümü kapattım; bannerın SSH-2.0’a döndüğünü ve 1. sürümde ısrar eden istemcinin reddedildiğini switch sıkılaştırma yazımızda gösterdim.

Buradaki ders protokolle ilgili değil, alışkanlıkla ilgili. “Telnet’i kapattık, SSH’a geçtik” cümlesi bir işi bitirdiğinizi söyler, hepsini değil. Şifreli bir kanalınız vardır ama kanalın en zayıf sürümü hâlâ açıktır ve ısrar eden bir istemci onu kullanabilir.

Aynı çıktının alt satırı da ayrı bir eksiği söylüyor: SSH Public Key Authentication is disabled. Yani cihaza hâlâ parolayla giriliyor. Ona da bir sonraki bölümde geliyoruz.

Parola Yerine Anahtar: Mekanizma ve Ne Zaman Gerekir?

Anahtar tabanlı kimlik doğrulama, sunucu kimliğinin aynadaki görüntüsüdür. Orada cihaz kendini kanıtlıyordu, burada siz kendinizi kanıtlıyorsunuz, ve yine parola göndermeden.

Mekanizma şöyle işler. Sizin de bir anahtar çiftiniz olur: özel anahtar sizin makinenizde kalır, açık anahtar sunucuya tanıtılır. Giriş sırasında sunucu size bir soru gönderir, siz özel anahtarınızla imzalarsınız, sunucu açık anahtarla doğrular. Parola hiçbir aşamada ağa çıkmaz, çünkü ortada parola yoktur.

Bu anahtarın kazandırdığı şey yalnız kabuk erişimi değil. SSH oturumu tek bir boru değil, kanallara ayrılabilen bir taşıyıcıdır: aynı şifreli oturumun içinde biri size komut satırı verirken bir diğeri dosya aktarır.

SFTP işte bu ikinci kanaldır ve ayrıca kurulmaz, sunucuda SSH çalışıyorsa zaten tanımlıdır. Adına rağmen FTP ile akrabalığı yoktur; neden ayrı bir protokol olduğunu ve FTPS ile karıştırılmasının sahada neye mal olduğunu FTP, FTPS ve SFTP farkı rehberimizde ele alıyoruz. Pratik sonucu şudur: burada anlattığımız sıkılaştırma adımları dosya aktarımınızı da kapsar, ikisi ayrı yapılandırmalar değildir.

Kazancı üç yerde görünür:

• Çalınacak bir parola kalmaz. Hattı dinleyen, sunucuyu ele geçiren ya da veritabanını okuyan biri kullanılabilir bir sır bulamaz.
• Tekrar oynatılamaz. Her girişte farklı bir soru imzalanır, kaydedilen bir oturum yeniden kullanılamaz.
• Özel anahtar makinenizden çıkmaz. Sunucuya güvenmek zorunda kalmazsınız.

Karşılığında bir sorumluluk gelir: özel anahtarınız artık kimliğinizdir. Parolayla korunması ve yedeğinin düşünülmesi gerekir.

Linux sunucularda bunun pratik kurulumunu, yani sshd_config üzerinden parolayla girişi kapatıp açık anahtarı tanıtmayı Ubuntu Server rehberimizin anahtar tabanlı kimlik doğrulama bölümünde ele aldık.

Ağ cihazlarında ise durum farklıdır ve genellikle atlanır: birçok switch ve router anahtar tabanlı girişi destekler ama varsayılan olarak kapalı gelir. Yukarıdaki ölçümde gördüğümüz disabled satırı tam olarak budur.

Ağ Cihazlarında SSH: Kurulumdan Sonra Ne Kalır?

SSH’ı anlatan Türkçe kaynakların neredeyse tamamı Linux sunucu üzerinden anlatıyor. Oysa sahada SSH’ın en çok konuşulduğu yer switch, router ve firewall yönetim arayüzleri. O tarafta kurulum bittikten sonra bakılması gereken üç şey var.

Birincisi, eskiyen imza algoritmaları. Bunu ölçerken birinci elden yaşadık: lab switch’ine modern bir istemciyle bağlanmak, komuta fazladan bir bayrak eklemeden mümkün olmadı.

ssh -o HostKeyAlgorithms=+ssh-rsa ilker@192.168.1.2

Sebebi o anahtarla atılan imzanın eski bir hash fonksiyonuna dayanması. Modern istemciler bu imza yöntemini varsayılan olarak reddediyor. Belirti kafa karıştırıcıdır: parola sorulmadan bağlantı reddedilir ve ilk akla gelen kimlik sorunu olur, oysa sorun müzakere aşamasındadır.

Burada gözden kaçan bir incelik var ve sıkılaştırma yaparken yanlış yere bakmanıza yol açıyor. Aynı bağlantının müzakere sonucuna baktığımızda tablo şöyle çıkıyor:

kex: algorithm: diffie-hellman-group-exchange-sha256
kex: host key algorithm: ssh-rsa
kex: server->client cipher: chacha20-poly1305@openssh.com

Trafiği koruyan şifre chacha20-poly1305, yani modern ve güçlü. Buna karşılık cihazın kimliğini kanıtladığı yöntem ssh-rsa, üstelik anahtarı 1024 bit. Kanal sağlam, kimlik zayıf. İkisi ayrı eksendir ve “trafiğimiz güçlü şifreyle korunuyor” cümlesi ikincisi hakkında hiçbir şey söylemez.

Cihaz yazılımı güncellenirse ikisi de düzelir. Güncellenemiyorsa bayrak geçici bir çözümdür ve o cihaz emeklilik listesine girer. Switch’in ekranı parmak izini başka bir biçimde gösterdiği için karşılaştırmanın nasıl yapılacağını switch SSH yapılandırması yazımızda anlattık.

İkincisi, oturum sınırları. Yukarıdaki çıktıda SSH Session Timeout: 600 ve Maximum number of SSH Sessions Allowed: 5 satırları duruyor. Zaman aşımı, açık unutulmuş bir oturumun süresiz beklemesini engeller. Bu ayarların varlığını bilmek, bir cihazda “kimse bağlı değil ama oturum dolu” hatasını teşhis ederken de işinize yarar.

Üçüncüsü, erişimin nereden geldiği. SSH şifreli olduğu için yönetim arayüzünü herkese açık bırakmanın sakıncası yok sanılır. Şifreleme trafiği korur, erişimi sınırlamaz. Doğru kurgu yönetim arayüzlerini ayrı bir yönetim ağına almak ve oraya kimlerin girebildiğini daraltmaktır; switch ve router tarafındaki yönetim erişimini nasıl kurguladığımızı switch ve router kurulumu yazımızda ele alıyoruz.

SSH Sıkılaştırma: Sık Yapılan Hatalar

“SSH açık, o zaman güvendeyiz.” Bu yazının en çok düzeltmek istediği cümle. SSH’ın açık olması kanalın şifreli olduğunu söyler; hangi sürümlerin kabul edildiğini, nasıl kimlik doğrulandığını ve kimin erişebildiğini söylemez. Ölçtüğümüz cihazda üç ayarın ikisi eksikti.

Parmak izi uyarısını geçiştirmek. İstemci “ana bilgisayar anahtarı değişti” diye sert bir uyarı verdiğinde, refleks çoğu zaman uyarıyı susturmak olur. Oysa o uyarı SSH’ın size verebileceği en değerli sinyaldir. Cihaz yeniden mi kuruldu, yoksa bağlandığınız şey o cihaz değil mi? İkisi de araştırılmayı hak eder.

Parolayla girişi kalıcı çözüm saymak. Anahtar tabanlı kimlik doğrulama çoğu cihazda destekleniyor ama kapalı geliyor. Kapalı kaldığı sürece elinizde çalınabilir bir sır vardır.

Sunucu kimliğini ve kullanıcı kimliğini karıştırmak. “SSH anahtarı” ifadesi iki farklı şey için kullanılıyor ve bu, sıkılaştırma sırasında yanlış ayarın açılmasına yol açıyor. Cihazın anahtarı zaten üretilmiş olabilir; bu, sizin anahtarla giriş yapabildiğiniz anlamına gelmez.

Eski cihazı bayrakla yaşatmak. Yukarıdaki HostKeyAlgorithms bayrağı bir teşhis aracıdır, bir çözüm değil. Her bağlantıda kriptografik kısıtı gevşetmek zorunda kalıyorsanız, çözülmesi gereken şey komut satırınız değil o cihazın yazılımıdır.

Sonuç: SSH Kanalı Şifrelemekten Fazlasını Yapar

SSH’ı Telnet’in şifreli hali diye anlatmak, yaptığı işin yalnızca üçte birini anlatmaktır. Kanalı kapatır, evet; ama aynı zamanda karşı tarafın kim olduğunu kanıtlar ve sizin kim olduğunuzu parola göndermeden ispatlamanıza izin verir.

Sahada eksik kalan da genellikle ilk iş değil, diğer ikisi oluyor. Kanal şifrelenir ve iş bitmiş sayılır; oysa cihaz hâlâ kırık bir sürümü kabul ediyor, giriş hâlâ parolayla yapılıyor ve ilk bağlantıdaki parmak izi sorusu hiç okunmadan geçiliyor.

Telgraf operatörü karşısındakini ritminden tanırdı. SSH size aynı imkanı veriyor, üstelik matematiksel bir kesinlikle. Tek istediği, ritmi bir kez gerçekten dinlemeniz.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn