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:

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.

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

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

Ş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.

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

İ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.

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.

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

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

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

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:

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.

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:

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

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.

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:

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 27, ö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).

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.

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:

İ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:

-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:

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

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:

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:

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.

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.

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.

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

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

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:

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:

and for hosts:

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:

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.

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

To vew a host 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:

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:

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

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:

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

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:

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

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:

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:

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:

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:

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:

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:

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

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:

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

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:

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

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

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:

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

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).

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

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

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:

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:

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

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.

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

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

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:

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.