Document Information
Preface
Part I Security Overview
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Using the Basic Audit Reporting Tool (Tasks)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
11. Privileges (Tasks)
12. Privileges (Reference)
Part IV Solaris Cryptographic Services
13. Solaris Cryptographic Framework (Overview)
14. Solaris Cryptographic Framework (Tasks)
15. Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
17. Using PAM
18. Using SASL
19. Using Solaris Secure Shell (Tasks)
Solaris Secure Shell (Overview)
Solaris Secure Shell Enhancements in the Solaris 10 Release
Solaris Secure Shell (Task Map)
Configuring Solaris Secure Shell (Task Map)
Using Solaris Secure Shell (Task Map)
Using Solaris Secure Shell
20. Solaris Secure Shell (Reference)
Part VI Kerberos Service
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Solaris Auditing
28. Solaris Auditing (Overview)
29. Planning for Solaris Auditing
30. Managing Solaris Auditing (Tasks)
31. Solaris Auditing (Reference)
Glossary
Index
|
Configuring Solaris Secure Shell
By default, host-based authentication and the use of both protocols are not enabled
in Solaris Secure Shell. Changing these defaults requires administrative intervention. Also, for port
forwarding to work requires administrative intervention.
How to Set Up Host-Based Authentication for Solaris Secure ShellThe following procedure sets up a public key system where the client's public
key is used for authentication on the server. The user must also
create a public/private key pair. In the procedure, the terms client and local host refer to the machine
where a user types the ssh command. The terms server and remote host refer to
the machine that the client is trying to reach.
- Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role
and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- On the client, enable host-based authentication.
In the client configuration file, /etc/ssh/ssh_config, type the following entry: HostbasedAuthentication yes
- On the server, enable host-based authentication.
In the server configuration file, /etc/ssh/sshd_config, type the same entry: HostbasedAuthentication yes
- On the server, configure a file that enables the client to be recognized
as a trusted host.
For more information, see the FILES section of the sshd(1M) man page.
- Add the client as an entry to the server's /etc/ssh/shosts.equiv file.
client-host
- Or, you can instruct users to add an entry for the client
to their ~/.shosts file on the server.
client-host
- On the server, ensure that the sshd daemon can access the list of
trusted hosts.
Set IgnoreRhosts to no in the /etc/ssh/sshd_config file. # sshd_config
IgnoreRhosts no
- Ensure that users of Solaris Secure Shell at your site have accounts
on both hosts.
- Do one of the following to put the client's public key on
the server.
- Modify the sshd_config file on the server, then instruct your users to add
the client's public host keys to their ~/.ssh/known_hosts file.
# sshd_config
IgnoreUserKnownHosts no For user instructions, see How to Generate a Public/Private Key Pair for Use With Solaris Secure Shell.
- Copy the client's public key to the server.
The host keys are stored in the /etc/ssh directory. The keys are typically generated
by the sshd daemon on first boot.
- Add the key to the /etc/ssh/ssh_known_hosts file on the server.
On the client, type the command on one line with no backslash. # cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \
'cat >> /etc/ssh/ssh_known_hosts && echo "Host key copied"'
- When you are prompted, supply your login password.
When the file is copied, the message “Host key copied” is displayed. Each line in the /etc/ssh/ssh_known_hosts file consists of fields that are separated by
spaces: hostnames algorithm-name publickey comment
- Edit the /etc/ssh/ssh_known_hosts file and add RemoteHost as the first field in the
copied entry.
## /etc/ssh/ssh_known_hosts File
RemoteHost <copied entry> Example 19-1 Setting Up Host-based AuthenticationIn the following example, each host is configured as a server and
as a client. A user on either host can initiate an ssh connection to
the other host. The following configuration makes each host a server and a
client:
On each host, the Solaris Secure Shell configuration files contain the following entries: # /etc/ssh/ssh_config
HostBasedAuthentication yes
#
# /etc/ssh/sshd_config
HostBasedAuthentication yes
IgnoreRhosts no
On each host, the shosts.equiv file contains an entry for the other host: # /etc/ssh/shosts.equiv on machine2
machine1 # /etc/ssh/shosts.equiv on machine1
machine2
The public key for each host is in the /etc/ssh/ssh_known_hosts file on the other host: # /etc/ssh/ssh_known_hosts on machine2
… machine1 # /etc/ssh/ssh_known_hosts on machine1
… machine2
Users have an account on both hosts: # /etc/passwd on machine1
jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh # /etc/passwd on machine2
jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh
How to Enable Solaris Secure Shell v1This procedure is useful when a host interoperates with hosts that run v1
and v2.
- Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role
and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Configure the host to use both Solaris Secure Shell protocols.
Edit the /etc/ssh/sshd_config file. # Protocol 2
Protocol 2,1
- Provide a separate file for the host key for v1.
Add a HostKey entry to the /etc/ssh/sshd_config file. HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa1_key
- Generate a host key for v1.
# ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa1_key -N '' - -t rsa1
Indicates the RSA algorithm for v1.
- -f
Indicates the file that holds the host key.
- -N ''
Indicates that no passphrase is required.
- Restart the sshd daemon.
# svcadm restart network/ssh:default You can also reboot the system.
How to Configure Port Forwarding in Solaris Secure ShellPort forwarding enables a local port be forwarded to a remote host. Effectively,
a socket is allocated to listen to the port on the local
side. Similarly, a port can be specified on the remote side.
Note - Solaris Secure Shell port forwarding must use TCP connections. Solaris Secure Shell does
not support UDP connections for port forwarding.
- Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role
and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Configure a Solaris Secure Shell setting on the remote server to allow
port forwarding.
Change the value of AllowTcpForwarding to yes in the /etc/ssh/sshd_config file. # Port forwarding
AllowTcpForwarding yes
- Restart the Solaris Secure Shell service.
remoteHost# svcadm restart network/ssh:default For information on managing persistent services, see Chapter 15, Managing Services (Overview), in System Administration Guide: Basic Administration and the svcadm(1M) man page.
- Verify that port forwarding can be used.
remoteHost# /usr/bin/pgrep -lf sshd
1296 ssh -L 2001:remoteHost:23 remoteHost
|