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 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ğiniyes
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.
-
İstemcinin doğru sunucuyla iletişim kurduğunu doğrulayabilmesi için kriptografik bir el sıkışma yapılır.
-
İstemci ve uzak ana makine arasındaki bağlantının taşıma katmanı, simetrik bir şifre kullanılarak şifrelenir.
-
İstemci kendi kimliğini sunucuya doğrular.
-
İ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.
Dosya | Açıklama |
---|---|
|
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. |
|
Öntanımlı SSH istemci yapılandırma dosyası. Bunun, varsa |
|
sshd arka plan programı için yapılandırma dosyası. |
|
sshd arka plan programı tarafından kullanılan ECDSA özel anahtarı. |
|
sshd arka plan programı tarafından kullanılan ECDSA genel anahtarı. |
|
SSH protokolünün 1. sürümü için sshd arka plan programı tarafından kullanılan RSA özel anahtarı. |
|
SSH protokolünün 1. sürümü için sshd arka plan programı tarafından kullanılan RSA genel anahtarı. |
|
SSH protokolünün 2. sürümü için sshd arka plan programı tarafından kullanılan RSA özel anahtarı. |
|
SSH protokolünün 2. sürümü için sshd arka plan programı tarafından kullanılan RSA genel anahtarı. |
|
sshd arka plan programı için PAM yapılandırma dosyası. |
|
|
Dosya | Açıklama |
---|---|
|
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. |
|
Kullanıcının ECDSA özel anahtarını içerir. |
|
Kullanıcının ECDSA genel anahtarı. |
|
SSH protokolünün 2. sürümü için ssh tarafından kullanılan RSA özel anahtarı. |
|
SSH protokolünün 2. sürümü için ssh tarafından kullanılan RSA genel anahtarı. |
|
SSH protokolünün 1. sürümü için ssh tarafından kullanılan RSA özel anahtarı. |
|
SSH protokolünün 1. sürümü için ssh tarafından kullanılan RSA genel anahtarı. |
|
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 26’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 26, ö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ı |
~/.ssh/ dizininizi yedekleyin
Sisteminizi yeniden kurarsanız ve önceden oluşturulmuş anahtar çiftlerini korumak isterseniz, |
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:
-
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):
-
Yeni oluşturulan anahtarın
~/.ssh/id_rsa
olan öntanımlı konumunu onaylamak için Enter tuşuna basın. -
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.| +-----------------+
-
Öntanımlı olarak,
~/.ssh/
dizininin izinlerirwx------
(sekizlik taban gösteriminde700
) 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/
-
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:
-
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):
-
Yeni oluşturulan anahtarın
~/.ssh/id_ecdsa
olan öntanımlı konumunu onaylamak için Enter tuşuna basın. -
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 | | | | | +-----------------+
-
Öntanımlı olarak,
~/.ssh/
dizininin izinlerirwx------
(sekizlik taban gösteriminde700
) 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/
-
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 |
-
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
veca_host_key
. Kullanıcı sertifikası imzalama anahtarını oluşturmak içinroot
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
-
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.
-
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 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
-
İ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 genelknown_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 |
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 ..
Creating SSH Certificates to Authenticate Hosts
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.
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.
-
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
-
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
-
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.
-
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
-
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
-
Değişikliklerin etkili olması için
sshd
hizmetini yeniden başlatın:~]# service sshd restart
-
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.
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.
-
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.
-
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.
-
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
-
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
-
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 thessh_config(5)
manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enablesshd
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.
-
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 26. |
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:
~]$ ssh USER@penguin.example.com
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 To remove a key from the ~]# 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).
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:
~]$ ssh -Y USER@penguin.example.com USER@penguin.example.com's password:
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 |
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 |
Ek Kaynaklar
For more information on how to configure or connect to an OpenSSH server on Fedora, see the resources listed below.
-
sshd
(8) — The manual page for thesshd
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 namedssh_config
documents available SSH client configuration options. -
sshd_config
(5) — The manual page namedsshd_config
provides a full description of available SSH daemon configuration options.
-
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.
Want to help? Learn how to contribute to Fedora Docs ›