OpenSSH
SSH
(Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP
, Telnet
, or rlogin, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
The ssh program is designed to replace older, less secure terminal applications used to log into remote hosts, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as rcp. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
Fedora includes the general OpenSSH package, openssh, as well as the OpenSSH server, openssh-server, and client, openssh-clients, packages. Note, the OpenSSH packages require the OpenSSL package openssl-libs, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
SSH 통신규약
왜 SSH를 사용하나요?
Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
- 두 시스템 사이에서 통신 차단
-
The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.
This attack is usually performed using a packet sniffer, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
- 특정한 호스트 사칭
-
Attacker’s system is configured to pose as the intended recipient of a transmission. If this strategy works, the user’s system remains unaware that it is communicating with the wrong host.
This attack can be performed using a technique known as DNS poisoning, or via so-called IP spoofing. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.
Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.
주요 특징
SSH 통신규약은 다음 보호장치를 제공합니다:
- 누구도 의도된 서버로 가장 할 수 없습니다
-
초기 연결 후에, 클라이언트는 이전에 연결했던 동일한 서버에 연결하고 있는지 확인 할 수 있습니다.
- 누구도 인증 정보를 캡춰 할 수 없습니다
-
클라이언트는 이 인증 정보를 강력한 128-비트 암호를 사용하여 서버에 전달합니다.
- 누구도 통신을 가로 챌 수 없습니다
-
All data sent and received during a session is transferred using 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read.
추가적으로, 이는 또한 다음 옵션을 제공합니다:
- 네트워크를 통해서 그래픽 응용프로그램을 사용하는 보안 방식을 제공합니다
-
Using a technique called X11 forwarding, the client can forward X11 (X Window System) applications from the server. Note that if you set the
ForwardX11Trusted
option toyes
or you use SSH with the-Y
option, you bypass the X11 SECURITY extension controls, which can result in a security threat. - 이는 다른 비보안 통신규약을 보호하는 방법을 제공합니다
-
The SSH protocol encrypts everything it sends and receives. Using a technique called port forwarding, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
- 보안 채널을 생성하는 데 사용 될 수 있습니다
-
The OpenSSH server and client can be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
- 이는 커버러스 인증을 지원합니다
-
OpenSSH servers and clients can be configured to authenticate using the GSSAPI (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.
통신규약 버전
Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under Fedora uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well, although version 1 is disabled by default and needs to be enabled in the configuration files.
SSH 버전 1 사용을 피하기
To ensure maximum security for your connection, it is recommended that only SSH version 2-compatible servers and clients are used whenever possible. |
SSH 연결의 사건 연속
The following series of events help protect the integrity of SSH communication between two hosts.
-
A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
-
The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
-
클라이언트는 스스로 서버에 인증합니다.
-
클라이언트는 암호화된 연결을 통해서 원격 호스트로 상호작용합니다.
Transport Layer The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange:
-
키가 교환됩니다
-
공개 키 암호화 알고리즘이 결정되었습니다
-
대칭 암호화 알고리즘이 결정되었습니다
-
메시지 인증 알고리즘이 결정되었습니다
-
해쉬 알고리즘이 결정되었습니다
During the key exchange, the server identifies itself to the client with a unique host key. If the client has never communicated with this particular server before, the server’s host key is unknown to the client and it does not connect. OpenSSH notifies the user that the authenticity of the host cannot be established and prompts the user to accept or reject it. The user is expected to independently verify the new host key before accepting it. In subsequent connections, the server’s host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client’s saved version before a connection can occur.
항상 새로운 SSH 서버의 무결성을 확인하세요
It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch. |
SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.
After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.
Authentication Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
Channels After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing[1]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
OpenSSH 구성하기
In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as root
by typing:
su -
구성 파일
There are two different sets of configuration files: those for client programs (that is, ssh, scp, and sftp), and those for the server (the sshd daemon). System-wide SSH configuration information is stored in the /etc/ssh/
directory as described in System-wide configuration files. User-specific SSH configuration information is stored in ~/.ssh/
within the user’s home directory as described in User-specific configuration files.
파일 | 설명 |
---|---|
|
Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication. |
|
The default SSH client configuration file. Note that it is overridden by |
|
The configuration file for the sshd daemon. |
|
The ECDSA private key used by the sshd daemon. |
|
The ECDSA public key used by the sshd daemon. |
|
The RSA private key used by the sshd daemon for version 1 of the SSH protocol. |
|
The RSA public key used by the sshd daemon for version 1 of the SSH protocol. |
|
The RSA private key used by the sshd daemon for version 2 of the SSH protocol. |
|
The RSA public key used by the sshd daemon for version 2 of the SSH protocol. |
|
The PAM configuration file for the sshd daemon. |
|
Configuration file for the |
파일 | 설명 |
---|---|
|
Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file. |
|
Contains the ECDSA private key of the user. |
|
The ECDSA public key of the user. |
|
The RSA private key used by ssh for version 2 of the SSH protocol. |
|
The RSA public key used by ssh for version 2 of the SSH protocol. |
|
The RSA private key used by ssh for version 1 of the SSH protocol. |
|
The RSA public key used by ssh for version 1 of the SSH protocol. |
|
Contains host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting to the correct SSH server. |
SSH 구성 파일에서 사용 될 수 있는 다양한 지시문과 연관된 정보를 위해, ssh_config
(5) 과 sshd_config
(5) 설명서 부분을 찹고하세요.
OpenSSH 서버 시작하기
관련 꾸러미가 설치되어 있는지 확인합니다
To run an OpenSSH server, you must have the openssh-server package installed. See Installing Packages for more information on how to install new packages in Fedora 27. |
현재 세션에서 동작 중인 sshd 데몬을 시작하려면, `root`으로 쉘 입력기에서 다음과 같이 입력하세요:
~]# systemctl start sshd.service
현재 세션에서 동작 중인 sshd 데몬을 멈추려면, `root`으로 다음 명령을 사용하세요:
~]# systemctl stop sshd.service
만약 당신이 데몬을 부팅 시에 자동으로 시작하고자 하면, `root`으로 다음과 같이 입력하세요:
~]# systemctl enable sshd.service ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
Fedora에서 서비스를 구성하는 방법에 대한 더 많은 정보를 위해 서비스 및 데몬을 참고하세요.
Note that if you reinstall the system, a new set of identification keys will be created. As a result, clients who had connected to the system with any of the OpenSSH tools before the reinstall will see the following message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 경고: 원격 호스트 식별이 변경되었습니다! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 누군가 불쾌한 일을 하고 있을 수 있습니다! 누군가 지금 당신을 도청 할 수 있습니다 (중간자 공격)! 이는 또한 RSA 호스트 키가 단지 변경 되었을 수도 있습니다.
To prevent this, you can backup the relevant files from the /etc/ssh/
directory (see System-wide configuration files for a complete list), and restore them whenever you reinstall the system.
원격 연결을 위한 SSH 필요
For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user’s password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include telnet, rsh, rlogin, and vsftpd.
These services are not installed by default in Fedora. If required, to make sure these services are not running, type the following commands at a shell prompt:
systemctl stop telnet.service systemctl stop rsh.service systemctl stop rlogin.service systemctl stop vsftpd.service
시작 할 때에 동작하는 이들 서비스를 비활성화 하려면, 다음과 같이 입력하세요:
systemctl disable telnet.service systemctl disable rsh.service systemctl disable rlogin.service systemctl disable vsftpd.service
Fedora에서 서비스를 구성하는 방법에 대한 더 많은 정보를 위해 서비스 및 데몬을 참고하세요.
키-기반의 인증 사용하기
To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, open the /etc/ssh/sshd_config
configuration file in a text editor such as vi or nano, and change the PasswordAuthentication
option as follows:
PasswordAuthentication no
If you are working on a system other than a new default installation, check that PubkeyAuthentication no has not been set. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised.
To be able to use ssh, scp, or sftp to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
Fedora 27 uses SSH Protocol 2 and RSA keys by default (see Protocol Versions for more information).
root으로 키 쌍을 발생하지 않습니다
If you complete the steps as |
~/.ssh/ 디렉토리를 백업합니다
If you reinstall your system and want to keep previously generated key pairs, backup the |
Generating Key Pairs To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
-
쉘 명령에서 다음과 같이 입력하여 RSA 키 쌍을 발생합니다:
~]$ ssh-keygen -t rsa 공개/개인 rsa 키 쌍을 생성 중. 키를 저장하려는 파일을 입력 (/home/USER/.ssh/id_rsa):
-
Enter를 누르고 새롭게 생성되는 키를 위해
~/.ssh/id_rsa
기본 위치를 확인합니다. -
Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
After this, you will be presented with a message similar to this:
자신의 식별은 /home/USER/.ssh/id_rsa에 저장되었습니다. 자신의 공개키는 /home/USER/.ssh/id_rsa.pub에 저장되었습니다. 키 지문: e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@penguin.example.com 키 임의 구조 이미지: +--[ RSA 2048]----+ | E. | | . . | | o . | | . .| | S . . | | + o o ..| | * * +oo| | O +..=| | o* o.| +-----------------+
-
By default, the permissions of the
~/.ssh/
directory are set torwx------
or700
expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:~]$ ls -ld ~/.ssh drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
-
공개 키를 원격 장비에 복사하려면, 다음 형식에서 명령을 실행하세요:
ssh-copy-id user@hostname
This will copy the most recently modified
~/.ssh/id*.pub
public key if it is not yet installed. Alternatively, specify the public key’s file name as follows:ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
This will copy the content of
~/.ssh/id_rsa.pub
into the~/.ssh/authorized_keys
file on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
To generate an ECDSA key pair for version 2 of the SSH protocol, follow these steps:
-
쉘 입력기에서 다음과 같이 입력하여 ECDSA 키 쌍을 발생합니다:
~]$ ssh-keygen -t ecdsa 공개용/개인용 ecdsa 키 쌍을 생성중. 키를 저장하기 위한 곳에 파일을 입력합니다 (/home/USER/.ssh/id_ecdsa):
-
Enter를 누르고 새롭게 생성되는 키를 위해
~/.ssh/id_ecdsa
기본 위치를 확인합니다. -
Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
After this, you will be presented with a message similar to this:
Your identification has been saved in /home/USER/.ssh/id_ecdsa. Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub. The key fingerprint is: fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@penguin.example.com The key's randomart image is: +--[ECDSA 256]---+ | .+ +o | | . =.o | | o o + ..| | + + o +| | S o o oE.| | + oo+.| | + o | | | | | +-----------------+
-
By default, the permissions of the
~/.ssh/
directory are set torwx------
or700
expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:~]$ ls -ld ~/.ssh ~]$ ls -ld ~/.ssh/ drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
-
공개 키를 원격 장비에 복사하려면, 다음 형식에서 명령을 실행하세요:
ssh-copy-id USER@hostname
This will copy the most recently modified
~/.ssh/id*.pub
public key if it is not yet installed. Alternatively, specify the public key’s file name as follows:ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
This will copy the content of
~/.ssh/id_ecdsa.pub
into the~/.ssh/authorized_keys
on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
See Configuring ssh-agent for information on how to set up your system to remember the passphrase.
자신의 개인 키를 공유하지 마세요
개인 키는 자신의 개인적으로만 사용해야 하고, 그리고 누구에게도 이를 주지 않는 것이 중요합니다. |
Configuring ssh-agent To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the ssh-agent authentication agent.
특정 쉘 입력기를 위해 자신의 암호문를 저장하려면, 다음 명령을 사용하세요:
~]$ ssh-add /home/USER/.ssh/id_rsa를 위해 암호문을 입력:
Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.
OpenSSH 인증서 인증 사용하기
SSH 인증서에 대한 안내
Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a certificate authority (CA) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.
OpenSSH certificates contain a public key, identity information, and validity constraints. They are signed with a standard SSH public key using the ssh-keygen utility. The format of the certificate is described in /usr/share/doc/openssh-version/PROTOCOL.certkeys
.
The ssh-keygen utility supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. For certificates to be used for user or host authentication, sshd
must be configured to trust the CA public key.
SSH 인증서 지원
Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Fedora 13, in the openssh-5.4p1-1.fc13 package. If required, to ensure the latest OpenSSH package is installed, enter the following command as root
:
~]# dnf install openssh 최종 메타자료 만료 확인은 2015년 9월 6일 일요일 16시07분22초에서 0시58분1초 전에 수행되었습니다. 꾸러미 openssh-7.1p1-1.fc23.x86_64가 이미 설치되었으며, 건너뜁니다.
SSH CA 인증서 서명 키 생성하기
Two types of certificates are required, host certificates and user certificates. It is considered better to have two separate keys for signing the two certificates, for example ca_user_key
and ca_host_key
, however it is possible to use just one CA key to sign both certificates. It is also easier to follow the procedures if separate keys are used, so the examples that follow will use separate keys.
The basic format of the command to sign user’s public key to create a user certificate is as follows:
ssh-keygen -s ca_user_key -I 인증서_ID id_rsa.pub
Where -s
indicates the private key used to sign the certificate, -I
indicates an identity string, the certificate_ID, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The certificate_ID is logged whenever the certificate is used for identification and it is also used when revoking a certificate. Having a long value would make logs hard to read, therefore using the host name for host certificates and the user name for user certificates is a safe choice.
To sign a host’s public key to create a host certificate, add the -h
option:
ssh-keygen -s ca_host_key -I 인증서_ID -h ssh_host_rsa_key.pub
Host keys are generated on the system by default, to list the keys, enter a command as follows:
~]# 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
It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the |
-
On the server designated to be the CA, generate two keys for use in signing certificates. These are the keys that all other hosts need to trust. Choose suitable names, for example
ca_user_key
andca_host_key
. To generate the user certificate signing key, enter the following command asroot
:~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key 공개/개인 rsa 키 쌍을 생성 중. '/root/.ssh' 디렉토리가 생성되었습니다. 암호문을 입력하세요 (암호문이 없는 경우 공백): 다시 동일한 암호문을 입력하세요: 당신의 식별은 /root/.ssh/ca_user_key에 저장되었습니다. 당신의 공개 키는 /root/.ssh/ca_user_key.pub에 저장되었습니다. 키 지문은 다음과 같습니다: 11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root@host_name.example.com 키의 임의 기교 이미지는 다음과 같습니다: +--[ RSA 2048]----+ | .+. o| | . o +.| | o + . . o| | o + . . ..| | S . ... *| | . . . .*.| | = E .. | | . o . | | . | +-----------------+
다음과 같이 `ca_host_key`호스트 인증 서명 키를 발생합니다:
~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key 공개/개인 rsa 키 쌍을 생성 중. 암호문을 입력하세요 (암호문이 없는 경우 공백): 다시 동일한 암호문을 입력하세요: 당신의 식별은 /root/.ssh/ca_host_key에 저장되었습니다. 당신의 공개 키는 /root/.ssh/ca_host_key.pub에 저장되었습니다. 키 지문은 다음과 같습니다: e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root@host_name.example.com 키의 임의 기교 이미지는 다음과 같습니다: +--[ RSA 2048]----+ | .. | | . ....| | . . o +oo| | o . o *o| | S = .| | o. .| | *.E. | | +o= | | .oo. | +-----------------+
만약 필요하다면, 권한이 올바른지 확인하세요:
~]# ls -la ~/.ssh 합계 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
-
Create the CA server’s own host certificate by signing the server’s host public key together with an identification string such as the host name, the CA server’s fully qualified domain name (FQDN) but without the trailing
.
, and a validity period. The command takes the following form:ssh-keygen -s ~/.ssh/ca_host_key -I 인증서_ID -h -n host_name.example.com -V -start:+end /etc/ssh/ssh_host_rsa.pub
The
-n
option restricts this certificate to a specific host within the domain. The-V
option is for adding a validity period; this is highly recommend. Where the validity period is intended to be one year, fifty two weeks, consider the need for time to change the certificates and any holiday periods around the time of certificate expiry.예를 들어:
~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub 암호문을 입력: Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29
SSH CA 공개 키 배포와 신뢰하기
Hosts that are to allow certificate authenticated log in from users must be configured to trust the CA’s public key that was used to sign the user certificates, in order to authenticate user’s certificates. In this example that is the ca_user_key.pub
.
Publish the ca_user_key.pub
key and download it to all hosts that are required to allow remote users to log in. Alternately, copy the CA user public key to all the hosts. In a production environment, consider copying the public key to an administrator account first. The secure copy command can be used to copy the public key to remote hosts. The command has the following format:
scp ~/.ssh/ca_user_key.pub root@호스트_이름.example.com:/etc/ssh/
Where host_name is the host name of a server the is required to authenticate user’s certificates presented during the login process. Ensure you copy the public key not the private key. For example, as root
:
~]# 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
For remote user authentication, CA keys can be marked as trusted per-user in the ~/.ssh/authorized_keys
file using the cert-authority directive or for global use by means of the TrustedUserCAKeys directive in the /etc/ssh/sshd_config
file. For remote host authentication, CA keys can be marked as trusted globally in the /etc/ssh/known_hosts
file or per-user in the ~/.ssh/ssh_known_hosts
file.
-
For user certificates which have one or more principles listed, and where the setting is to have global effect, edit the
/etc/ssh/sshd_config
file as follows:TrustedUserCAKeys /etc/ssh/ca_user_key.pub
변경 사항을 적용하려면 `sshd`를 재시작하세요:
~]# service sshd restart
To avoid being presented with the warning about an unknown host, a user’s system must trust the CA’s public key that was used to sign the host certificates. In this example that is ca_host_key.pub
.
-
Extract the contents of the public key used to sign the host certificate. For example, on the CA:
cat ~/.ssh/ca_host_key.pub ssh-rsa AAAAB5Wm.== root@ca-server.example.com
-
To configure client systems to trust servers' signed host certificates, add the contents of the
ca_host_key.pub
into the globalknown_hosts
file. This will automatically check a server’s host advertised certificate against the CA public key for all users every time a new machine is connected to in the domain*.example.com
. Login asroot
and configure the/etc/ssh/ssh_known_hosts
file, as follows:~]# vi /etc/ssh/ssh_known_hosts # A CA key, accepted for any host in *.example.com @cert-authority *.example.com ssh-rsa AAAAB5Wm.
Where
ssh-rsa AAAAB5Wm.
is the contents ofca_host_key.pub
. The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by hosts to remote users.
SSH 인증서 생성하기
A certifcate is a signed public key. The user’s and host’s public keys must be copied to the CA server for signing by the CA server’s private key.
Copying many keys to the CA to be signed can create confusion if they are not uniquely named. If the default name is always used then the latest key to be copied will overwrite the previously copied key, which may be an acceptable method for one administrator. In the example below the default name is used. In a production environment, consider using easily recognizable names. It is recommend to have a designated directory on the CA server owned by an administrative user for the keys to be copied into. Copying these keys to the |
Create an administrator account, in this example admin
, and a directory to receive the user’s keys. For example:
~]$ mkdir keys
Set the permissions to allow keys to be copied in:
~]$ chmod o+w keys ls -la keys 합계 8 drwxrwxrwx. 2 admin admin 4096 May 22 16:17 . drwx------. 3 admin admin 4096 May 22 16:17 ..
호스트 인증을 위한 SSH 인증서 생성하기
호스트 인증서에 서명하는 명령은 다음 형식을 갖습니다:
ssh-keygen -s ca_host_key -I 호스트_이름 -h ssh_host_rsa_key.pub
호스트 인증서는 `ssh_host_rsa_key-cert.pub`로 명명됩니다.
To authenticate a host to a user, a public key must be generated on the host, passed to the CA server, signed by the CA, and then passed back to be stored on the host to present to a user attempting to log into the host.
-
호스트 키는 시스템에서 자동으로 발생됩니다. 이를 나열하려면 다음 명령을 입력하세요:
~]# 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
-
Copy the chosen public key to the server designated as the CA. For example, from the host:
~]# 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
상대적으로, 다음 CA에서:
~]$ scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub
-
CA 서버에서, 호스트의 공개키를 서명합니다. 예를 들면, `root`으로:
~]# 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 암호문 입력: 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
Where host_name is the host name of the system requiring the certificate.
-
인증서를 호스트에 복사합니다. 예를 들면, CA에서:
~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/ root@host_name.example.com's 비밀번호: ssh_host_rsa_key-cert.pub 100% 1384 1.5KB/s 00:00
-
Configure the host to present the certificate to a user’s system when a user initiates the login process. As
root
, edit the/etc/ssh/sshd_config
file as follows:HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
-
변경 사항을 적용하려면 `sshd`를 재시작하세요:
~]# service sshd restart
-
On user’s systems. remove keys belonging to hosts from the
~/.ssh/known_hosts
file if the user has previously logged into the host configured above. When a user logs into the host they should no longer be presented with the warning about the hosts authenticity.
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.
사용자 인증하기를 위해 SSH 인증서 생성하기
사용자 인증서를 서명하려면, 다음 형식에서 명령을 사용하세요:
ssh-keygen -s ca_user_key -I 사용자_이름 -n 사용자_이름 -V -start:+end id_rsa.pub
결과 인증서는 `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 공개/개인 rsa 키 쌍을 생성 중. 키를 저장하려는 파일을 입력(/home/user1/.ssh/id_rsa): 생성된 디렉토리 '/home/user1/.ssh'. 암호문을 입력하세요 (암호문이 없는 경우 공백): 다시 동일한 암호문을 입력하세요: 당신의 식별은 /home/user1/.ssh/id_rsa에 저장되었습니다. 당신의 공개 키는 /home/user1/.ssh/id_rsa.pub에 저장되었습니다. 키 지문은 다음과 같습니다: b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1@host1.example.com 키의 임의 기교 이미지는 다음과 같습니다: +--[ 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 합계 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 비밀번호: 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.
-
CA 서버에서, 사용자의 공개키를 서명합니다. 예를 들면, `root`으로:
~]# ssh-keygen -s ~/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub 암호문을 입력하세요: 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 비밀번호: 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.
SSH CA 인증서 보기
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: 유형: ssh-rsa-cert-v01@openssh.com user certificate 공개 키: RSA-CERT 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86 서명 중인 CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8 키 ID: "user1" 번호: 0 유효: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16 본인: user1 중요 옵션: (없음) 확장: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc
호스트 인증서를 보려면:
~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub /etc/ssh/ssh_host_rsa_key-cert.pub: 유형: ssh-rsa-cert-v01@openssh.com host certificate 공개 키: RSA-CERT 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23 서명된 CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a 키 ID: "host_name" 번호: 0 유효: 2015-05-26T17:19:01에서 2016-06-08T17:19:01까지 대상: host_name.example.com 중요 옵션: (없음) 확장: (없음)
SSH CA 인증서 취소
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
관련 꾸러미가 설치되어 있는지 확인합니다
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 27. |
ssh 유틸리티 사용하기
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:
경고: 알려진 호스트 목록에 'penguin.example.com' (ECDSA)가 영구적으로 추가됨. USER@penguin.example.com's 비밀번호:
SSH 서버의 호스트 키 최신화하기
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 찾음: 15 행 유형 ECDSA /home/USER/.ssh/known_hosts로 최신화되었습니다. 원래 내용은 /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 비밀번호: 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
원격 파일을 로컬 시스템으로 전송하려면, 다음 구문을 사용하세요:
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 비밀번호: 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).
명령 | 설명 |
---|---|
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. |
사용 가능한 명령의 전체 목록을 위해, sftp
(1) 설명서 부분을 참고하세요.
보안 쉘 보다 그 이상
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 포워딩
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.
포트 포워딩
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 |
추가 자원
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 홈페이지 - 더 많은 문서, 자주 질문한 문제, 전자우편 목록 연결, 결점보고 및 다른 유용한 자원이 포함된 OpenSSH 홈페이지.
-
OpenSSL 홈페이지 - 더 많은 문서, 자주 질문한 문제, 전자우편 목록 연결 및 다른 유용한 자원이 포함된 OpenSSL 홈페이지.
Want to help? Learn how to contribute to Fedora Docs ›