Documentation for a newer release is available. View Latest

OpenSSH

indexterm:[OpenSSH] `SSH` (Secure Shell - Güvenli Kabuk), bir istemci-sunucu mimarisi kullanarak iki sistem arasında güvenli iletişimi kolaylaştıran ve kullanıcıların sunucu ana makine sistemlerinde uzaktan oturum açmasına olanak tanıyan bir protokoldür. `FTP`, `Telnet` veya [command]#rlogin# gibi diğer uzaktan iletişim protokollerinden farklı olarak SSH, oturum açma oturumunu şifreler ve davetsiz misafirlerin şifrelenmemiş parolaları toplamasını zorlaştırır.

ssh programı, telnet veya rsh gibi uzak ana makinelerde oturum açmak için kullanılan daha eski, daha az güvenli terminal uygulamalarının yerini alacak şekilde tasarlanmıştır. scp adlı ilgili bir program, rcp gibi ana makineler arasında dosya kopyalamak için tasarlanmış eski programların yerini alır. Bu eski uygulamalar, istemci ve sunucu arasında iletilen parolaları şifrelemediğinden, mümkün olduğunda bunlardan kaçının. Uzak sistemlerde oturum açmak için güvenli yöntemler kullanmak, hem istemci sistemi hem de uzak ana makine için riskleri azaltır.

Fedora genel OpenSSH paketini, openssh, ve ayrıca OpenSSH sunucusu, openssh-server, ve istemcisi, openssh-clients, paketlerini içermektedir. OpenSSH paketlerinin, birkaç önemli kriptografik kütüphane kuran ve OpenSSH’nin şifreli iletişim sağlamasına imkan veren OpenSSL paketi openssl-libs gerektirdiğini unutmayın.

SSH Protokolü

Neden SSH Kullanmalıyım?

Olası davetsiz misafirler, bir sisteme erişim elde etmek amacıyla ağ trafiğini kesintiye uğratmalarına, engellemelerine ve yeniden yönlendirmelerine olanak tanıyan çeşitli araçlara sahiptir. Genel olarak bu tehditler şu şekilde sınıflandırılabilir:

İki sistem arasındaki iletişimin dinlenmesi

Saldırgan, iletişim kuran taraflar arasında ağ üzerinde herhangi bir yerde olabilir ve aralarında geçen bilgileri kopyalayabilir. Bilgileri ele geçirebilir ve saklayabilir, veya bilgileri değiştirebilir ve hedeflenen alıcıya gönderebilir.

Bu saldırı genellikle, ağda akan her paketi yakalayan ve içeriğini analiz eden oldukça yaygın bir ağ yardımcı programı olan bir paket dinleyicisi kullanılarak gerçekleştirilir.

Belirli bir ana makinenin kimliğine bürünülmesi

Saldırganın sistemi, bir iletimin hedeflenen alıcısı gibi görünecek şekilde yapılandırılır. Bu strateji işe yararsa, kullanıcının sistemi yanlış ana makineyle iletişim kurduğundan habersiz kalır.

Bu saldırı, DNS zehirlemesi olarak bilinen bir teknik kullanılarak veya IP kandırması denen bir yöntemle gerçekleştirilebilir. İlk durumda davetsiz misafir, istemci sistemlerini kötü amaçla kopyalanmış bir ana makineye yönlendirmek için ele geçirilmiş bir DNS sunucusu kullanır. İkinci durumda davetsiz misafir, güvenilir bir ana makineden geliyormuş gibi görünen sahte ağ paketleri gönderir.

Her iki teknik de olası hassas bilgileri ele geçirir ve bu ele geçirme düşmanca nedenlerle yapılırsa sonuçlar felaket olabilir. Uzak kabuk oturum açması ve dosya kopyalama için SSH kullanılırsa, bu güvenlik tehditleri büyük ölçüde azaltılabilir. Bunun nedeni, SSH istemcisi ve sunucusunun kimliklerini doğrulamak için sayısal imzalar kullanmasıdır. Ayrıca, istemci ve sunucu sistemleri arasındaki tüm iletişim şifrelenir. Her paket yalnızca yerel ve uzak sistemler tarafından bilinen bir anahtar kullanılarak şifrelendiğinden, bir iletişimin her iki tarafının kimliğini taklit etme girişimleri işe yaramaz.

Ana Özellikler

SSH protokolü aşağıdaki güvenlik önlemlerini sağlamaktadır:

Hiç kimse kendisini amaçlanan sunucuymuş gibi tanıtamaz

İlk bağlantıdan sonra istemci, daha önce bağlandığı sunucuyla aynı sunucuya bağlandığını doğrulayabilir.

Kimlik doğrulama bilgilerini hiç kimse ele geçiremez

İstemci, kimlik doğrulama bilgilerini güçlü bir 128 bit şifreleme kullanarak sunucuya iletir.

Hiç kimse iletişimi dinleyemez

Bir oturum sırasında gönderilen ve alınan tüm veriler 128 bit şifreleme kullanılarak aktarılır, bu da ele geçirilen aktarımların şifresinin çözülmesini ve okunmasını son derece zorlaştırır.

Ek olarak, aşağıdaki seçenekleri de sunar:

Grafiksel uygulamaları bir ağ üzerinden kullanmak için güvenli yollar sağlar

İstemci, X11 iletme adlı bir teknik kullanarak sunucudan X11 (X Pencere Sistemi) uygulamalarını iletebilir. ForwardX11Trusted seçeneğini yes olarak ayarlarsanız veya -Y seçeneğiyle SSH’yi kullanırsanız, X11 SECURITY uzantısı denetimlerini atlarsınız, bu da bir güvenlik tehdidine neden olabilir.

Normalde güvenli olmayan protokolleri güvenli şekilde kullanmanın bir yolunu sağlar

SSH protokolü, gönderdiği ve aldığı her şeyi şifreler. Bir SSH sunucusu, port yönlendirme adlı bir teknik kullanılarak POP gibi normalde güvenli olmayan protokolleri güvenli şekilde kullanmak ve genel sistem ve veri güvenliğini artırmak için kullanılan bir kanal haline gelebilir.

Güvenli bir kanal oluşturmak için kullanılabilir

OpenSSH sunucusu ve istemcisi, sunucu ve istemci makineler arasındaki trafik için sanal özel ağa benzer bir tünel oluşturacak şekilde yapılandırılabilir.

Kerberos ile kimlik doğrulamayı destekler

OpenSSH sunucuları ve istemcileri, Kerberos ağ kimlik doğrulama protokolünün GSSAPI (Generic Security Services Application Program Interface - Genel Güvenlik Hizmetleri Uygulama Program Arayüzü) uygulamasını kullanarak kimlik doğrulaması yapacak şekilde yapılandırılabilir.

Protokol Sürümleri

Şu anda iki çeşit SSH vardır: sürüm 1 ve sürüm 2. Fedora’daki OpenSSH paketi, sürüm 1’deki bilinen açıklardan etkilenmeyen gelişmiş bir anahtar değişim algoritmasına sahip SSH sürüm 2’yi kullanmaktadır. Bununla birlikte, uyumluluk nedenleriyle OpenSSH paketi sürüm 1 bağlantılarını da desteklemektedir, ancak sürüm 1 öntanımlı olarak devre dışıdır ve yapılandırma dosyalarında etkinleştirilmesi gerekir.

SSH sürüm 1’i kullanmaktan kaçının

Bağlantınız için azami güvenliği sağlamak için, mümkün olduğunda yalnızca SSH sürüm 2 uyumlu sunucuların ve istemcilerin kullanılması tavsiye edilmektedir.

Bir SSH Bağlantısının Olay Sırası

Aşağıdaki olaylar dizisi, iki ana makine arasındaki SSH iletişiminin bütünlüğünün korunmasına yardımcı olur.

  1. İstemcinin doğru sunucuyla iletişim kurduğunu doğrulayabilmesi için kriptografik bir el sıkışma yapılır.

  2. İstemci ve uzak ana makine arasındaki bağlantının taşıma katmanı, simetrik bir şifre kullanılarak şifrelenir.

  3. İstemci kendi kimliğini sunucuya doğrular.

  4. İstemci, şifreli bağlantı üzerinden uzak ana makineyle etkileşime girer.

Taşıma Katmanı

Taşıma katmanının birincil rolü, kimlik doğrulama esnasında ve sonraki iletişim sırasında iki ana makine arasında güvenli kolaylaştırmaktır. Taşıma katmanı bunu, verilerin şifrelenmesi ve şifresinin çözülmesini yaparak ve veri paketlerinin gönderilip alınırken bütünlük korumasını sağlayarak gerçekleştirir. Taşıma katmanı ayrıca sıkıştırma işlemini yaparak bilgi aktarımını hızlandırır.

Bir SSH istemcisi bir sunucuyla bağlantı kurduğunda, iki sistemin taşıma katmanını doğru bir şekilde oluşturabilmesi için birbirlerine anahtar bilgilerini verirler. Bu değiş tokuş sırasında şu adımlar gerçekleşir:

  • Anahtar değiş tokuşu yapılır

  • Genel anahtar şifreleme algoritması belirlenir

  • Simetrik şifreleme algoritması belirlenir

  • Mesaj doğrulama algoritması belirlenir

  • Sağlama algoritması belirlenir

Anahtar değiş tokuşu sırasında, sunucu kendisini istemciye benzersiz bir ana makine anahtarı ile tanıtır. İstemci bu belirli sunucuyla daha önce hiç iletişim kurmadıysa, sunucunun ana makine anahtarı istemci tarafından bilinmez ve bağlantı gerçekleşmez. OpenSSH, kullanıcıya ana makinenin doğruluğunun sağlanamayacağını bildirir ve kullanıcıdan bunu kabul etmesini veya reddetmesini ister. Kullanıcının, kabul etmeden önce yeni ana makine anahtarını bağımsız olarak doğrulaması beklenir. Sonraki bağlantılarda, sunucunun ana makine anahtarı, istemcide kaydedilen anahtarla karşılaştırılır ve istemcinin gerçekten amaçlanan sunucuyla iletişim kurduğuna dair güven sağlanır. Sonraki bağlantılarda ana makine anahtarı artık eşleşmezse, bir bağlantı kurulmadan önce kullanıcının istemcideki kayıtlı anahtarı kaldırması gerekir.

Yeni bir SSH sunucusunun bütünlüğünü her zaman doğrulayın

Yerel sistem, amaçlanan sunucu ile saldırgan tarafından kurulan sahte sunucu arasındaki farkı bilmediğinden, ilk temas sırasında bir saldırganın SSH sunucusu gibi davranması mümkündür. Bunu önlemeye yardımcı olmak için, ilk kez bağlanmadan önce veya bir ana makine anahtarı uyuşmazlığı durumunda sunucu yöneticisiyle iletişime geçerek yeni bir SSH sunucusunun bütünlüğünü doğrulayın.

SSH, hemen hemen her tür genel anahtar algoritması veya kodlama biçimiyle çalışmak üzere tasarlanmıştır. İlk anahtar değişiminde değiş tokuşlar için kullanılacak bir sağlama değeri ve paylaşılan bir gizli değer oluşturulduktan sonra, iki sistem bağlantı üzerinden gönderilen kimlik doğrulamasını ve gelecekteki verileri korumak için hemen yeni anahtarları ve algoritmaları hesaplamaya başlar.

Bir anahtar ve algoritma kullanılarak belirli bir miktarda veri iletildikten sonra (kesin miktar SSH uygulamasına bağlıdır), başka bir anahtar değiş tokuşu gerçekleşir ve başka bir sağlama değeri ve yeni bir paylaşılan gizli değer üretilir. Saldırgan sağlama değerini ve paylaşılan gizli değeri belirleyebilse bile, bu bilgi yalnızca sınırlı bir süre için yararlıdır.

Kimlik Doğrulama

Taşıma katmanı iki sistem arasında bilgi iletmek için güvenli bir tünel oluşturduğunda, sunucu istemciye, özel anahtarla kodlanmış imza kullanma veya bir parola yazma gibi desteklenen farklı kimlik doğrulama yöntemlerini söyler. İstemci daha sonra bu desteklenen yöntemlerden birini kullanarak sunucuya kimliğini doğrulamaya çalışır.

SSH sunucuları ve istemcileri, her iki tarafa da en iyi miktarda denetim sağlayan farklı kimlik doğrulama türlerine izin verecek şekilde yapılandırılabilir. Sunucu, güvenlik modeline göre hangi şifreleme yöntemlerini desteklediğine karar verebilir ve istemci, kullanılabilir seçeneklerden kimlik doğrulamayı deneyeceği yöntemlerin sırasını seçebilir.

Kanallar

SSH taşıma katmanı üzerinden başarılı bir kimlik doğrulaması yapıldıktan sonra, çoğullama (multiplexing)[1] adı verilen bir teknikle birden çok kanal açılır. Bu kanalların her biri, farklı terminal oturumları ve X11 iletme oturumları için iletişimi gerçekleştirir.

Hem istemciler hem de sunucular yeni bir kanal oluşturabilir. Daha sonra her kanala bağlantının her iki ucunda farklı bir numara atanır. İstemci yeni bir kanal açmaya çalıştığında, istemciler istekle birlikte kanal numarasını da gönderir. Bu bilgi sunucu tarafından saklanır ve iletişimi o kanala yönlendirmek için kullanılır. Bu, farklı oturum türlerinin birbirini etkilememesi ve belirli bir oturum sona erdiğinde, birincil SSH bağlantısını kesmeden kanalının kapatılabilmesi için yapılır.

Kanallar ayrıca düzenli bir şekilde veri gönderip almalarına olanak sağlayan akış denetimini destekler. Bu şekilde, istemci kanalın açık olduğuna dair bir mesaj alana kadar kanal üzerinden veri gönderilmez.

İstemci ve sunucu, istemcinin talep ettiği hizmetin türüne ve kullanıcının ağa bağlanma biçimine bağlı olarak her kanalın özelliklerini otomatik olarak görüşür. Bu, protokolün temel alt yapısını değiştirmek zorunda kalmadan farklı türdeki uzak bağlantıların ele alınmasında büyük esneklik sağlar.

OpenSSH’yi Yapılandırma

Bu bölümde açıklanan görevleri gerçekleştirmek için süper kullanıcı ayrıcalıklarına sahip olmanız gerekir. Bunları elde etmek için şunu yazarak root olarak oturum açın:

su -

Yapılandırma Dosyaları

İki farklı yapılandırma dosyası grubu vardır: istemci programları (ssh, scp ve sftp) için olanlar ve sunucu (sshd arka plan programı) için olanlar. Sistem genelindeki SSH yapılandırma bilgileri, Sistem genelindeki yapılandırma dosyaları kısmında açıklandığı gibi /etc/ssh/ dizininde saklanır. Kullanıcıya özel SSH yapılandırma bilgileri, Kullanıcıya özel yapılandırma dosyaları kısmında açıklandığı gibi kullanıcının ev dizini içindeki ~/.ssh/ dizininde saklanır.

Tablo 1. Sistem genelindeki yapılandırma dosyaları
Dosya Açıklama

/etc/ssh/moduli

Güvenli bir taşıma katmanı oluşturmak için önemli olan “Diffie-Hellman group exchange” anahtar değiş tokuş yöntemi için kullanılan Diffie-Hellman gruplarını içerir. Bir SSH oturumunun başında anahtarlar değiş tokuş edildiğinde, her iki tarafça da tek başına belirlenemeyecek paylaşılan, gizli bir değer oluşturulur. Bu dosya yoksa, sabit gruplar kullanılacaktır. Diğer anahtar değiş tokuş yöntemlerinin bu dosyaya ihtiyacı yoktur.

/etc/ssh/ssh_config

Öntanımlı SSH istemci yapılandırma dosyası. Bunun, varsa ~/.ssh/config tarafından geçersiz kılındığını unutmayın.

/etc/ssh/sshd_config

sshd arka plan programı için yapılandırma dosyası.

/etc/ssh/ssh_host_ecdsa_key

sshd arka plan programı tarafından kullanılan ECDSA özel anahtarı.

/etc/ssh/ssh_host_ecdsa_key.pub

sshd arka plan programı tarafından kullanılan ECDSA genel anahtarı.

/etc/ssh/ssh_host_key

SSH protokolünün 1. sürümü için sshd arka plan programı tarafından kullanılan RSA özel anahtarı.

/etc/ssh/ssh_host_key.pub

SSH protokolünün 1. sürümü için sshd arka plan programı tarafından kullanılan RSA genel anahtarı.

/etc/ssh/ssh_host_rsa_key

SSH protokolünün 2. sürümü için sshd arka plan programı tarafından kullanılan RSA özel anahtarı.

/etc/ssh/ssh_host_rsa_key.pub

SSH protokolünün 2. sürümü için sshd arka plan programı tarafından kullanılan RSA genel anahtarı.

/etc/pam.d/sshd

sshd arka plan programı için PAM yapılandırma dosyası.

/etc/sysconfig/sshd

sshd hizmeti için yapılandırma dosyası.

Tablo 2. Kullanıcıya özel yapılandırma dosyaları
Dosya Açıklama

~/.ssh/authorized_keys

Sunucular için yetkilendirilen genel anahtarların bir listesini tutar. İstemci bir sunucuya bağlandığında, sunucu bu dosyada saklanan imzalı genel anahtarına bakarak istemcinin kimliğini doğrular.

~/.ssh/id_ecdsa

Kullanıcının ECDSA özel anahtarını içerir.

~/.ssh/id_ecdsa.pub

Kullanıcının ECDSA genel anahtarı.

~/.ssh/id_rsa

SSH protokolünün 2. sürümü için ssh tarafından kullanılan RSA özel anahtarı.

~/.ssh/id_rsa.pub

SSH protokolünün 2. sürümü için ssh tarafından kullanılan RSA genel anahtarı.

~/.ssh/identity

SSH protokolünün 1. sürümü için ssh tarafından kullanılan RSA özel anahtarı.

~/.ssh/identity.pub

SSH protokolünün 1. sürümü için ssh tarafından kullanılan RSA genel anahtarı.

~/.ssh/known_hosts

Kullanıcı tarafından erişilen SSH sunucularının ana makine anahtarlarını içerir. Bu dosya, SSH istemcisinin doğru SSH sunucusuna bağlandığından emin olması için çok önemlidir.

SSH yapılandırma dosyalarında kullanılabilecek çeşitli yönergeler hakkında bilgi için ssh_config(5) ve sshd_config(5) kılavuz sayfalarına bakın.

OpenSSH Sunucusunu Başlatma

İlgili paketlerin kurulu olduğundan emin olun

Bir OpenSSH sunucusu çalıştırmak için openssh-server paketinin kurulu olması gerekir. Fedora 31’da yeni paketlerin nasıl kurulacağı hakkında daha fazla bilgi için Paketleri Kurma kısmına bakın.

Geçerli oturumda sshd arka plan programını başlatmak için, root olarak bir kabuk isteminde şunu yazın:

~]# systemctl start sshd.service

Geçerli oturumda çalışan sshd arka plan programını durdurmak için, root olarak şu komutu kullanın:

~]# systemctl stop sshd.service

Arka plan programının önyükleme sırasında otomatik olarak başlamasını istiyorsanız, root olarak şunu yazın:

~]# systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

Fedora’da hizmetlerin nasıl yapılandırılacağı hakkında daha fazla bilgi için Hizmetler ve Arka Plan Programları bölümüne bakın.

Sistemi yeniden kurarsanız, yeni tanımlama anahtarlarının oluşturulacağını unutmayın. Sonuç olarak, yeniden kurulumdan önce sisteme OpenSSH araçlarından herhangi biriyle bağlanan istemciler aşağıdaki mesajı göreceklerdir:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Bunu önlemek için, /etc/ssh/ dizinindeki ilgili dosyaları yedekleyebilir (tam liste için Sistem genelindeki yapılandırma dosyaları kısmına bakın) ve sistemi yeniden kurduğunuzda onları geri yükleyebilirsiniz.

Uzak Bağlantılar için SSH Gerektirme

SSH’nin gerçekten etkili olması için güvenli olmayan bağlantı protokollerinin kullanılması yasaklanmalıdır. Aksi takdirde, bir kullanıcının parolası bir oturumda SSH kullanılarak korunurken, başka bir oturumda Telnet kullanarak oturum açtığında ele geçirilebilir. Devre dışı bırakılacak bazı hizmetler arasında telnet, rsh, rlogin ve vsftpd bulunmaktadır.

Bu hizmetler Fedora’da öntanımlı olarak kurulu değildir. Gerekirse, bu hizmetlerin çalışmadığından emin olmak için bir kabuk isteminde şu komutları yazın:

systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service

Başlangıçta bu hizmetleri çalıştırmayı devre dışı bırakmak için şunu yazın:

systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service

Fedora’da hizmetlerin nasıl yapılandırılacağı hakkında daha fazla bilgi için Hizmetler ve Arka Plan Programları bölümüne bakın.

Anahtar Tabanlı Kimlik Doğrulamayı Kullanma

Sistem güvenliğini daha da iyileştirmek için SSH anahtar çiftleri oluşturun ve ardından parola doğrulamasını devre dışı bırakarak anahtar tabanlı kimlik doğrulamasını zorunlu kılın. Bunu yapmak için vi veya nano gibi bir metin düzenleyicide /etc/ssh/sshd_config yapılandırma dosyasını açın ve PasswordAuthentication seçeneğini aşağıdaki gibi değiştirin:

PasswordAuthentication no

Yeni bir öntanımlı kurulum dışında bir sistem üzerinde çalışıyorsanız, PubkeyAuthentication no seçeneğinin ayarlanmadığını denetleyin. Konsol üzerinden veya yerel olarak değil de uzaktan bağlanılıyorsa, parola doğrulamasını devre dışı bırakmadan önce anahtar tabanlı oturum açma işleminin test edilmesi tavsiye edilir.

Bir istemci makineden sunucuya bağlanmak üzere ssh, scp veya sftp kullanabilmek için aşağıdaki adımları izleyerek bir yetkilendirme anahtarı çifti oluşturun. Anahtarların her kullanıcı için ayrı ayrı oluşturulması gerektiğini unutmayın.

Fedora 31, öntanımlı olarak SSH protokolünün 2. sürümünü ve RSA anahtarlarını kullanır (daha fazla bilgi için Protokol Sürümleri kısmına bakın).

Anahtar çiftlerini root kullanıcısı ile oluşturmayın

Adımları root olarak tamamlarsanız, anahtarları yalnızca root kullanıcısı kullanabilecektir.

~/.ssh/ dizininizi yedekleyin

Sisteminizi yeniden kurarsanız ve önceden oluşturulmuş anahtar çiftlerini korumak isterseniz, ~/.ssh/ dizinini yedekleyin. Yeniden kurulumdan sonra, yedeklediğiniz dizini ev dizininize geri kopyalayın. Bu işlem, root dahil, sisteminizdeki tüm kullanıcılar için yapılabilir.

Anahtar Çiftleri Oluşturma

SSH protokolünün 2. sürümü için bir RSA anahtar çifti oluşturmak için şu adımları izleyin:

  1. Bir kabuk isteminde şunu yazarak bir RSA anahtar çifti oluşturun:

    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/KULLANICI/.ssh/id_rsa):
  2. Yeni oluşturulan anahtarın ~/.ssh/id_rsa olan öntanımlı konumunu onaylamak için Enter tuşuna basın.

  3. Bir parola girin ve sizden istendiğinde tekrar girerek onu doğrulayın. Güvenli olması için, hesabınızda oturum açmak için kullandığınız parolanın aynısını kullanmaktan kaçının.

    Bundan sonra, şuna benzer bir mesajla karşılaşacaksınız:

    Your identification has been saved in /home/KULLANICI/.ssh/id_rsa.
    Your public key has been saved in /home/KULLANICI/.ssh/id_rsa.pub.
    The key fingerprint is:
    e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 KULLANICI@penguin.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |             E.  |
    |            . .  |
    |             o . |
    |              . .|
    |        S .    . |
    |         + o o ..|
    |          * * +oo|
    |           O +..=|
    |           o*  o.|
    +-----------------+
  4. Öntanımlı olarak, ~/.ssh/ dizininin izinleri rwx------ (sekizlik taban gösteriminde 700) olarak ayarlanır. Bu, yalnızca KULLANICI'nın içeriği görebilmesini sağlamak içindir. Gerekirse, bu aşağıdaki komutla doğrulanabilir:

    ~]$ ls -ld ~/.ssh
    drwx------. 2 KULLANICI KULLANICI 54 Nov 25 16:56 /home/KULLANICI/.ssh/
  5. Genel anahtarı uzak bir makineye kopyalamak için aşağıdaki biçimde bir komut kullanın:

     ssh-copy-id KULLANICI@anamakineadı

    Bu, henüz yapılmamışsa en son değiştirilen ~/.ssh/id*.pub genel anahtarını kopyalayacaktır. Alternatif olarak, genel anahtarın dosya adını aşağıdaki gibi belirtebilirsiniz:

    ssh-copy-id -i ~/.ssh/id_rsa.pub KULLANICI@anamakineadı

    Bu, ~/.ssh/id_rsa.pub dosyasının içeriğini, bağlanmak istediğiniz makinedeki ~/.ssh/authorized_keys dosyasına kopyalayacaktır. Dosya zaten varsa, anahtarlar dosyanın sonuna eklenir.

SSH protokolünün 2. sürümü için bir ECDSA anahtar çifti oluşturmak için şu adımları izleyin:

  1. Bir kabuk isteminde şunu yazarak bir ECDSA anahtar çifti oluşturun:

    ~]$ ssh-keygen -t ecdsa
    Generating public/private ecdsa key pair.
    Enter file in which to save the key (/home/KULLANICI/.ssh/id_ecdsa):
  2. Yeni oluşturulan anahtarın ~/.ssh/id_ecdsa olan öntanımlı konumunu onaylamak için Enter tuşuna basın.

  3. Bir parola girin ve sizden istendiğinde tekrar girerek onu doğrulayın. Güvenli olması için, hesabınızda oturum açmak için kullandığınız parolanın aynısını kullanmaktan kaçının.

    Bundan sonra, şuna benzer bir mesajla karşılaşacaksınız:

    Your identification has been saved in /home/KULLANICI/.ssh/id_ecdsa.
    Your public key has been saved in /home/KULLANICI/.ssh/id_ecdsa.pub.
    The key fingerprint is:
    fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 KULLANICI@penguin.example.com
    The key's randomart image is:
    +--[ECDSA  256]---+
    |       .+ +o     |
    |       . =.o     |
    |        o o +  ..|
    |         + + o  +|
    |        S o o oE.|
    |           + oo+.|
    |            + o  |
    |                 |
    |                 |
    +-----------------+
  4. Öntanımlı olarak, ~/.ssh/ dizininin izinleri rwx------ (sekizlik taban gösteriminde 700) olarak ayarlanır. Bu, yalnızca KULLANICI'nın içeriği görebilmesini sağlamak içindir. Gerekirse, bu aşağıdaki komutla doğrulanabilir:

    ~]$ ls -ld ~/.ssh
                  ~]$ ls -ld ~/.ssh/
    drwx------. 2 KULLANICI KULLANICI 54 Nov 25 16:56 /home/KULLANICI/.ssh/
  5. Genel anahtarı uzak bir makineye kopyalamak için aşağıdaki biçimde bir komut kullanın:

    ssh-copy-id KULLANICI@anamakineadı

    Bu, henüz yapılmamışsa en son değiştirilen ~/.ssh/id*.pub genel anahtarını kopyalayacaktır. Alternatif olarak, genel anahtarın dosya adını aşağıdaki gibi belirtebilirsiniz:

    ssh-copy-id -i ~/.ssh/id_ecdsa.pub KULLANICI@anamakineadı

    Bu, ~/.ssh/id_ecdsa.pub dosyasının içeriğini, bağlanmak istediğiniz makinedeki ~/.ssh/authorized_keys dosyasına kopyalayacaktır. Dosya zaten varsa, anahtarlar dosyanın sonuna eklenir.

Sisteminizi parolayı hatırlayacak şekilde nasıl ayarlayacağınızla ilgili bilgi için ssh-agent Yapılandırma kısmına bakın.

Özel anahtarınızı asla paylaşmayın

Özel anahtar yalnızca kişisel kullanımınız içindir ve onu asla kimseye vermemeniz önemlidir.

ssh-agent Yapılandırma

Uzak bir makineyle her bağlantı başlattığınızda parolanızı girmek zorunda kalmamak amacıyla parolanızı saklamak için ssh-agent kimlik doğrulama aracısını kullanabilirsiniz.

Belirli bir kabuk istemi için parolanızı kaydetmek için şu komutu kullanın:

~]$ ssh-add
Enter passphrase for /home/KULLANICI/.ssh/id_rsa:

Oturumu kapattığınızda parolanızın unutulacağını unutmayın. Komutu, bir sanal konsolda veya bir terminal penceresinde her oturum açtığınızda çalıştırmanız gerekir.

OpenSSH Sertifika Kimlik Doğrulamasını Kullanma

SSH Sertifikalarına Giriş

Kimlik doğrulama için genel anahtar şifrelemesinin kullanılması, genel anahtarın her istemciden istemcinin oturum açmayı planladığı her sunucuya kopyalanmasını gerektirir. Bu sistem iyi ölçeklenmez ve yönetimsel bir yük olabilir. İstemci sertifikalarının kimliğini doğrulamak için bir sertifika yetkilisinden (certificate authority) (CA) bir genel anahtar kullanmak, birden çok sistem arasında anahtar kopyalama ihtiyacını ortadan kaldırır. X.509 Genel Anahtar Alt Yapısı Sertifika sistemi bu soruna bir çözüm sunarken, bir sertifikanın imzalanması için ilgili ücretlerle birlikte sertifikanın gönderilmesi ve onaylanması süreci vardır. Alternatif olarak OpenSSH, basit sertifikaların ve ilgili CA alt yapısının oluşturulmasını destekler.

OpenSSH sertifikaları bir genel anahtar, kimlik bilgileri ve geçerlilik kısıtlamaları içerir. ssh-keygen programı kullanılarak standart bir SSH genel anahtarıyla imzalanırlar. Sertifikanın biçimi /usr/share/doc/openssh-sürüm/PROTOCOL.certkeys dosyasında açıklanmaktadır.

ssh-keygen programı iki tür sertifikayı destekler: kullanıcı ve ana makine. Kullanıcı sertifikaları, kullanıcıların kimliklerini sunuculara doğrularken, ana makine sertifikaları, sunucu ana makinelerini kullanıcılara doğrular. Kullanıcı veya ana makine kimlik doğrulaması için kullanılacak sertifikalar için sshd, CA genel anahtarına güvenecek şekilde yapılandırılmalıdır.

SSH Sertifikaları Desteği

Yeni OpenSSH sertifika biçimini kullanan kullanıcıların ve ana makinelerin sertifika kimlik doğrulaması desteği, Fedora 13’te openssh-5.4p1-1.fc13 paketinde tanıtılmıştır. Gerekirse, en yeni OpenSSH paketinin kurulu olduğundan emin olmak için root olarak şu komutu girin:

~]# dnf install openssh
Last metadata expiration check performed 0:58:01 ago on Sun Sep  6 16:07:22 2015.
Package openssh-7.1p1-1.fc23.x86_64 is already installed, skipping.

SSH CA Sertifika İmzalama Anahtarları Oluşturma

İki tür sertifika gereklidir, ana makine sertifikaları ve kullanıcı sertifikaları. İki sertifikayı imzalamak için iki ayrı anahtara sahip olmak daha iyidir, örneğin ca_user_key ve ca_host_key, ancak her iki sertifikayı da imzalamak için yalnızca bir CA anahtarı kullanmak mümkündür. Ayrı anahtarlar kullanılıyorsa adımları takip etmek de daha kolaydır, bu nedenle aşağıdaki örneklerde ayrı anahtarlar kullanılacaktır.

Kullanıcı sertifikası oluşturmak için kullanıcının genel anahtarını imzalama komutunun temel biçimi şu şekildedir:

ssh-keygen -s ca_user_key -I sertifika_kimliği id_rsa.pub

-s, sertifikayı imzalamak için kullanılan özel anahtarı belirtirken -I, herhangi bir alfasayısal değer olabilen sertifika_kimliği kimlik dizgesini belirtir. Sertifikada sıfır ile sonlandırılmış bir dizge olarak saklanır. sertifika_kimliği, sertifika tanımlama için her kullanıldığında günlüğe kaydedilir ve ayrıca bir sertifika iptal edilirken de kullanılır. Uzun bir değer kullanmak olmak günlüklerin okunmasını zorlaştırır, bu nedenle ana makine sertifikaları için ana makine adını ve kullanıcı sertifikaları için kullanıcı adını kullanmak güvenli bir seçimdir.

Bir ana makine sertifikası oluşturmak üzere bir ana makine genel anahtarını imzalamak için -h seçeneğini ekleyin:

ssh-keygen -s ca_host_key -I sertifika_kimliği -h ssh_host_rsa_key.pub

Ana makine anahtarları sistemde öntanımlı olarak oluşturulur, anahtarları listelemek için şu şekilde bir komut girin:

~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  668 Jul  9  2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root  590 Jul  9  2014 /etc/ssh/ssh_host_dsa_key.pub
-rw-------. 1 root root  963 Jul  9  2014 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root  627 Jul  9  2014 /etc/ssh/ssh_host_key.pub
-rw-------. 1 root root 1671 Jul  9  2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 Jul  9  2014 /etc/ssh/ssh_host_rsa_key.pub

CA anahtarlarını, diğer özel anahtarlarda olduğu gibi güvenli bir yerde oluşturmanız ve saklamanız tavsiye edilir. Bu örneklerde root kullanıcısı kullanılacaktır. Gerçek bir üretim ortamında, bir yönetici kullanıcı hesabıyla çevrim dışı bir bilgisayar kullanılması tavsiye edilir. Anahtar uzunluklarına ilişkin rehberlik için NIST Özel Yayın 800-131A Revizyon 1 adresine bakın.

SSH CA Sertifika İmzalama Anahtarları Oluşturma
  1. CA olarak belirlenen sunucuda, sertifikaları imzalamak için iki anahtar oluşturun. Bunlar, diğer tüm ana makinelerin güvenmesi gereken anahtarlardır. Uygun adları seçin, örneğin ca_user_key ve ca_host_key. Kullanıcı sertifikası imzalama anahtarını oluşturmak için root olarak şu komutu girin:

    ~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key
    Generating public/private rsa key pair.
    Created directory '/root/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/ca_user_key.
    Your public key has been saved in /root/.ssh/ca_user_key.pub.
    The key fingerprint is:
    11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root@ana_makine_adi.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |       .+.      o|
    |       . o     +.|
    |      o + .   . o|
    |       o + . . ..|
    |        S . ... *|
    |        . . . .*.|
    |         = E  .. |
    |        . o .    |
    |           .     |
    +-----------------+

    Şu şekilde bir ana makine sertifikası imzalama anahtarı ca_host_key oluşturun:

    ~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/ca_host_key.
    Your public key has been saved in /root/.ssh/ca_host_key.pub.
    The key fingerprint is:
    e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root@ana_makine_adi.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |            ..   |
    |           . ....|
    |        . . o +oo|
    |       o .   o *o|
    |        S     = .|
    |             o. .|
    |            *.E. |
    |           +o=   |
    |          .oo.   |
    +-----------------+

    Gerekirse izinlerin doğru olduğunu onaylayın:

    ~]# ls -la ~/.ssh
    total 40
    drwxrwxrwx. 2 root root 4096 May 22 13:18 .
    dr-xr-x---. 3 root root 4096 May  8 08:34 ..
    -rw-------. 1 root root 1743 May 22 13:15 ca_host_key
    -rw-r--r--. 1 root root  420 May 22 13:15 ca_host_key.pub
    -rw-------. 1 root root 1743 May 22 13:14 ca_user_key
    -rw-r--r--. 1 root root  420 May 22 13:14 ca_user_key.pub
    -rw-r--r--. 1 root root  854 May  8 05:55 known_hosts
    -r--------. 1 root root 1671 May  6 17:13 ssh_host_rsa
    -rw-r--r--. 1 root root 1370 May  7 14:30 ssh_host_rsa-cert.pub
    -rw-------. 1 root root  420 May  6 17:13 ssh_host_rsa.pub
  2. Ana makine adı, sonunda . işareti olmadan CA sunucusunun tam nitelikli etki alanı adı (fully qualified domain name) (FQDN) gibi bir tanımlama dizgesi ve bir geçerlilik süresiyle sunucunun genel anahtarını imzalayarak CA sunucusunun kendi ana makine sertifikasını oluşturun. Kullanılacak komut şu şekildedir:

    ssh-keygen -s ~/.ssh/ca_host_key -I sertifika_kimliği -h -n ana_makine_adi.example.com -V -başlangıç:+bitiş /etc/ssh/ssh_host_rsa.pub

    -n seçeneği, bu sertifikayı etki alanı içindeki belirli bir ana makineyle kısıtlar. -V seçeneği bir geçerlilik süresi eklemek içindir, bu şiddetle tavsiye edilir. Geçerlilik süresinin bir yıl, elli iki hafta olması amaçlanıyorsa, sertifikaları değiştirmek için gereken süreyi ve sertifikanın sona erme zamanı civarındaki tatil dönemlerini göz önünde bulundurun.

    Örneğin:

    ~]# ssh-keygen -s ~/.ssh/ca_host_key -I ana_makine_adi -h -n ana_makine_adi.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
    Enter passphrase:
    Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "ana_makine_adi" serial 0 for ana_makine_adi.example.com valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29

SSH CA Genel Anahtarlarını Dağıtma ve Onlara Güvenme

Kullanıcıların sertifika ile oturum açmasına izin verecek ana makineler, kullanıcının sertifikalarının kimliğini doğrulamak için kullanıcı sertifikalarını imzalamak için kullanılan CA’nın genel anahtarına güvenecek şekilde yapılandırılmalıdır. Bu örnekte bu ca_user_key.pub anahtarıdır.

ca_user_key.pub anahtarını yayınlayın ve uzak kullanıcıların oturum açmasına izin vermek için gerekli olan tüm ana makinelere indirin. Alternatif olarak, CA kullanıcı genel anahtarını tüm ana makinelere kopyalayın. Üretim ortamında, genel anahtarı önce bir yönetici hesabına kopyalamayı düşünün. Genel anahtarı uzak ana makinelere kopyalamak için güvenli kopyalama komutu kullanılabilir. Komut aşağıdaki biçime sahiptir:

scp  ~/.ssh/ca_user_key.pub root@ana_makine_adi.example.com:/etc/ssh/

Burada ana_makine_adi, oturum açma işlemi sırasında sunulan kullanıcı sertifikalarının kimliğini doğrulamak için gerekli olan sunucunun ana makine adıdır. Özel anahtarı değil genel anahtarı kopyaladığınızdan emin olun. Örneğin, root olarak:

~]# scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
The authenticity of host 'host_name.example.com (10.34.74.56)' can't be established.
RSA key fingerprint is fc:23:ad:ae:10:6f:d1:a1:67:ee:b1:d5:37:d4:b0:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'host_name.example.com,10.34.74.56' (RSA) to the list of known hosts.
root@host_name.example.com's password:
ca_user_key.pub                                       100%  420     0.4KB/s   00:00

Uzak kullanıcı kimlik doğrulaması için, CA anahtarları ~/.ssh/authorized_keys dosyasında cert-authority yönergesi kullanılarak kullanıcı başına veya /etc/ssh/sshd_config dosyasında TrustedUserCAKeys yönergesi kullanılarak genel kullanım için güvenilir olarak işaretlenebilir. Uzak ana makine kimlik doğrulaması için, CA anahtarları /etc/ssh/known_hosts dosyasında genel olarak veya ~/.ssh/ssh_known_hosts dosyasında kullanıcı başına güvenilir olarak işaretlenebilir.

Kullanıcı İmzalama Anahtarına Güvenme
  1. Bir veya daha fazla ilkenin listelendiği ve ayarın genel etkiye sahip olacağı kullanıcı sertifikaları için /etc/ssh/sshd_config dosyasını aşağıdaki gibi düzenleyin:

    TrustedUserCAKeys /etc/ssh/ca_user_key.pub

    Değişikliklerin etkili olması için sshd hizmetini yeniden başlatın:

    ~]# service sshd restart

Bilinmeyen bir ana makineyle ilgili uyarıyla karşılaşmamak için, kullanıcının sistemi ana makine sertifikalarını imzalamak için kullanılan CA’nın genel anahtarına güvenmelidir. Bu örnekte bu ca_host_key.pub anahtarıdır.

Ana Makine İmzalama Anahtarına Güvenme
  1. Ana makine sertifikasını imzalamak için kullanılan genel anahtarın içeriğini çıkarın. Örneğin, CA üzerinde:

    cat ~/.ssh/ca_host_key.pub
    ssh-rsa  AAAAB5Wm.== root@ca_sunucusu.example.com
  2. İstemci sistemlerini sunucuların imzalı ana makine sertifikalarına güvenecek şekilde yapılandırmak için, ca_host_key.pub dosyasının içeriğini genel known_hosts dosyasına ekleyin. Bu, *.example.com etki alanında yeni bir makineye her bağlanıldığında sunucunun ana makine sertifikasını tüm kullanıcılar için CA genel anahtarına karşı otomatik olarak denetleyecektir. root olarak oturum açın ve /etc/ssh/ssh_known_hosts dosyasını aşağıdaki gibi yapılandırın:

    ~]# vi /etc/ssh/ssh_known_hosts
    # A CA key, accepted for any host in *.example.com
    @cert-authority *.example.com ssh-rsa AAAAB5Wm.

    Burada ssh-rsa AAAAB5Wm. ca_host_key.pub anahtarının içeriğidir. Yukarıdaki, sistemi CA sunucularının ana makine genel anahtarına güvenecek şekilde yapılandırır. Bu, ana makineler tarafından uzak kullanıcılara sunulan sertifikaların genel kimlik doğrulamasını sağlar.

SSH Sertifikaları Oluşturma

Sertifika, imzalı bir genel anahtardır. Kullanıcının ve ana makinenin genel anahtarları, CA sunucusunun özel anahtarı tarafından imzalanmak üzere CA sunucusuna kopyalanmalıdır.

İmzalamak için CA’ya çok sayıda anahtar kopyalamak, benzersiz bir şekilde adlandırılmamışlarsa karışıklığa neden olabilir. Her zaman öntanımlı ad kullanılırsa, kopyalanacak en son anahtar daha önce kopyalanan anahtarın üzerine yazacak; bu da bir yönetici için kabul edilebilir bir yöntem olabilir. Aşağıdaki örnekte öntanımlı ad kullanılmıştır. Bir üretim ortamında, kolayca tanınabilir adlar kullanmayı düşünün. Anahtarların kopyalanması için CA sunucusunda yönetici bir kullanıcıya ait belirlenmiş bir dizin olması tavsiye edilir. Bu anahtarların root kullanıcısının /etc/ssh/ dizinine kopyalanması tavsiye edilmez. Aşağıdaki örneklerde anahtarlar/ adlı bir dizine sahip admin adlı bir hesap kullanılacaktır.

Bu örnekte admin olan bir yönetici hesabı ve kullanıcının anahtarlarını almak için bir dizin oluşturun. Örneğin:

~]$ mkdir anahtarlar

Anahtarların kopyalanmasına izin vermek için izinleri ayarlayın:

~]$ chmod o+w anahtarlar
ls -la anahtarlar
total 8
drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
drwx------. 3 admin admin 4096 May 22 16:17 ..

Ana Makinelerin Kimliğini Doğrulamak için SSH Sertifikaları Oluşturma

Bir ana makine sertifikasını imzalamak için kullanılan komut aşağıdaki gibidir:

ssh-keygen -s ca_host_key -I ana_makine_adi -h ssh_host_rsa_key.pub

Ana makine sertifikası ssh_host_rsa_key-cert.pub olarak adlandırılacaktır.

Ana Makine Sertifikası Oluşturma

Bir ana makinenin kimliğini bir kullanıcıya doğrulamak için ana makinede bir genel anahtar oluşturulmalı, CA sunucusuna iletilmeli, CA tarafından imzalanmalı ve ardından ana makinede oturum açmaya çalışan bir kullanıcıya sunulmak üzere ana makinede depolanmak üzere geri iletilmelidir.

  1. Ana makine anahtarları sistemde otomatik olarak oluşturulur. Bunları listelemek için aşağıdaki komutu çalıştırın:

    ~]# ls -l /etc/ssh/ssh_host*
    -rw-------. 1 root root  668 May  6 14:38 /etc/ssh/ssh_host_dsa_key
    -rw-r--r--. 1 root root  590 May  6 14:38 /etc/ssh/ssh_host_dsa_key.pub
    -rw-------. 1 root root  963 May  6 14:38 /etc/ssh/ssh_host_key
    -rw-r--r--. 1 root root  627 May  6 14:38 /etc/ssh/ssh_host_key.pub
    -rw-------. 1 root root 1679 May  6 14:38 /etc/ssh/ssh_host_rsa_key
    -rw-r--r--. 1 root root  382 May  6 14:38 /etc/ssh/ssh_host_rsa_key.pub
  2. Seçilen genel anahtarı CA olarak belirlenen sunucuya kopyalayın. Örneğin, ana makineden:

    ~]# scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
    The authenticity of host 'ca-server.example.com (10.34.74.58)' can't be established.
    RSA key fingerprint is b0:e5:ea:b8:75:e2:f0:b1:fe:5b:07:39:7f:58:64:d9.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
    admin@ca-server.example.com's password:
    ssh_host_rsa_key.pub                           100%  382     0.4KB/s   00:00

    Alternatif olarak, CA’dan:

    ~]$ scp  root@ana_makine_adi.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub
  3. CA sunucusunda, ana makinenin genel anahtarını imzalayın. Örneğin, root olarak:

    ~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
    Enter passphrase:
    Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-26T12:21:54 to 2016-06-08T12:21:54

    Burada ana_makine_adi sertifika gerektiren sistemin ana makine adıdır.

  4. Sertifikayı ana makineye kopyalayın. Örneğin, CA’dan:

    ~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@ana_makine_adi.example.com:/etc/ssh/
    root@ana_makine_adi.example.com's password:
    ssh_host_rsa_key-cert.pub                      100% 1384     1.5KB/s   00:00
  5. Ana makineyi, kullanıcı oturum açma işlemini başlattığında sertifikayı kullanıcının sistemine sunacak şekilde yapılandırın. root olarak /etc/ssh/sshd_config dosyasını aşağıdaki gibi düzenleyin:

    HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
  6. Değişikliklerin etkili olması için sshd hizmetini yeniden başlatın:

    ~]# service sshd restart
  7. Kullanıcının sistemlerinde, kullanıcı daha önce yukarıda yapılandırılan ana makinede oturum açmışsa, ana makinelere ait anahtarları ~/.ssh/known_hosts dosyasından kaldırın. Kullanıcı ana makinede oturum açtığında artık ana makinenin kimliğinin doğruluğu hakkında bir uyarı ile karşılaşmayacaktır.

To test the host certificate, on a client system, ensure the client has set up the global /etc/ssh/known_hosts file, as described in Trusting the Host Signing Key, and that the server’s public key is not in the ~/.ssh/known_hosts file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the -v option to the SSH command to see logging information.

Creating SSH Certificates for Authenticating Users

To sign a user’s certificate, use a command in the following format:

ssh-keygen -s ca_user_key -I user_name -n user_name -V -start:+end id_rsa.pub

The resulting certificate will be named id_rsa-cert.pub.

The default behavior of OpenSSH is that a user is allowed to log in as a remote user if one of the principals specified in the certificate matches the remote user’s name. This can be adjusted in the following ways:

  • Add more user’s names to the certificate during the signing process using the -n option:

    -n "name1[,name2,...]"
  • On the user’s system, add the public key of the CA in the ~/.ssh/authorized_keys file using the cert-authority directive and list the principals names as follows:

    ~]# vi ~/.ssh/authorized_keys
    # A CA key, accepted for any host in *.example.com
    @cert-authority principals="name1,name2" *.example.com ssh-rsa AAAAB5Wm.
  • On the server, create an AuthorizedPrincipalsFile file, either per user or glabally, and add the principles' names to the file for those users allowed to log in. Then in the /etc/ssh/sshd_config file, specify the file using the AuthorizedPrincipalsFile directive.

Generating a User Certificate

To authenticate a user to a remote host, a public key must be generated by the user, passed to the CA server, signed by the CA, and then passed back to be stored by the user for use when logging in to a host.

  1. On client systems, login as the user who requires the certificate. Check for available keys as follows:

    ~]$ ls -l ~/.ssh/

    If no suitable public key exists, generate one and set the directory permissions if the directory is not the default directory. For example, enter the following command:

    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/user1/.ssh/id_rsa):
    Created directory '/home/user1/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/user1/.ssh/id_rsa.
    Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
    The key fingerprint is:
    b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1@host1.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |    oo++.        |
    |   o.o.o.        |
    |   .o o .        |
    |    oo . o       |
    |   . oo.S        |
    |     o=..        |
    |     .Eo+        |
    |      .=         |
    |     ..          |
    +-----------------+

    By default the directory permissions for a user’s keys are drwx------., or octal 0700. If required, confirm the permissions are correct:

    ~]$ ls -la ~/.ssh
    total 16
    drwx------. 2 user1 user1 4096 May  7 12:37 .
    drwx------. 3 user1 user1 4096 May  7 12:37 ..
    -rw-------. 1 user1 user1 1679 May  7 12:37 id_rsa
    -rw-r--r--. 1 user1 user1  421 May  7 12:37 id_rsa.pub

    See Using Key-based Authentication for more examples of key generation and for instructions on setting the correct directory permissions.

  2. The chosen public key must be copied to the server designated as the CA, in order to be signed. The secure copy command can be used to do this, the command has the following format:

    scp  ~/.ssh/id_protocol.pub admin@ca_server.example.com:~/keys/

    Where protocol is the part of the file name indicating the protocol used to generate the key, for example rsa, admin is an account on the CA server, and /keys/ is a directory setup to receive the keys to be signed.

    Copy the chosen public key to the server designated as the CA. For example:

    ~]$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
    admin@ca-server.example.com's password:
    id_rsa.pub                                  100%  421     0.4KB/s   00:00

    If you have configured the client system to trust the host signing key as described in Trusting the Host Signing Key then you should not see a warning about the authenticity of the remote host.

  3. On the CA server, sign the user’s public key. For example, as root:

    ~]# ssh-keygen -s ~/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
    Enter passphrase:
    Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2015-05-21T16:43:17 to 2016-06-03T16:43:17
  4. Copy the resulting certificate to the user’s ~/.ssh/ directory on their system. For example:

    ~]# scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
    user1@host_name.example.com's password:
    id_rsa-cert.pub                             100%  1498    1.5KB/s   00:00
  5. If using the standard file names and location then no further configuration is required as the SSH daemon will search for user certificates ending in -cert.pub and use them automatically if it finds them. Note that the default location and file names for for SSH version 2 keys are: ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa as explained in the ssh_config(5) manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable sshd to present the certificate. They will be used automatically when logging in to a remote system. In this is the case then skip to step 6.

    If required to use a non-default directory or file naming convention, then as root, add the following line to the /etc/ssh/ssh_config or ~/.ssh/config files:

    IdentityFile ~/path/key_file

    Note that this must be the private key name, do not had .pub or -cert.pub. Ensure the file permission are correct. For example:

    ~]$ ls -la ~/.ssh/config
    -rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
    chmod 700 ~/.ssh/config
    ~]$ ls -la ~/.ssh/config
    -rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config

    This will enable the user of this system to be authenticated by a user certificate when logging into a remote system configured to trust the CA user certificate signing key.

  6. To test the user certificate, attempt to log into a server over SSH from the user’s account. You should do this as the user listed as a principle in the certificate, if any are specified. You should not be prompted for a password. If required, add the -v option to the SSH command to see logging information.

Signing an SSH Certificate Using a PKCS#11 Token

It is possible to sign a host key using a CA key stored in a PKCS#11 token by providing the token library using the -D and identifying the CA key by providing its public half as an argument to the -s option:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID host_key.pub

In all cases, certificate_ID is a "key identifier" that is logged by the server when the certificate is used for authentication.

Certificates may be configured to be valid only for a set of users or host names, the principals. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals, use a comma separated list with the -n option as follows:

ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I certificate_ID -n user1,user2 id_rsa.pub

and for hosts:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID -h -n host.domain ssh_host_rsa_key.pub

Additional limitations on the validity and use of user certificates may be specified through certificate options. A certificate option may disable features of the SSH session, may be valid only when presented from particular source addresses or may force the use of a specific command. For a list of valid certificate options, see the ssh-keygen(1) manual page for the -O option.

Certificates may be defined to be valid for a specific lifetime. The -V option allows specifying a certificates start and end times. For example:

ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub -V "-1w:+54w5d"

A certificate that is presented at a time outside this range will not be considered valid. By default, certificates are valid indefinitely starting from UNIX Epoch.

Viewing an SSH CA Certificate

To view a certificate, use the -L to list the contents. For example, for a user’s certificate:

~]$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
/home/user1/.ssh/id_rsa-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86
        Signing CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8
        Key ID: "user1"
        Serial: 0
        Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16
        Principals:
                user1
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

To vew a host certificate:

~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23
        Signing CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a
        Key ID: "host_name"
        Serial: 0
        Valid: from 2015-05-26T17:19:01 to 2016-06-08T17:19:01
        Principals:
                host_name.example.com
        Critical Options: (none)
        Extensions: (none)

Revoking an SSH CA Certificate

If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed.

Keys can be revoked by adding them to the revoked_keys file and specifying the file name in the sshd_config file as follows:

RevokedKeys /etc/ssh/revoked_keys

Note that if this file is not readable, then public key authentication will be refused for all users.

A new key revocation list can be generated as follows:

~]$ ssh-keygen -kf  /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub

To add lines to the list, use the -u option to update the list:

ssh-keygen -ukf /etc/ssh/revoked_keys -z integer ~/.ssh/id_rsa.pub

where integer is the line number.

To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:

ssh-keygen -Qf  /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub

A user can revoke a CA certificate by changing the cert-authority directive to revoke in the known_hosts file.

OpenSSH Clients

İlgili paketlerin kurulu olduğundan emin olun

To connect to an OpenSSH server from a client machine, you must have the openssh-clients package installed. See Installing Packages for more information on how to install new packages in Fedora 31.

Using the ssh Utility

The ssh utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the rlogin, rsh, and telnet programs.

Similarly to the telnet command, log in to a remote machine by using the following command:

ssh hostname

For example, to log in to a remote machine named penguin.example.com, type the following at a shell prompt:

~]$ ssh penguin.example.com

This will log you in with the same user name you are using on the local machine. If you want to specify a different user name, use a command in the following form:

ssh username@hostname

For example, to log in to penguin.example.com as USER, type:

The first time you initiate a connection, you will be presented with a message similar to this:

The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is 256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff.
Are you sure you want to continue connecting (yes/no)?

Users should always check if the fingerprint is correct before answering the question in this dialog. The user can ask the administrator of the server to confirm the key is correct. This should be done in a secure and previously agreed way. If the user has access to the server’s host keys, the fingerprint can be checked by using the ssh-keygen command as follows:

~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff   (ECDSA)

Type yes to accept the key and confirm the connection. You will see a notice that the server has been added to the list of known hosts, and a prompt asking for your password:

Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:
Updating the host key of an SSH server

If the SSH server’s host key changes, the client notifies the user that the connection cannot proceed until the server’s host key is deleted from the ~/.ssh/known_hosts file. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised.

To remove a key from the ~/.ssh/known_hosts file, issue a command as follows:

~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old

After entering the password, you will be provided with a shell prompt for the remote machine.

Alternatively, the ssh program can be used to execute a command on the remote machine without logging in to a shell prompt:

ssh username@hostname command

For example, the /etc/redhat-release file provides information about the Fedora version. To view the contents of this file on penguin.example.com, type:

~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Fedora release 20 (Heisenbug)

After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.

Using the scp Utility

scp can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to rcp.

To transfer a local file to a remote system, use a command in the following form:

scp localfile username@hostname:remotefile

For example, if you want to transfer taglist.vim to a remote machine named penguin.example.com, type the following at a shell prompt:

~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim                                   100%  144KB 144.5KB/s   00:00

Multiple files can be specified at once. To transfer the contents of .vim/plugin/ to the same directory on the remote machine penguin.example.com, type the following command:

~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim                                  100%   13KB  12.6KB/s   00:00
snippetsEmu.vim                               100%   33KB  33.1KB/s   00:00
taglist.vim                                   100%  144KB 144.5KB/s   00:00

To transfer a remote file to the local system, use the following syntax:

scp username@hostname:remotefile localfile

For instance, to download the .vimrc configuration file from the remote machine, type:

~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

Using the sftp Utility

The sftp utility can be used to open a secure, interactive FTP session. In its design, it is similar to ftp except that it uses a secure, encrypted connection.

To connect to a remote system, use a command in the following form:

sftp username@hostname

For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:

~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>

After you enter the correct password, you will be presented with a prompt. The sftp utility accepts a set of commands similar to those used by ftp (see A selection of available sftp commands).

Tablo 3. A selection of available sftp commands
Command Description

ls [directory]

List the content of a remote directory. If none is supplied, a current working directory is used by default.

cd directory

Change the remote working directory to directory.

mkdir directory

Create a remote directory.

rmdir path

Remove a remote directory.

put localfile [remotefile]

Transfer localfile to a remote machine.

get remotefile [localfile]

Transfer remotefile from a remote machine.

For a complete list of available commands, see the sftp(1) manual page.

More Than a Secure Shell

A secure command line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.

X11 Forwarding

To open an X11 session over an SSH connection, use a command in the following form:

ssh -Y username@hostname

For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:

When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently.

Note that the X Window system must be installed on the remote system before X11 forwarding can take place. Enter the following command as root to install the X11 package group:

~]# dnf group install "X Window System"

X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Print Settings utility. To do this, connect to the server using ssh and type:

~]$ system-config-printer &

The Print Settings tool will appear, allowing the remote user to safely configure printing on the remote system.

Port Forwarding

SSH can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.

Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.

Using reserved port numbers

Setting up port forwarding to listen on ports below 1024 requires root level access.

To create a TCP/IP port forwarding channel which listens for connections on the localhost, use a command in the following form:

ssh -L local-port:remote-hostname:remote-port username@hostname

For example, to check email on a server called mail.example.com using POP3 through an encrypted connection, use the following command:

~]$ ssh -L 1100:mail.example.com:110 mail.example.com

Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port 1100 on the localhost to check for new email. Any requests sent to port 1100 on the client system will be directed securely to the mail.example.com server.

If mail.example.com is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:

~]$ ssh -L 1100:mail.example.com:110 other.example.com

In this example, POP3 requests from port 1100 on the client machine are forwarded through the SSH connection on port 22 to the SSH server, other.example.com. Then, other.example.com connects to port 110 on mail.example.com to check for new email. Note that when using this technique, only the connection between the client system and other.example.com SSH server is secure.

Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.

A connection is only as secure as a client system

Using port forwarding to forward connections in this manner allows any user on the client system to connect to that service. If the client system becomes compromised, the attacker also has access to forwarded services.

System administrators concerned about port forwarding can disable this functionality on the server by specifying a No parameter for the AllowTcpForwarding line in /etc/ssh/sshd_config and restarting the sshd service.

Ek Kaynaklar

For more information on how to configure or connect to an OpenSSH server on Fedora, see the resources listed below.

Kurulu Belgeler
  • sshd(8) — The manual page for the sshd daemon documents available command line options and provides a complete list of supported configuration files and directories.

  • ssh(1) — The manual page for the ssh client application provides a complete list of available command line options and supported configuration files and directories.

  • scp(1) — The manual page for the scp utility provides a more detailed description of this utility and its usage.

  • sftp(1) — The manual page for the sftp utility.

  • ssh-keygen(1) — The manual page for the ssh-keygen utility documents in detail how to use it to generate, manage, and convert authentication keys used by ssh.

  • ssh_config(5) — The manual page named ssh_config documents available SSH client configuration options.

  • sshd_config(5) — The manual page named sshd_config provides a full description of available SSH daemon configuration options.

Çevrim İçi Belgelendirme
  • OpenSSH Home Page — The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.

  • OpenSSL Home Page — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.


1. Çoğullanmış bir bağlantı, paylaşılan ortak bir ortam üzerinden gönderilen birkaç sinyalden oluşur. SSH ile ortak bir güvenli bağlantı üzerinden farklı kanallar gönderilir.