Working Securely Across a Network
Secure communication is a concern, particularly when sharing confidential and vital information between people. For example, English Prime Minister Winston Churchill and American President Franklin D. Roosevelt shared critical military information, such as troop movements, during World War II. To secure their voice conversations through the telephone, the SIGSALY (aka Green Hornet) was devised to encrypt and decrypt using cryptographic keys.
Today, we can’t imagine anyone not worrying about network security. Even people who are not so technically savvy should be concerned. For instance, what if your bank’s network is not secured, and a hacker steals your bank account number and PIN? Likewise, a DBA may want to connect to a Linux/Solaris server situated in a remote geographical location or another room in the building while working at the office or at home. What if a coworker is eavesdropping while that DBA is accessing sensitive data?
To address these network security concerns, version 1 of SSH was hatched in 1995, but it was replaced a year later by version 2 for security enhancements. SSH is a network protocol in which the encrypted data traverses through the network using a secure channel between computers, as illustrated in Figure 14-1. The ssh protocol replaces the older network protocols (telnet, rlogin, and rsh), and the scp command replaces the rcp command. The older protocols and commands were replaced because they lack the security feature; it just was not considered when they were initially designed.
Figure 14-1. SSH connection
This chapter focuses the discussion on how to log on securely to a remote Linux/Solaris server through SSH. It also discusses how to generate the server’s SSH host key, how to use the SSH public key for authentication in lieu of the username’s password, and how to securely copy files between Linux/Solaris servers.
Problem
You want to configure SSH so you can have a secured and encrypted connection to your remote Linux/Solaris server.
Solution
Before you configure SSH, ensure that you have the required packages: openssh, openssh-server, openssh-clients, and openssh-askpass. You can verify the SSH packages installed on your server by running the rpm command as follows:
# rpm -qa | grep -i openssh
openssh-5.3p1-94.el6.x86_64
openssh-clients-5.3p1-94.el6.x86_64
openssh-server-5.3p1-94.el6.x86_64
openssh-askpass-5.3p1-94.el6.x86_64
Note Run the ssh -V command to check the type and version of SSH installed on your server.
Before you can connect to your remote Linux/Solaris server, the SSH daemon server (sshd) must be running. You can run sshd as follows:
# service sshd start
Starting sshd: [ OK ]
You can also run sshd by calling the following script, which is the same script called by the previous command:
# /etc/rc.d/init.d/sshd start
Starting sshd: [ OK ]
However, if sshd is already started, you can restart it as shown here. Another way is to issue the command /etc/rc.d/init.d/sshd restart:
# service sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]
For Solaris, issue the following command to enable the ssh service, as shown here:
# svcadm enable network/ssh
To disable the ssh service, issue the following command:
# svcadm disable network/ssh
Afterward, run the following command to verify whether the ssh service is online or offline:
# svcs -v ssh
For sshd to start automatically when the Linux server is rebooted, you need to have sshd activated. You can activate sshd by using chkconfig, ntsysv, or system-config-services.
For the chkconfig command, use the --level option and provide the run level in which you want sshd to start. The following command indicates that sshd is configured to start in run levels 2, 3, 4, and 5:
# chkconfig --level 2345 sshd on
Note For a discussion of the Linux system V init run levels, refer to Chapter 11.
For the ntsysv command, also use the --level option and specify the run levels for sshd to start. If no run levels are specified, sshd will be activated only on the current run level. The following command runs ntsysv and affects only run levels 3 and 5:
# ntsysv --level 35
Note You can also launch ntsysv through the text mode setup utility by running the OS setup command and selecting System Services from the menu.
After you launch the ntsysv command, the screen of the text console service configuration tool will appear, as shown in Figure 14-2. Navigate by scrolling down using the arrow keys until the cursor is on sshd. The asterisk (*) inside the square brackets indicates that the status of the service is active; empty square brackets show that it is not active. (You can press the spacebar to toggle the status to become active or not active.) To save the changes, click the Tab key to highlight the Ok button and then press Enter.
Figure 14-2. Launching the ntsysv command
Another way to activate sshd is to run the system-config-services command; you can launch this tool as follows:
# /usr/sbin/system-config-services
After you launch system-config-services, the GUI-based service configuration tool will appear, as shown in Figure 14-3. Navigate by scrolling down to the sshd service and check the adjacent box to activate it. In this dialog box, you also have the option to start, stop, and restart the sshd service. You can also check the status and PID.
Figure 14-3. Launching system-config-services
How It Works
By default, the required SSH packages are included in major Linux/Solaris distributions. Otherwise, you can download them from any Linux/Solaris package download site such as http://www.openssh.com.
Once the SSH packages are installed on your remote Linux/Solaris server, you can activate and run the sshd daemon, and it should be ready to accept SSH connections. You can, however, make some changes, such as modifying the default port number on which sshd should be listening.
Note The default SSH port number that the Linux/Solaris server will listen on is 22. To change the default SSH port number, modify the value of the parameter Port in the /etc/ssh/sshd_config file.
The /etc/ssh/sshd_config file is the SSH systemwide configuration file at the Linux/Solaris server, which is the computer that you want to connect via SSH. The /etc/ssh/ssh_config file is the configuration file for the SSH client, which is the computer from which you are initiating SSH. If you make some changes to the /etc/ssh/sshd_config file, you have to reload sshd by running service sshd reload as follows:
[root@BLLNX2 stage]# service sshd reload
Reloading sshd: [ OK ]
You can also run the service sshd restart command; another method is to stop and start the sshd service, which will give the same results, as follows:
# service sshd stop
Stopping sshd: [ OK ]
# service sshd start
Starting sshd: [ OK ]
For Solaris, run the following:
# svcadm disable network/ssh
# svcadm enable network/ssh
To verify the run level that sshd is configured to start, run the chkconfig command with the --list option. As shown here, sshd is set to start on run levels 2, 3, 4, and 5:
# chkconfig --list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Once sshd is running, issue the following OS command to verify whether the corresponding sshd process is running. If there are no results, it means that sshd is not running yet. So you have to run the service sshd start command to manually start sshd:
# ps -ef | grep -v grep | grep ssh
root 4025 1 0 16:32 ? 00:00:00 /usr/sbin/sshd
Note To disallow the root user to log on via SSH, set the parameter PermitRootLogin to no in the /etc/ssh/sshd_config file. Once the non-root users have successfully logged on to the Linux/Solaris server via SSH, they can then run the su - root command or run the sudo command instead.
Problem
The SSH host key of your remote Linux/Solaris server is lost, is corrupted, or was not generated when the SSH packages were installed or during the first run. You want to generate a new SSH host key.
Solution
To generate a new SSH host key of the Linux/Solaris server, log on as root and run the ssh-keygen command with the -t option, which indicates the type of key to be generated. You must provide the -f option, followed by the file name of the key file. If you omit the -f option, it will create the public key for the OS account root instead of the SSH host key on the Linux/Solaris server.
The following example generates the SSH host key for the RSA type. If the files of the SSH host keys already exist, you are asked whether you want to overwrite them.
Next, you are asked to provide the passphrase:
root@BLSOL02:~# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
Generating public/private rsa key pair.
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (yes/no)? yes
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66 root@BLSOL02
To generate the SSH host key for the DSA type, run the following command:
root@BLSOL02:~# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
Generating public/private dsa key pair.
/etc/ssh/ssh_host_dsa_key already exists.
Overwrite (yes/no)? yes
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
ee:0d:88:61:1a:27:20:2e:69:27:7b:bc:70:de:a2:5c root@BLSOL02
Note For security reasons, we recommend that you supply a passphrase when creating the SSH host key. This prevents non-root users from peeking on the SSH host key by running ssh-keygen with the -y option (discussed in detail in the next section).
How It Works
The SSH host key is like a master key that encrypts and decrypts the data that traverses between the remote Linux/Solaris server and the client computer from which you want to initiate the SSH connection. This secures your connection to the remote Linux/Solaris server and eliminates vulnerability to man-in-the-middle attacks.
When creating a new SSH host key, you have to provide the type of key that corresponds to the version of SSH and the kind of encryption algorithm, which is either RSA or DSA. Both the RSA and DSA support some security method and different encryption algorithm. In terms of security, both the DSA and RSA are similar when comparing them with the same length keys. However, there is no clear winner for being fastest in encryption and decryption.
The valid values for the SSH host key are rsa1, rsa, and dsa. rsa1 refers to RSA of SSH version 1 (SSHv1); rsa and dsa are for SSH version 2 (SSHv2).
Note If your Linux/Solaris server supports only SSHv2, set the value of the parameter Protocol to 2 in /etc/ssh/sshd_config.
To create the RSA host key, run ssh-keygen with the -t rsa option, which creates two files: /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_rsa_key.pub. For the DSA host key, run -keygen with the -t dsa option, which creates /etc/ssh/ssh_host_dsa_key and /etc/ ssh/ssh_host_dsa_key.pub. Both ssh_host_rsa_key and ssh_host_dsa_key contain the private and public key, whereas ssh_host_rsa_key.pub and ssh_host_dsa_key.pub contain only the public key. The public key is used to encrypt the data; the private key is used to decrypt the data.
The first time you log on to the remote Linux/Solaris server, which is the computer you are connecting to via SSH, you are prompted to confirm the server’s SSH host key fingerprint, as shown here. If you accept it, the file $HOME/.ssh/known_hosts is created on the local Linux/Solaris server, which is the computer from which you initiated the SSH connection. $HOME/.ssh/known_hosts contains the server’s SSH host key.
oracle@BLSOL01:~$ ssh BLSOL02
The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established.
RSA key fingerprint is 03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’blsol02,192.168.2.42’ (RSA) to the list of known hosts.
Password:
Last login: Thu Aug 20 23:59:50 2015 from ol6-121-rac1
Oracle Corporation SunOS 5.11 11.2 June 2014
oracle@BLSOL02:~$
To determine the SSH key fingerprint on the remote Linux/Solaris server, run the ssh-keygen command with the -l option, as shown here. It verifies whether you have the correct SSH host key fingerprint of the remote Linux/Solaris server that you want to connect via SSH.
root@BLSOL02:~# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
1024 ee:0d:88:61:1a:27:20:2e:69:27:7b:bc:70:de:a2:5c /etc/ssh/ssh_host_dsa_key.pub
root@BLSOL02:~#
root@BLSOL02:~# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66 /etc/ssh/ssh_host_rsa_key.pub
Meanwhile, to determine the SSH host key on the remote Linux/Solaris server, run the ssh-keygen command with the -y option, as shown here. For security reasons, you can be asked to provide the passphrase that you supplied when creating the SSH host key.
root@BLSOL02:~# ssh-keygen -y -f /etc/ssh/ssh_host_dsa_key
ssh-dss AAAAB3NzaC1kc3MAAACBAJ2G5jV/4MHg9dG4DNb13Wrh94kbN5yUDQeW5SOP0JCzCQVpS2BnsV53L6CUQUPiNilXCqiLVMGaJmm+GSNL4Z82zAvNekTihXa1XabdAN7hBWccaxzH7ppmNbexiZVE/63aKIN+QnsjZ+cFbrqgDN9/10O8DKVM7AJQbyaPDbOrAAAAFQCmFbD9ei01XVMKkOzvqOpp4SwqXQAAAIBNRewVPbCM/p2GZ4PlepXnY2EtbeUZ8WFe15gEfrTwk9lDVh1M2RBs5NRqzHe3JNNddln116fhr++tFK2/xOtG9bNbWfIUEO++gULfYDqn1Ir17L7MZ3gK1KeELyJqtbkZKs2Ne/SA0oaZeJC0CMbi8Vs6ESkdMoSq34xbceDeugAAAIBc4ZWy840UAb7EURncb9KJg9wLFXfYpy7XubGGXhgfsw/z4Uect++kP8QpSYY3QynCzJ4ix3FpOyMKx4VShXKxQcYEMCNx5mnNOiLk/YmEfyeZI/pNR7WIixvQQIj0JObjQRzdz2T+K3Y83S8f522N76dNVBgJmCbW0SalhwqoIw==
root@BLSOL02:~#
root@BLSOL02:~# ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs/WovKxUpZw8T03HoH4dOlYGLzQ9bbfqayRd8Me33odUzKc8loUhOAdck7ySzaU3fd0Y+OYt1V/CN7wKo2qKowknf2K9JDsPyztSlSZi5FcT2WU6uDlb0FnEg+VAad83ETfDQQ+Ei2s5tV24n+QKAJd7qiAImITTfC55D/ftxpdKZL+m4Meupva6rTiagsLc7fiR4w6FYtuNI3oqaxElDuhJ3675XoTTF3FzhUj0spj4ZLZ6nkN3mYTVyAfrrjzeHDG6N59B6O46C2zW9hCW3e0ZQ3g1sQlDaE/hScErd4JoLR8F2VnWlrj0MQx+4328/p5C668LdPzULEuNEzXNPQ==
On your local client computer, run the tail command, as shown here. Check the SSH host key, which comprises the characters after ssh-rsa or ssh-dsa, and compare them against the results of the ssh-keygen -y option.
oracle@BLSOL01:~$ tail -1 $HOME/.ssh/known_hosts
blsol02,192.168.2.42 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs/WovKxUpZw8T03HoH4dOlYGLzQ9bbfqayRd8Me33odUzKc8loUhOAdck7ySzaU3fd0Y+OYt1V/CN7wKo2qKowknf2K9JDsPyztSlSZi5FcT2WU6uDlb0FnEg+VAad83ETfDQQ+Ei2s5tV24n+QKAJd7qiAImITTfC55D/ftxpdKZL+m4Meupva6rTiagsLc7fiR4w6FYtuNI3oqaxElDuhJ3675XoTTF3FzhUj0spj4ZLZ6nkN3mYTVyAfrrjzeHDG6N59B6O46C2zW9hCW3e0ZQ3g1sQlDaE/hScErd4JoLR8F2VnWlrj0MQx+4328/p5C668LdPzULEuNEzXNPQ==
However, when the remote Linux/Solaris server has a duplicate hostname or IP address, you will see the following error messages the next time you log on:
[root@ol6-121-rac1 ~]# ssh oracle@BLSOL01
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:6
DSA host key for blsol01 has changed and you have requested strict checking.
Host key verification failed.
To resolve this problem, you can rename $HOME/.ssh/known_hosts, but this is not advisable because you will lose the reference of the SSH host keys of the other servers. Another workaround is to edit $HOME/.ssh/known_hosts and remove the entry that corresponds to the hostname or IP address and type of SSH host key of the remote Linux/Solaris server that you want to connect via SSH. Before you edit $HOME/.ssh/known_hosts, we recommend that you make another copy of the file.
Problem
You want to log on to a remote Linux/Solaris server through a secured and encrypted connection.
Solution
On the local server, run the ssh command, followed by the hostname or IP address of the remote Linux/Solaris server that you want to connect. Afterward, supply the password of the corresponding OS user on the remote Linux/Solaris server.
In the first line of the following example, the OS prompt oracle@BLSOL01:~$ indicates that the OS username is oracle, which is logged on to the local Linux/Solaris server BLSOL01. The following ssh command connects to the remote Linux/Solaris server BLSOL02 and logs on to the same OS username oracle. You are then prompted to provide the password of the OS user on the remote Linux/Solaris server BLSOL02:
oracle@BLSOL01:~$ ssh BLSOL02
Password:
Last login: Wed Aug 19 18:13:50 2015 from blsol01
Oracle Corporation SunOS 5.11 11.2 June 2014
oracle@BLSOL02:~$
Once you have successfully logged on, you can verify whether you are already in the remote Linux/Solaris server. In the following example, the OS prompt shows that you are now logged on as oracle on server BLSOL02. However, you can run the OS commands echo $HOSTNAME and echo $USER, as shown here, to display the hostname of the Linux/Solaris server and OS username, respectively:
oracle@BLSOL02:~$ echo $HOSTNAME
BLSOL02
oracle@BLSOL02:~$ echo $USER
oracle
oracle@BLSOL02:~$
How It Works
Before you can run ssh on your local server, ensure that the open-ssh and openssh-clients packages are already installed. Otherwise, you can download them from any Linux/Solaris package download site, such as http://www.openssh.com.
To connect to the remote Linux/Solaris server from another UNIX/Linux computer or Mac OS, run the ssh command. If you are initiating the SSH connection from Windows, we recommend that you use the PuTTY software, as illustrated in recipe 1-1. Another option is to download and install OpenSSH for Windows.
The first time you log on to the remote Linux/Solaris server via SSH, you will be prompted to confirm the SSH host key fingerprint of the remote Linux/Solaris server, as shown here. Once you accept the SSH host key fingerprint, a row will be added in $HOME/.ssh/known_hosts of the local Linux/Solaris server, which contains the hostname, IP address, and SSH host key of the remote Linux/Solaris server.
oracle@BLSOL01:~$ ssh BLSOL02
The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established.
DSA key fingerprint is 8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’blsol02,192.168.2.42’ (DSA) to the list of known hosts.
Password:
Last login: Wed Aug 19 18:18:37 2015 from blsol01
Oracle Corporation SunOS 5.11 11.2 June 2014
oracle@BLSOL02:~$
Note You can run the ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key and ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key commands to verify the SSH host key fingerprint and SSH host key of the server.
To log on to a different OS user when connecting to the remote Linux/Solaris server, you need to add the -l option followed by the username, as shown here. Notice that the prompt is oracle@BLSOL01:~$ in the first line, so the current OS username is oracle and the hostname is BLSOL01. In the last line, the prompt is [bslopuz@BLSOL02 ~]$, which shows that you are now logged in as the username bslopuz of the remote server BLSOL02:
oracle@BLSOL01:~$ ssh -l bslopuz BLSOL02
Password:
Last login: Wed Aug 19 15:59:33 2015 from 192.168.2.101
Oracle Corporation SunOS 5.11 11.2 June 2014
bslopuz@BLSOL02:~$
Another way to connect using a different username than the one you are currently logged on with is to run the ssh bslopuz@BLSOL0 command, where the username and hostname are concatenated with the @ character, as follows:
oracle@BLSOL01:~$ ssh bslopuz@BLSOL02
Password:
Last login: Wed Aug 19 18:24:15 2015 from blsol01
Oracle Corporation SunOS 5.11 11.2 June 2014
bslopuz@BLSOL02:~$
By default, the SSH daemon server (sshd) is listening on port number 22. If the parameter Port in /etc/ssh/sshd_config on the remote Linux/Solaris server is pointing to a number other than 22, you have to add the -p option when running the ssh command, followed by the correct SSH port number, as shown here:
oracle@BLSOL01:~$ ssh -p 51 ol6-121-rac1
oracle@ol6-121-rac1’s password:
Last login: Wed Aug 19 18:30:37 2015 from blsol01
[oracle@ol6-121-rac1 ~]$
Note If you want to run an X Window application on the remote Linux/Solaris server, run the ssh command with the -X option. For additional information about running an X Window application via SSH, refer to recipe 15-5.
If you can’t connect to your remote Linux/Solaris server via SSH, run the ping command, as shown here. It verifies whether you have a direct connection to the Linux/Solaris server. The -c3 option of the ping command means it will send requests to the remote Linux server only three times.
[oracle@ol6-121-rac1 ~]$ ping -c3 BLSOL01
PING BLSOL01 (192.168.2.41) 56(84) bytes of data.
64 bytes from BLSOL01 (192.168.2.41): icmp_seq=1 ttl=255 time=0.452 ms
64 bytes from BLSOL01 (192.168.2.41): icmp_seq=2 ttl=255 time=0.245 ms
64 bytes from BLSOL01 (192.168.2.41): icmp_seq=3 ttl=255 time=0.209 ms
--- BLSOL01 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.209/0.302/0.452/0.107 ms
For a Solaris server, we recommend the –s option of the ping command, which will continually send packets to the remote server, as shown here:
oracle@BLSOL01:~$ ping -s BLSOL02
PING BLSOL02: 56 data bytes
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=0. time=0.520 ms
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=1. time=0.379 ms
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=2. time=0.290 ms
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=3. time=0.228 ms
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=4. time=0.251 ms
64 bytes from BLSOL02 (192.168.2.42): icmp_seq=5. time=0.195 ms
^C
----BLSOL02 PING Statistics----
6 packets transmitted, 6 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 0.195/0.310/0.520/0.121
However, if you are passing through a proxy server before you can connect to the remote Linux/Solaris server, we recommend that you use the PuTTY software because it is easy to configure the proxy server settings (refer to recipe 1-1). If the remote Linux/Solaris server is behind a firewall, check with your SA to see whether the corresponding SSH port number is open.
To monitor the OS users connecting to the remote Linux server via SSH, check the /var/log/secure file, as shown here. This log file provides important information, such as the date and time that a particular OS user is logged on, the hostname or IP address from where the SSH connection is initiated, and the relevant messages showing why you are perhaps unable to log on.
[root@ol6-121-rac1 ~]# tail -f /var/log/secure
Aug 19 19:17:01 ol6-121-rac1 su: pam_unix(su-l:session): session opened for user oracle by (uid=0)
Aug 19 19:17:02 ol6-121-rac1 su: pam_unix(su-l:session): session closed for user oracle
Aug 19 19:17:04 ol6-121-rac1 sshd[5330]: Accepted password for oracle from 192.168.2.42 port 38569 ssh2
Aug 19 19:17:04 ol6-121-rac1 sshd[5330]: pam_unix(sshd:session): session opened for user oracle by (uid=0)
Aug 19 19:17:20 ol6-121-rac1 sshd[5330]: pam_unix(sshd:session): session closed for user oracle
Note To troubleshoot SSH connections, run the ssh command with the -v option to display debugging messages. For more debugging messages, run with the -vvv option instead. We also recommend that you review the /var/log/secure and /var/log/messages files.
Problem
You want to copy the files between Linux/Solaris servers through a secured and encrypted connection.
Solution
Run the scp command to copy files between Linux/Solaris servers through SSH. To run the scp command, provide the source files and target files. These files can be in the local and/or remote Linux/Solaris servers. In the following example, the /home/oracle/temp/ccf_output01.log file is copied from server BLSOL01 to the same directory on server BLSOL02. You will be prompted for a password of the username on the remote Linux/Solaris server:
oracle@BLSOL01:~$ scp /export/home/oracle/temp/ccf_output01.log BLSOL02:/export/home/oracle/temp
Password:
ccf_output01.log 100% |*****************************| 14956 00:00
Note The sftp command is another protocol to securely transfer files between Linux/Solaris servers. However, we excluded examples of the sftp command because the sftp protocol is not yet an Internet standard.
How It Works
Similar to using the ssh command, you will be prompted to confirm the SSH host key fingerprint of the remote Linux/Solaris server the first time you run the scp command to securely copy files to the remote Linux/Solaris server via SSH, as shown here. Once you accept the SSH host key fingerprint, a row will be added in $HOME/.ssh/known_hosts of the local Linux/Solaris server, which contains the hostname, IP address, key type, and SSH host key of the remote Linux/Solaris server.
oracle@BLSOL01:~$ scp /export/home/oracle/temp/ccf_output01.log BLSOL02:/export/home/oracle/temp
The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established.
DSA key fingerprint is 8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’blsol02,192.168.2.42’ (DSA) to the list of known hosts.
Password:
ccf_output01.log 100% |*****************************| 14956 00:00
Note The scp command replaces the rcp command because the latter is not a secure way of copying files between Linux/Solaris servers, particularly when the data is traversing the Internet. We recommend that you use the scp command to safeguard your critical data.
The following is the syntax of the scp command. The hostnames can be different Linux/Solaris servers. If no hostnames are defined, the files will be copied to the same local Linux/Solaris server. The usernames may be different between the local and remote Linux/Solaris servers.
scp [<option>] [source_user@]source_host:]source_file
[[target_user@]target_host:]target_file
Table 14-1 shows the common options of the scp command. You can run man scp to determine other options.
Table 14-1. Common Options of scp Command
Option | Meaning |
|---|---|
P | Preserves the permission and date timestamp of the source file. |
P | Gets the SSH port number of the remote Linux/Solaris server. |
Q | Hides the progress meter. |
R | Copies recursively all subdirectories and their files. |
v | Displays debugging messages. |
To copy recursively all the files and directories, use the -r option. The following command will copy all the files and subdirectories of $HOME/temp1 of the local server BLSOL01 to a remote Linux/Solaris server BLSOL02 under the directory $HOME:
oracle@BLSOL01:~$ scp -r $HOME/temp1 BLSOL02:$HOME
Password:
ol6-121-rac1.localdo 100% |*****************************| 54 00:00
test03.txt 100% |*****************************| 0 00:00
ccf_output01.log 100% |*****************************| 14956 00:00
test02.txt 100% |*****************************| 0 00:00
test01.txt 100% |*****************************| 29 00:00
Similar to using the cp command, you can use a wildcard such as the asterisk (*) to copy selected files. The following command will copy all the files with an extension of txt in the directory $HOME/temp1 on the remote Linux/Solaris server BLSOL02 to the directory $HOME/temp2 on the local Linux/Solaris server BLSOL01:
oracle@BLSOL01:~$ scp BLSOL02:$HOME/temp1/*.txt $HOME/temp2
Password:
ol6-121-rac1.localdo 100% |*****************************| 54 00:00
test01.txt 100% |*****************************| 29 00:00
test02.txt 100% |*****************************| 0 00:00
test03.txt 100% |*****************************| 0 00:00
Note PuTTY also provides a pscp.exe client to securely copy files from the Microsoft Windows environment to a UNIX/Linux environment. You can download pscp.exe from PuTTY’s download page.
14-5. Authenticating Through Public Keys
Problem
You want to log on to a remote Linux/Solaris server when connecting via SSH. You want to authenticate using a public key instead of typing the OS password.
Solution
In the following example, the OS username oracle is currently logged on to the local Linux/Solaris server BLSOL01 and will log on to the remote Linux/Solaris server BLSOL02. Perform the following steps to use a public key for authentication in lieu of a password prompt:
- On the local Linux/Solaris server BLSOL01, run the ssh-keygen command with the -t rsa option to generate the RSA public key or with -t dsa for the DSA public key. If the files of the RSA and DSA keys already exist, you will be asked whether you want to overwrite them. If no, you can skip this step, but ensure that you remember their passphrases because you will need them later. If yes, you are prompted to provide the passphrase, which is used to access the newly created private key. Afterward, the names of the private and public key files and key fingerprints are displayed.
oracle@BLSOL01:~$ /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/export/home/oracle/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /export/home/oracle/.ssh/id_rsa.
Your public key has been saved in /export/home/oracle/.ssh/id_rsa.pub.
The key fingerprint is:
8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 oracle@BLSOL01 - On the local Linux/Solaris server BLSOL01, provide the read, write, and execute permission only to the owner for security reasons so the private and public keys are not accessible to others:
oracle@BLSOL01:~$ chmod 700 $HOME/.ssh
oracle@BLSOL01:~$ chmod 600 $HOME/.ssh/* - Copy the public key from the local Linux/Solaris server BLSOL01 to the remote Linux/Solaris server BLSOL02. You may need to supply the password of the OS user on the remote Linux/Solaris server BLSOL02. This public key must be from the OS username on the local Linux/Solaris server BLSOL01, which is the computer from which you want to initiate the logon to the remote Linux/Solaris server and connect via SSH.
oracle@BLSOL01:~$ scp $HOME/.ssh/id_rsa.pub BLSOL02:$HOME
Password:
id_rsa.pub 100% |*****************************| 396 00:00 Note We recommend that you make local copies of the key files, such as id_rsa and id_rsa.pub. In case someone mistakenly executes ssh-keygen -t rsa, at least you can always restore the original copies. - Create the directory $HOME/.ssh if not yet available on the remote Linux/Solaris server BLSOL02:
oracle@BLSOL02:~$ mkdir $HOME/.ssh - On the remote Linux/Solaris server BLSOL02, append the public key from the local Linux/Solaris server BLSOL01 to $HOME/.ssh/authorized_keys. Afterward, delete the key file $HOME/id_rsa.pub on the remote Linux/Solaris server BLSOL02, which you copied from the local Linux/Solaris server BLSOL01.
oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys
/export/home/oracle/.ssh/authorized_keys: No such file or directory
oracle@BLSOL02:~$ cat $HOME/id_rsa.pub >> $HOME/.ssh/authorized_keys
oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys
-rw-r--r-- 1 oracle staff 396 Aug 19 20:34 /export/home/oracle/.ssh/authorized_keys
oracle@BLSOL02:~$ rm $HOME/id_rsa.pub - On the remote Linux/Solaris server BLSOL02, provide the read, write, and execute permission only to the owner for security reasons. Other users can’t access and modify $HOME/.ssh/authorized_keys.
oracle@BLSOL02:~$ chmod 700 $HOME/.ssh
oracle@BLSOL02:~$ chmod 600 $HOME/.ssh/authorized_keys
oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys
-rw------- 1 oracle staff 396 Aug 19 20:34 /export/home/oracle/.ssh/authorized_keys - After the public key is successfully appended to $HOME/.ssh/authorized_keys on the remote Linux/Solaris server BLSOL02, you can now log on without supplying the password of the OS user when connecting via SSH to the remote Linux/Solaris server BLSOL02, as shown here. Instead, you will be prompted for the passphrase, which is actually the passphrase you supplied when creating the public key on the local Linux/Solaris server BLSOL01.
oracle@BLSOL01:~$ ssh BLSOL02
Enter passphrase for key ’/export/home/oracle/.ssh/id_rsa’:
Last login: Wed Aug 19 20:31:17 2015 from blsol01
Oracle Corporation SunOS 5.11 11.2 June 2014
Note If you immediately press Enter or Return when asked to provide the passphrase, or if you provide the passphrase incorrectly three times, you will be prompted instead for the actual password of the OS username that you want to use to log on to the remote Linux/Solaris server.
How It Works
To authenticate using the public key, run the ssh-keygen command to generate the public key at the local Linux/Solaris server, which is the computer from which you are going to initiate the SSH connection. Then copy the newly generated public key and append it to the $HOME/.ssh/authorized_keys on the remote Linux/Solaris server, which is the computer from which you are going to connect via SSH.
The ssh-keygen will create the RSA and DSA key files, which are used to encrypt and decrypt the data. For RSA, use the -t rsa option command, which will create two files: $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub. For DSA, use the -t dsa option, which will create $HOME/.ssh/id_dsa and $HOME/.ssh/id_dsa.pub.
$HOME/.ssh/id_rsa and $HOME/.ssh/id_dsa contain both the private key and the public key, whereas $HOME/.ssh/id_rsa.pub and $HOME/.ssh/id_dsa.pub contain just the public key. The public key is used to encrypt the data; the private key is used to decrypt the data. For security reasons, ensure that both the private key and the public key files are writable and readable only by the owner.
When creating the public key, you are prompted to provide the passphrase, which can be a string of arbitrary length. The passphrase is your password to decrypt the data. Even if the private and public keys are stolen, they are useless without the passphrase because the data can’t be decrypted. So it is important that you keep the passphrase to yourself; don’t share it with others.
To change the passphrase, run the ssh-keygen command with the -p option, as shown here. However, you have to supply the old passphrase before you can change it to prevent unauthorized users from changing your passphrase:
oracle@BLSOL01:~$ ssh-keygen -p
Enter file in which the key is (/export/home/oracle/.ssh/id_rsa):
Enter old passphrase:
Key has comment ’/export/home/oracle/.ssh/id_rsa’
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
Using the public key as a way to authenticate when connecting to the remote Linux/Solaris server via SSH can be a security risk. For example, if other OS users can modify your $HOME/.ssh/ authorized_keys, they can append their own public key to the said file. As a result, they can log on to your account on the remote Linux/Solaris server without needing your password.
As a security measure, we recommend that you provide a passphrase when creating the public key and not share the passphrase with anyone. Also, run the chmod 700 $HOME command, which ensures that the directories and files underneath the $HOME directory are writable, readable, and executable only by the owner. Doing so prevents other OS users to peek at and alter any files starting from your $HOME directory.
After you have successfully logged in, run the following OS commands to verify the OS username and hostname of the remote Linux/Solaris server BLSOL02, as shown here. Even though that information is sometimes obvious in the OS prompt, it’s a good exercise to verify it.
oracle@BLSOL02:~$ echo $HOSTNAME
BLSOL02
oracle@BLSOL02:~$ echo $USER
oracle
14-6. Configuring a Promptless Logon
Problem
You want to log on without providing the remote OS user’s password and public key’s passphrase when connecting through SSH to a remote Linux/Solaris server.
Solution
In the following example, the OS username oracle is currently logged on to the local Linux/Solaris server BLSOL01 and will log on to the remote Linux/Solaris server BLSOL02. Perform the following steps to set up a promptless logon when connecting to the remote Linux/Solaris server via SSH:
- Create the public key on the local Linux/Solaris server BLSOL01 and the OS username where you will initiate the SSH connection. For additional details, refer to recipe 14-5 because you need to perform the same steps as in that recipe.
- Run the SSH agent and capture the output to $HOME/ssh-agent.sh:
oracle@BLSOL01:~$ /usr/bin/ssh-agent > $HOME/ssh-agent.sh - Run $HOME/ssh-agent.sh to set the environment variables SSH_AUTH_SOCK and SSH_AGENT_PID:
oracle@BLSOL01:~$ source $HOME/ssh-agent.sh
Agent pid 4566 - Run the ssh-add command and provide the passphrase you supplied when the public key was created on the local Linux/Solaris server:
oracle@BLSOL01:~$ /usr/bin/ssh-add
Enter passphrase for /export/home/oracle/.ssh/id_rsa:
Identity added: /export/home/oracle/.ssh/id_rsa (/export/home/oracle/.ssh/id_rsa) - As shown here, the OS username oracle on the local Linux/Solaris server BLSOL01 can now log on to the remote Linux/Solaris server BLSOL02 without providing the OS user password and the public key passphrase:
oracle@BLSOL01:~$ ssh BLSOL02
Last login: Wed Aug 19 20:41:48 2015 from blsol01
Oracle Corporation SunOS 5.11 11.2 June 2014
oracle@BLSOL02:~$
How It Works
In recipe 14-5, you used a public key for authentication in lieu of the OS username’s password on the remote Linux/Solaris server. However, you are asked to provide the passphrase, which is generated when the public key was created on the local Linux/Solaris server. So you are still prompted to enter something.
For a complete promptless logon to the remote Linux/Solaris server when connecting via SSH, run the ssh-agent and ssh-add commands. The ssh-agent command will create a socket and cache the passphrase of the private key. It will also create a new directory under /tmp, as defined in the environment variable SSH_AUTH_SOCK. The ssh-add command will add the RSA and DSA identities and present them to the SSH agent. You can then log on to the remote Linux/Solaris server without any prompt for a password or passphrase.
To verify the key fingerprints, run the ssh-add command with the -l option to check what’s presented to the SSH agent. Next, run the ssh-keygen command with the -l option, followed by the path name of the private key file. As shown here, notice that both outputs have a similar key fingerprint, which is 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60:
oracle@BLSOL01:~$ /usr/bin/ssh-add -l
2048 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 /export/home/oracle/.ssh/id_rsa (RSA)
oracle@BLSOL01:~$ /usr/bin/ssh-keygen -l -f $HOME/.ssh/id_rsa
2048 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 /export/home/oracle/.ssh/id_rsa.pub
To delete the identities presented to the SSH agent, run ssh-add with the -d option. To delete everything, use the -D option instead:
oracle@BLSOL01:~$ /usr/bin/ssh-add -d
Identity removed: /export/home/oracle/.ssh/id_rsa (/export/home/oracle/.ssh/id_rsa.pub)
For a promptless logon, the critical key is to ensure that the environment variable SSH_ AUTH_SOCK is pointing to the correct path name before connecting through SSH. Otherwise, you will be prompted again for the passphrase once you exit from your shell or log out of the system.
A workaround is to run the ssh-agent command and capture the output to $HOME/ssh-agent.sh. Before you connect to the remote Linux/Solaris server via SSH, you must run $HOME/ssh-agent.sh to set the same value to the SSH_AUTH_SOCK environment variable. This setting should be the same as when the ssh-agent command was first executed.
To schedule the ssh or scp command in the cron job, ensure that the environment variable SSH_AUTH_SOCK is set correctly each time you log on to the OS username on the local Linux/Solaris server. To do this, we recommend that you add the following lines in $HOME/.bashrc. Notice that you send the output to /dev/null when you run $HOME/ssh-agent.sh to avoid displaying the SSH agent PID every time you log on to that OS username:
if [ -f $HOME/ssh-agent.sh ]; then
source $HOME/ssh-agent.sh > /dev/null
fi
If you think you have configured everything correctly, but are still prompted for the passphrase, you have to troubleshoot. Begin by verifying that the OS process of the SSH agent is still active and the environment variables are set correctly. Issue the ps -ef | grep ssh-agent command to determine the PID of the SSH agent:
oracle@BLSOL01:~$ ps -ef | grep ssh-agent
bslopuz 1639 1601 0 Aug 17 ? 0:01 /usr/bin/ssh-agent -- gnome-session
oracle 4566 1 0 20:44:03 ? 0:00 /usr/bin/ssh-agent
Run the env | grep SSH command to display the environment variables, as shown here. The value of the SSH_AGENT_PID and the PID of the SSH agent should be the same. In the example, the PID is 4566:
oracle@BLSOL01:~$ env | grep SSH
SSH_AGENT_PID=4566
SSH_AUTH_SOCK=/tmp/ssh-XXXXoGaO6i/agent.4565
Also, the value of the environment variable SSH_AUTH_SOCK should be pointing to an existing path name. To verify, run the ls command as follows:
oracle@BLSOL01:~$ ls -l /tmp/ssh-XXXXoGaO6i/agent.4565
srw------- 1 oracle staff 0 Aug 19 20:44 /tmp/ssh-XXXXoGaO6i/agent.4565
After you have successfully logged on, run the following OS commands to verify the OS username and hostname of the remote Linux/Solaris server BLLNX2, as shown here. Even if that information is sometimes obvious in the OS prompt, it is a good exercise to verify them.
oracle@BLSOL02:~$ echo $HOSTNAME
BLSOL02
oracle@BLSOL02:~$ echo $USER
oracle