<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>SSH Configuration</title>
<link rel="stylesheet" type="text/css" href="../../../CSS/main.css">
</head>

<body>

<basefont face="Times" size="3">
<table border="0" width="100%" id="table1" cellspacing="1" cellpadding="4"  >
<tr>
<td rowspan="2" width="40%">

<p align="center"><img border="0" src="/Images/splogo.gif" width="45"  ><font face="Bernard MT Condensed" color="#FF0000" size="7">
<font color="#FF0000"><a href="/index.shtml">Softpanorama</a></font></font></p>

<center>

<font size="2" face="Arial"><b>May the source be with you, but remember the <a href="/SE/kiss.shtml">KISS principle</a> ;-) </b></font></center>
</td>
<td align="center">

<b><a href="/index.shtml"><font size="2">Home</font></a></b></td>
<td align="center">

<b><a href="/switchboard.shtml"><font size="2">Switchboard</font></a></b></td>
<td align="center">

<b><a href="/Admin/index.shtml"><font size="2">Unix Administration</font></a></b></td>
<td align="center">

<b><a href="/Commercial_linuxes/RHEL/index.shtml"><font size="2">Red Hat</font></a></b></td>
<td align="center">

<b><a href="/Net/index.shtml"><font size="2">TCP/IP Networks</font></a></b></td>
<td align="center">

<b><a href="/Skeptics/Political_skeptic/Neoliberalism/index.shtml"><font size="2">Neoliberalism</font></a></b></td>
<td align="center">

<b><a href="/Social/Toxic_managers/index.shtml"><font size="2">Toxic Managers</font></a></b></td>
</tr>
<tr>
<td colspan="7" align="center">

<b><font size="2">(slightly skeptical) Educational society promoting &quot;<a href="/Back_to_basics/index.shtml">Back to basics</a>&quot; movement against IT overcomplexity 
and&nbsp; <a href="Commercial_linuxes/RHEL/index.shtml">bastardization of classic Unix</a></font></b></td>
</tr>
</table>
<hr width="100%" noshade size="5" color="#FF0000">
<center>
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Top_banner2021 -->
<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="3389635737"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
     (adsbygoogle = window.adsbygoogle || []).push({});
</script></center>


<h1>SSH Configuration </h1>

<table border="1" cellpadding="0" cellspacing="0" bordercolor="#111111" width="100%" bgcolor="#FFFFCC" id="table1">
	<tr>
		<td width="14%" align="center"><a href="#News">News</a></td>
		<td width="14%" align="center"><b><a href="../ssh.shtml">SSH </a></b></td>
		<td width="14%" align="center"><a href="#Recommended_Links">Recommended 
		Links</a></td>
		<td width="14%" align="center"><b><a href="troubleshooting.shtml">SSH troubleshooting</a></b></td>
		<td width="14%" align="center">
		<b>
		<a href="private_and_public_key_management.shtml">Private and Public key 
		management</a></b></td>
		<td width="15%" align="center"><b><a href="ssh_forwarding_minitutorial.shtml">Mini-tutorial</a></b></td>
		<td width="15%" align="center"><b><a href="passwordless_ssh_login.shtml">Passwordless SSH login</a></b></td>
	</tr>
	<tr>
		<td width="14%" align="center"><a href="ssh-keygen.shtml">ssh-keygen man 
		page</a></td>
		<td width="14%" align="center"><b><a href="ssh_forwarding_minitutorial.shtml">SSH Forwarding Minitutorial</a></b></td>
		<td width="14%" align="center"><b><a href="x_over_ssh.shtml">X11 forwaring over ssh</a></b></td>
		<td width="14%" align="center"><b><a href="reverse_ssh_tunnels.shtml">Reverse SSH Tunnels</a></b></td>
		<td width="14%" align="center"><b><a href="ssh_client.shtml">SSH client</a></b></td>
		<td width="15%" align="center"><b><a href="scp_tips.shtml">SCP Tips</a></b></td>
		<td width="15%" align="center"><b><a href="tcp_wrapper_and_ssh_security_issues.shtml">ssh &amp; TCP Wrappers</a></b></td>
	</tr>
	<tr>
		<td width="14%" align="center">&nbsp;</td>
		<td width="14%" align="center"><b><a href="../../../Admin/tips.shtml">Unix Sysadmin Tips</a></b></td>
		<td width="14%" align="center"><b><a href="../../../Admin/admin_horror_stories.shtml">Sysadmin 
      Horror Stories</a></b></td>
		<td width="14%" align="center"><b><a href="ssh_history.shtml">SSH History</a></b></td>
		<td width="14%" align="center"><b><a href="tips.shtml">Tips</a></b></td>
		<td width="15%" align="center"><b>
      <a target="_blank" href="../../../Bulletin/Humor/linux_sucks.shtml">Humor</a></b></td>
		<td width="15%" align="center"><a href="#Etc">Etc</a></td>
	</tr>
</table>

<table border="0" width="178" height="620" align="right" cellspacing="4" bgcolor="#FFFFFF">
   <tr>
      <td>

      <table border="1" width="174" height="616" align="center" bgcolor="#FF0000">
         <tr>
            <td>
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Upper skyscaper -->
<ins class="adsbygoogle"
     style="display:inline-block;width:160px;height:600px"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="0371843916"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
            </td>
         </tr>
      </table></td>
   </tr>
</table>

<p>In order of precedence, Secure Shell configuration occurs at the following places: 
the software build-time, the server command-line options, the server configuration 
file (<tt>sshd_config</tt>), the client command-line options, the user client configuration 
file (<tt>~/.ssh/config</tt>), and the global client configuration file (<tt>ssh_config</tt>). 
Build-time configuration is the strongest. It cannot be changed without rebuilding 
the software. This makes it inconvenient if a change is needed.</p>
<!---google box ------->
<table border="0" width="310" align="left" cellspacing="7" cellpadding="4">
<tr><td width="340" bgcolor="#FFFF00" valign="center" align="center">
<center>
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Top Large Rectangle -->
<ins class="adsbygoogle"
     style="display:inline-block;width:336px;height:280px"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="3274064497"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
</center>
</td></tr>
</table>
<!---end of google box ------->

<p>The server configuration involves the following: how the <tt>sshd</tt>(1M) daemon 
will present itself on the network, what protocols and authentication methods are 
acceptable, and how the user environment is constructed. The client configuration 
involves the following: determining which server to transact with which protocol, 
verifying the server identity, determining the user identity presentation, and choosing 
the ease-of-use features. Policy details are implemented on the server side. The 
client cannot override or provide a feature that the server does not offer.</p>

<p>The available features can be enabled or disabled by either command-line options 
or the applicable configuration file. Command-line options apply to a particular 
instantiation of either the server or client. Configuration file options are persistent 
until the file is altered and a new instantiation started. The most reliable configuration 
method uses the configuration file. This gives a repeatable, reproducible invocation. 
Changes can also be tracked by using source control. For information on command-line 
options, consult the vendor documentation.</p>

<p>When OpenSSH is built, <tt>sshd_config</tt> and <tt>ssh_config</tt> are placed 
at the location specified by <tt>sysconfdir</tt>. Usual locations are <tt>/etc</tt>,<tt>/usr/local/etc</tt>,<tt>/etc/ssh</tt> 
or <tt>/etc/openssh</tt>. The Solaris Secure Shell software stores the two files 
at /etc/<tt>ssh</tt>. These files should be owned by user <tt>root</tt> and group
<tt>sys</tt>. The file permission mode should be either 644 or 444.</p>

<p>Configuration files contain two types of entries: comments and keyword-value 
pairs. Comments are blank lines and lines beginning with the hash mark (<tt>#</tt>). 
Keyword-value pairs consist of an identifier (keyword), a space, and the value associated 
with the identifier. Keywords are case insensitive, where as values are case sensitive.</p>

<p>Traditionally, the first letter of each word in a keyword is capitalized for 
readability. Some values are lists that are either comma delimited or space delimited, 
depending on the keyword. Consider keeping configuration files under source control 
to track revisions. The source control tags can be hidden by the comment character 
(the hash mark).</p>

<p>server configuration options supported by the Solaris Secure Shell software and 
OpenSSH. The list is formatted in the following manner:</p>

<p>Name of the option and the value or values it takes</p>

<ul>

	<li>

	<p>Description</p>
	</li>

	<li>

	<p>Default in the Solaris Secure Shell software and OpenSSH</p>
	</li>

	<li>

	<p>Recommendation, as applicable</p>
	</li>

	<li>

	<p>References, as applicable</p>
	</li>

	<li>

	<p>Example, given in a code box</p>
	</li>
</ul>

<p><b>Note: </b>Server options override the client&#39;s configuration.</p>

<h3>Recommendations</h3>

<p>During configuration, you will need to make trade-offs between security, ease-of-use, 
and legacy compatibility. A wide variety of options covering network and protocol 
support, authentication, and user environment, obscure the individual option&#39;s impact 
on the whole. This section includes some configuration recommendations and discusses 
the consequences of their usage.</p>

<p>Note</p>

<p>Only the Solaris Secure Shell software and OpenSSH versions that are current 
at the time of this writing are used. Not all of the options are covered. Consult 
the vendor documentation for information on the other options and on the options 
presented here.</p>

<h4>Server Recommendations</h4>

<p>Server configuration specifies how the daemon presents itself on the network, 
what protocols are offered, and what authentication methods are allowed. Specific 
recommendations are given for each topic. Recommendations specific to a particular 
Secure Shell implementation have also been noted.</p>
<h5>Protocol Support</h5>

<p>Two major versions of the Secure Shell protocol exist. Protocol 1 has been 
deprecated because of vulnerabilities, such as packet insertion and 
password-length determination. Use Protocol 2. Disable support for Protocol 1. </p>
<h5>Network Access</h5>

<p>By default, the <tt>sshd</tt>(1M) daemon listens on all network interfaces on 
its bound ports. For workstations or other systems on which accessibility is desired 
for all interfaces, this behavior is not a problem.<font color="#FF0000"><i><b> 
For architectures such as the Service Delivery Network, in which management traffic 
is limited to a particular interface, this behavior is a problem.</b></i></font> 
Limit network access with the <tt>ListenAddress</tt> keyword. Access is limited 
by a particular IP address, not by a network interface.</p>

<pre> # Listen only to the management network.
 ListenAddress 192.168.0.10</pre>

<p>To further narrow down what the daemon will listen to, use either a host-based 
firewall, such as the SunScreen™ software, or TCP Wrappers.</p>

<p>For information about traffic-limited architectures, consult the Sun BluePrints 
OnLine article &quot;Building Secure N-Tier Environments&quot; (October 2000).</p>
<h5>Keep-Alives</h5>

<p>Occasionally, connections are temporarily suspended when a route is downed, a 
machine crashes, a connection is hijacked, or a man-in-the-middle attack is attempted. 
TCP keep-alives should be sent to detect any of these cases. If TCP keep-alives 
fail, the server will disconnect the connection and return allocated resources. 
Regular disconnects can aggravate users on faulty networks.</p>

<pre> KeepAlive yes
</pre>

<h5>Data Compression</h5>

<p>Optionally, compression can be used on the encrypted data streams. This use results 
in bandwidth savings for compressible data, such as interactive logins or log files, 
at the expense of more CPU resources. For uncompressible data such as encrypted 
or compressed files, the extra CPU time is wasted and decreases performance. For 
a single Secure Shell session, these losses are inconsequential. For a file server, 
the extra load could impact performance. In this case, turn compression off to prevent 
misconfigured clients from driving up the system load.</p>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch03lev1sec3#PLID2">[View full width]</a></pre>

<pre># Transferring ASCII data such as interactive logins or log files
 Compression yes </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch03lev1sec3#PLID3">[View full width]</a></pre>

<pre># Transferring random data such as compressed or
 encrypted files
 # Prevents performance issues and reduces CPU load
 Compression no</pre>

<h5>Privilege Separation</h5>

<p>Privilege separation is an OpenSSH-only feature. The <tt>sshd</tt>(1M) daemon 
is split into two parts: a privileged process to deal with authentication and process 
creation and an unprivileged process to deal with incoming network connections. 
After successful authentication, the privileged process spawns a new process with 
the privileges of the authenticated user. The goal is to prevent compromise from 
an error in the network facing process. Unfortunately, privilege separation is not 
really compatible with pluggable authentication modules or SunSHIELD Basic Security 
Module (BSM) auditing. Some OpenSSH features are also disabled. If privilege separation 
is desired, consult the vendor documentation.</p>

<p>Note</p>

<p>The compilation options presented in
<a href="sshd_configuration.shtml?xmlid=0131429000/ch02#ch02">Chapter 2</a> disable 
privilege separation.</p>

<pre> # OpenSSH only
 UsePrivilegeSeparation no
</pre>

<h5>Login Grace Time</h5>

<p>The default login grace time is the time a connection is allowed to exist before 
being successfully authenticated. The default of 600 seconds for the Solaris Secure 
Shell software and 120 seconds for later OpenSSH versions is too long. Reduce the 
time to 60 seconds.</p>

<pre> LoginGraceTime 60
</pre>

<h5>Password and Public Key Authentication</h5>

<p>Passwords are not always appropriate. A stronger means may be required, such 
as public-key cryptographic two-factor authentication. Secure Shell refers to the 
key pair as an identity. See &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch06#ch06">Managing 
Keys and Identities</a>&quot; on page 71 for more details. When passwords are deemed 
sufficient, do not allow empty passwords. They are too easy to guess.</p>

<pre> PasswordAuthentication yes
 PermitEmptyPasswords no
 PubKeyAuthentication yes
 DSAAuthentication yes
</pre>

<h5>Superuser (<tt>root</tt>) Logins</h5>

<p>Neither the Solaris Secure Shell software nor OpenSSH honors the values set in 
the <tt>/etc/default/login</tt> file. To prevent network superuser (<tt>root</tt>) 
logins, they must be explicitly denied. The Solaris Secure Shell software and OpenSSH 
default to <tt>yes.</tt> However, the default <tt>sshd_config</tt>(4) file in the 
Solaris Secure Shell software disables this feature. This forces a system administrator 
to log in as an unprivileged user, then change users (<tt>su</tt>) to the superuser. 
Enable superuser logins only if the system has no user accounts and the appropriate 
host protection is in place.</p>

<pre> PermitRootLogin no
</pre>

<h5>Banners, Mail, and Message-of-the-Day</h5>

<p>Some sites require that a banner be displayed after a user connects to a system, 
but before logging in. You can accomplished this with the <tt>Banner</tt> keyword. 
Set <tt>Banner</tt> to <tt>/etc/issue</tt> so that only one banner file exists for 
the entire system.</p>

<pre> Banner /etc/issue</pre>

<p>In the Solaris OE, the interactive login shell is expected to display the message-of-the-day 
(MOTD) and to check for new mail. With some versions of OpenSSH, this feature causes 
the MOTD display and mail check to be done twice. Set these keywords to <tt>no</tt> 
to eliminate the duplication.</p>

<pre> CheckMail no
 PrintMotd no</pre>

<h5>Connection and X11 Forwarding</h5>

<p>Secure Shell can tunnel TCP and X protocol connections through encrypted connections 
established between the client and server. Tunneling the traffic is referred to 
as forwarding. The forwarding occurs at the application level and is not completely 
transparent to the applications being forwarded. The applications need some configuration 
to use the tunnel.</p>

<p>Note</p>

<p>Data is protected only while it is in the tunnel between the client and server. 
After that, it is normal network traffic in the clear.</p>

<p>Tunneled traffic bypasses firewalls and intrusion detection systems. Allowing 
connection (TCP port) forwarding allows remote users safer access to email or the 
corporate web server. X forwarding allows system administrators to run GUI applications 
remotely, such as the Solaris™ Management Console software. This may not be functionality 
you want your users setting up. You can inconvenience users by turning off the functionality, 
but as long as they have shell access, they can run their own forwarders. Use role-based 
access control to explicitly limit what you want your users to do in this case.</p>

<p>If port forwarding is enabled, disable <tt>GatewayPorts</tt> and notify your 
users. <tt>GatewayPorts</tt> allows machines, other than the client, to access the 
forwarded ports in the tunnel. This access effectively bypasses any firewall usage. 
Again, users could run their own private forwarders on their client machines to 
defeat the server restrictions. Consider placing an intrusion detection sensor on 
the private network side of a Secure Shell bastion host to detect problem traffic.</p>

<pre> AllowTCPForwarding yes
 GatewayPorts no
 X11DisplayOffset 10
 X11Forwarding yes
 XAuthLocation /usr/X/bin/xauth
</pre>

<h5>User Access Control Lists</h5>

<p>User access control lists (ACLs) can be specified in the server configuration 
file. No other part of the Solaris OE honors this ACL. You can either specifically 
allow or deny individual users or groups. The default is to allow access to anyone 
with a valid account. You can use ACLs to limit access to particular users in NIS 
environments, without resorting to custom pluggable authentication modules. Use 
only one of the following four ACL keywords in the server configuration file:
<tt>AllowGroups</tt>, <tt>AllowUsers</tt>, <tt>DenyGroups</tt> or <tt>DenyUsers</tt>.</p>

<pre> # Allow only the sysadmin staff
 AllowGroups staff
</pre>

<pre> # Prevent unauthorized users.
 DenyUsers cheng atkinson
</pre>

<h5>User File Permissions</h5>

<p>If a user has left their home directory or .ssh files world writable either by 
accident or by trickery, an intruder could insert identities allowing password-free 
access or alter the <tt>known_hosts</tt> file to allow man-in-the-middle attacks. 
With <tt>StrictModes</tt> enabled, the <tt>sshd</tt>(1M) daemon will not allow a 
login. But, users can be easily confused because they will not know why they cannot 
log in. No different error message is presented to them.</p>

<pre> StrictModes yes
</pre>

<p>If you decide to disable <tt>StrictModes</tt>, consider eliminating public-key-based 
authentication to prevent user account compromise. The consequence is the elimination 
of password-free logins for users or automated jobs.</p>
<h5><tt>UseLogin</tt> Keyword</h5>

<p>For OpenSSH only, <tt>UseLogin</tt> specifies that the OpenSSH <tt>sshd</tt>(1M) 
call <tt>login</tt>(1) instead of performing the initial login tasks itself for 
interactive sessions. <tt>login</tt>(1) must be called for BSM auditing. Unless
<tt>UseLogin</tt> is set to <tt>yes, cron</tt>(1M) will partially break if SunSHIELD 
BSM auditing is enabled. See &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch07#ch07">Auditing</a>&quot; 
on page 81 for details on the consequences of <tt>UseLogin</tt> and on getting BSM 
auditing to work successfully. <tt>UseLogin</tt> will not work if <tt>UsePrivilegeSeparation</tt> 
is enabled. Enabling <tt>UseLogin</tt> disables X11 and port forwarding.</p>

<pre> UseLogin no
</pre>

<h5>Legacy Support</h5>

<p>If legacy clients must be supported, strengthen the default configuration as 
much as possible. Default to Protocol 2 for the clients that support it. Disable 
all of the <tt>rhosts-</tt>style authentication methods. Increase the server key 
size and decrease the ephemeral key regeneration interval to minimize offline factoring 
attacks against the keys.</p>

<pre> # Enable protocol 1 but default to protocol 2.
 Protocol 2,1
 # Legacy support options - protocol 1 only
 HostKey /etc/ssh/ssh_host_key
 IgnoreRhosts yes
 IgnoreUserKnownHosts yes
 KeyRegenerationInterval 1800
 RhostsAuthentication no
 RhostsRSAAuthentication no
 RSAAuthentication yes
 ServerKeyBits 1024</pre>

<h3>Configuration Options</h3>

<p><tt>AllowGroups</tt> pattern</p>

<ul>

	<li>

	<p><font color="#FF0000"><i><b>Specifies a group access control list. After 
	authentication, access is granted if the user&#39;s primary group matches the pattern 
	given.</b></i></font> The primary group is the GID field listed in <tt>/etc/passwd</tt>. 
	The pattern is the token listed in <tt>/etc/group</tt>. Wildcards of asterisk 
	(<tt>*</tt>), matching any number of characters, or question mark (<tt>?</tt>), 
	matching a single character, can be used. Patterns are space delimited. Use 
	only one of the following access control keywords in the server configuration 
	file: <tt>AllowGroups</tt>, <tt>AllowUser</tt>, <tt>DenyGroups</tt>, or <tt>
	DenyUsers</tt>.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to allow access.</p>
	</li>

	<li>

	<p>See also <tt>AllowUser</tt>, <tt>DenyGroups</tt>, and <tt>DenyUser</tt>. 
	For example</p>
	</li>
</ul>

<pre>   # Allow only the whell access
   AllowGroups wheel</pre>

<pre>   # Allow both staff and sysadmin access
   AllowGroups s*</pre>

&nbsp;<p><tt>AllowUsers</tt> pattern</p>

<ul>

	<li>

	<p>Specifies a user access control list. After authentication, access is granted 
	if the user&#39;s login matches the pattern given. The pattern should be alphanumeric, 
	not the numerical UID value. Wildcards of asterisk (*), matching any number 
	of characters, or question mark (?), matching a single character, can be used. 
	Patterns are space delimited. </p>
	</li>
</ul>

<p>Use only one of the following access control keywords in the server configuration 
file: <tt>AllowGroups, AllowUser, DenyGroups</tt>, or <tt>DenyUsers</tt>.</p>

<ul>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to allow access.</p>
	</li>

	<li>

	<p>See also <tt>AllowGroups, DenyGroups</tt>, and <tt>DenyUser</tt>.</p>
	</li>
</ul>

<pre>   # Allow only Suzie and Buster access.
   AllowUsers suzie buster</pre>

<p><tt>AllowTCPForwarding yes | no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not TCP forwarding (also known as port forwarding) is 
	allowed.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>no</tt>. OpenSSH defaults 
	to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>If you want users to protect their mail, Web, or other traffic, enable this 
	option. Setting <tt>UseLogin</tt> to <tt>yes</tt> in OpenSSH disables this feature.</p>
	</li>

	<li>

	<p>See also <tt>GatewayPorts</tt> and <tt>X11Forwarding</tt>.</p>
	</li>
</ul>

<p><b>Note</b></p>

<p>If users have shell access, they can install their own port forwarders. If this 
is an issue, consider RBAC to limit access.</p>

<pre># Protect user&#39;s traffic
   AllowTCPForwarding yes</pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app02#PLID4">[View full width]</a></pre>

<pre># Only allow a remote job restricted access to
 gather logs.
   AllowTCPForwarding no</pre>

<p><tt>Banner</tt> value</p>

<ul>

	<li>

	<p>Specifies a banner that is displayed along with the authentication prompt. 
	If your environment requires this banner, set to <tt>/etc/issue</tt> so that 
	only one banner exists for the entire system.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to no banner.</p>
	</li>
</ul>

<pre>   Banner /etc/issue</pre>

<p><tt>CheckMail yes | no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not the server should check for new mail. In the Solaris 
	OE, the login shell should check for new mail only during the beginning of interactive 
	logins.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>no</tt>. New versions of 
	OpenSSH no longer honor this keyword.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PrintMotd</tt>.</p>
	</li>
</ul>

<pre>   CheckMail no</pre>

<p><tt>Ciphers</tt> list</p>

<ul>

	<li>

	<p>For Protocol 2 only, specifies which ciphers are available. The cipher list 
	is comma delimited, and the clients use the first available choice, unless overridden 
	on the command line.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>aes128-cbc,blowfish-cbc,3des-cbc</tt>. 
	OpenSSH defaults to <tt>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc</tt>.</p>
	</li>
</ul>

<pre>   Ciphers aes128-cbc,blowfish-cbc,3des-cbc
</pre>

<p><tt>Compression yes | no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not compression can be used.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>
</ul>

<pre>   Compression yes
</pre>

<p><tt>DenyGroups</tt> pattern</p>

<ul>

	<li>

	<p>Specifies a group access control list. After authentication, access is denied 
	if the user&#39;s primary group matches the given pattern. The primary group is 
	the GID field listed in <tt>/etc/passwd</tt>. The pattern is the token listed 
	in <tt>/etc/group</tt>. Wildcards of asterisk (*), matching any number of characters, 
	or question mark(?), matching a single character, can be used. Patterns are 
	space delimited. Use only one of the following access control keywords in the 
	server configuration file: <tt>AllowGroups, AllowUser, DenyGroups</tt>, or
	<tt>DenyUsers</tt>.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to allow access.</p>
	</li>

	<li>

	<p>See also <tt>AllowGroups, AllowUsers</tt>, and <tt>DenyUsers</tt>.</p>
	</li>
</ul>

<pre>   # Prevent the users from logging in to the server  
   DenyGroups users
</pre>

<p><tt>DenyUsers</tt> pattern</p>

<ul>

	<li>

	<p>Specifies a user access control list. After authentication, access is denied 
	if the user&#39;s login matches the pattern given. The pattern can be alphanumeric, 
	but not the numerical UID value. Wildcards of asterisk (*), matching any number 
	of characters, or question mark (?), matching a single character, can be used. 
	Patterns are space delimited. Use only one of the following access control keywords 
	in the server configuration file: <tt>AllowGroups, AllowUser, DenyGroups</tt>, 
	or <tt>DenyUsers</tt>.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to allow access.</p>
	</li>

	<li>

	<p>See also <tt>AllowGroups, AllowUsers</tt>, and <tt>DenyGroups</tt>.</p>
	</li>
</ul>

<pre>   DenyUsers Cheng Atkinson
</pre>

<p><tt>DSAAuthentication yes | no</tt></p>

<ul>

	<li>

	<p>For Protocol 2 only, specifies whether or not DSA authentication is allowed.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PubKeyAuthentication</tt>.</p>
	</li>
</ul>

<pre>   DSAAuthentication yes
</pre>

<p><tt>GatewayPorts yes | no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not remote hosts are allowed to connect to ports forwarded 
	by the client. This can be used to form a limited VPN setup. Setting <tt>UseLogin</tt> 
	to <tt>yes</tt> in OpenSSH disables this feature.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>
</ul>

<p>Note</p>

<p>Users can chain together port forwarders (that is, create a bouncer) on the local 
machine to circumvent this restriction.</p>

<ul>

	<li>

	<p>See also <tt>AllowTCPForwarding</tt>.</p>
	</li>
</ul>

<pre>   GatewayPorts no
</pre>

<p><tt>HostKey</tt> value</p>

<ul>

	<li>

	<p>Specifies the private host key files. These keys are used to securely identify 
	the server. <tt>ssh_host_key</tt> is needed for Protocol 1 support. <tt>ssh_host_rsa_key</tt> 
	is needed for Protocol 2 RSA authentication. <tt>ssh_host_dsa_key</tt> is needed 
	for Protocol 2 DSA authentication. The keys must be generated with <tt>ssh-keygen</tt> 
	if they do not exist before first invocation of <tt>sshd</tt>(1M).</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to: <tt>/etc/ssh</tt> OpenSSH 
	defaults to: <tt>/usr/local/etc</tt></p>
	</li>
</ul>

<pre>   HostKey /etc/ssh/ssh_host_key
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_dsa_key
</pre>

<p><tt>IgnoreRhosts yes | no</tt></p>

<ul>

	<li>

	<p>For Protocol a only, specifies whether or not a user&#39;s. <tt>.rhosts</tt> 
	and <tt>.shosts</tt> files are used for authentication.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>

	<li>

	<p>See also <tt>RhostsAuthentication</tt>.</p>
	</li>
</ul>

<pre>   IgnoreRhosts yes
</pre>

<p><tt>IgnoreUserKnownHosts yes | no</tt></p>

<ul>

	<li>

	<p>For Protocol 1, specifies whether or not a user&#39;s <tt>~/.ssh/known_hosts</tt> 
	file will be used during <tt>RhostsRSAAuthentication</tt>.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>

	<li>

	<p>See also <tt>RhostsRSAAuthentication</tt>.</p>
	</li>
</ul>

<pre>   IgnoreUserKnownHosts yes
</pre>

<p><tt>KeepAlive yes | no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not TCP keep-alives are sent. If they are sent, the 
	death of a connection, crash of a machine, or downing of a route will be noticed, 
	and the connection terminated. This prevents connections from hanging and consuming 
	resources.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>
</ul>

<pre>   keepAlive yes
</pre>

<p><tt>KeyRegenerationInterval</tt> value</p>

<ul>

	<li>

	<p>For Protocol 1 only, the ephemeral key (that is, the key to encrypt data, 
	not the one to identify the server) is regenerated after the designated time 
	in seconds, if it has been used.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>3600</tt> seconds.</p>
	</li>

	<li>

	<p>Recommend value is <tt>1800</tt> seconds. Do not set this value too low, 
	or the server will spend all of its time generating new keys.</p>
	</li>
</ul>

<pre>   KeyRegenerationInterval 1800
</pre>

<p><tt>ListenAddress</tt> value</p>

<ul>

	<li>

	<p>Specifies the local address on which the server should listen. <i><b>For 
	multihomed machines, you can limit the server to listening on only one address.</b></i> 
	The <tt>port</tt> keyword must be placed before this keyword.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to listen to all local 
	addresses.</p>
	</li>

	<li>

	<p>Recommended value is to limit to only administrative address interfaces, 
	when possible.</p>
	</li>
</ul>

<pre>   ListenAddress 192.168.0.5
</pre>

<p><tt>LoginGraceTime</tt> value</p>

<ul>

	<li>

	<p>Specifies the grace time during which a connection can exist without successful 
	authentication.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to 600 seconds.</p>
	</li>

	<li>

	<p>OpenSSH defaults to 120 seconds.</p>
	</li>

	<li>

	<p>Recommended value is 60 seconds.</p>
	</li>

	<li>

	<p>See also <tt>MaxStartups</tt>.</p>
	</li>
</ul>

<pre>   LoginGraceTime 60
</pre>

<p><tt>LogLevel</tt> value</p>

<ul>

	<li>

	<p>Specifies the verbosity of logging information. Information is logged by 
	using <tt>syslog</tt>(3). Higher levels generate a larger volume of log data.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>INFO</tt>.</p>
	</li>

	<li>

	<p>See also <tt>SyslogFacility</tt>.</p>
	</li>

	<li>

	<p>See <tt>syslog</tt>(3), <tt>syslog.conf</tt>(4), and <tt>syslogd</tt>(1M) 
	for information.</p>
	</li>
</ul>

<pre>   LogLevel DEBUG
</pre>

<p><tt>MACs</tt> list</p>

<ul>

	<li>

	<p>For Protocol 2 only, specifies which message authentication code (MAC) algorithms 
	are available. The MAC list is comma delimited. The clients use the first match, 
	unless overridden on the command line.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>hmac-sha1, hmac-md5</tt>. 
	OpenSSH defaults to <tt>hmac-md5, hmac-sha1, hmac-ripemd160, hmac-sha1-96, hmac-md5-96</tt>.</p>
	</li>
</ul>

<pre>   MACS hmac-sha1, hmac-md5
</pre>

<p><tt>MaxAuthTries</tt> value</p>

<ul>

	<li>

	<p>For the Solaris Secure Shell software only, specifies the maximum number 
	of retries for authentication before a connection is dropped.</p>
	</li>

	<li>

	<p>The default is <tt>6</tt>. This value cannot be overridden by <tt>ConnectionAttempts</tt> 
	in the client configuration file.</p>
	</li>
</ul>

<pre>   MaxAuthTries 6
</pre>

<p>The following is an example of when <tt>MaxAuthTries</tt> is set to 2, and the 
user fails to log in successfully:</p>

<pre>hook /home/suzi $ ssh blackbeard
   suzi@blackbeard&#39;s password: password
   Permission denied, please try again.
   suzi@blackbeard&#39;s password: password
   Received disconnect: 2: too many failed
 userauth_requests
   hook /home/suzi $</pre>

<p><tt>MaxAuthTriesLog</tt> value</p>

<ul>

	<li>

	<p>For the Solaris Secure Shell software only, specifies the number of retries 
	for authentication before a warning message is logged.</p>
	</li>

	<li>

	<p>The default is <tt>MaxAuthTries</tt> divided by two.</p>
	</li>

	<li>

	<p>See also <tt>LogLevel</tt> and <tt>SyslogFacility</tt>.</p>
	</li>
</ul>

<pre>   MaxAuthTriesLog 3</pre>

<p><tt>MaxStartups</tt> value</p>

<ul>

	<li>

	<p>Specifies the maximum number of concurrent unauthenticated connections. When 
	the limit is reached, no new connections are allowed until the count drops.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>10</tt>.</p>
	</li>

	<li>

	<p>See also <tt>LoginGraceTime</tt>.</p>
	</li>
</ul>

<pre>   MaxStartups 10</pre>

<p><tt>PAMAuthenticationViaKBDInt yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not to use pluggable authentication modules through 
	the keyboard interactive method for authentication. Setting the value to <tt>
	yes</tt> allows the use of custom pluggable authentication modules.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>
</ul>

<pre>   PAMAuthenticationViaKBDInt yes</pre>

<p><tt>PasswordAuthentication yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not passwords can be used for authentication. For systems 
	with many users on internal corporate accounts, password authentication is sufficient. 
	For remote users or automated execution, use key-based authentication.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PermitEmptyPasswords, PermitRootLogin</tt>, and <tt>PubKeyAuthentication</tt>.</p>
	</li>
</ul>

<pre>   # Internal mail server
   PasswordAuthentication yes</pre>

<pre>   # DMZ Bastion host
   PasswordAuthentication no
</pre>

<p><tt>PermitEmptyPasswords yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not accounts with empty passwords are allowed to log 
	in.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PasswordAuthentication</tt>.</p>
	</li>
</ul>

<pre>   PermitEmptyPasswords no
</pre>

<p><tt>PermitRootLogin yes|no|without-password|forced-commands-only</tt></p>

<ul>

	<li>

	<p>Specifies whether or not the superuser (<tt>root</tt>) account can log in 
	over the network. <tt>without-password</tt> allows logins by using key-based 
	authentication only. For OpenSSH only, the additional value, <tt>forced-commands-only</tt>, 
	can be used. This requires key-based authentication and a command to be associated 
	with the particular key.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>no</tt>. OpenSSH defaults 
	to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PasswordAuthentication</tt> and <tt>PubKeyAuthentication</tt>.</p>
	</li>
</ul>

<pre>   # Force the system admins to su
   PermitRootLogin no
</pre>

<pre>   # Only a root account exists
   PermitRootLogin without-password
</pre>

<p><tt>PermitUserEnvironment yes|no</tt></p>

<ul>

	<li>

	<p>For OpenSSH only, specifies whether or not the server should process environment 
	options in <tt>~/.ssh/environment</tt> or <tt>~/.ssh/authorized</tt> keys.</p>
	</li>

	<li>

	<p>The default and recommended value is <tt>no</tt>.</p>
	</li>
</ul>

<pre>   PermitUserEnvironment no
</pre>

<p><tt>Port</tt> value</p>

<ul>

	<li>

	<p>Specifies the port on which the server is to listen. The Internet Assigned 
	Numbers Authority (IANA) assigned port for Secure Shell is <tt>22</tt>. If your 
	firewall blocks low-value ports (less than 1024), a higher value might be needed. 
	You can have multiple listings of this keyword.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>22</tt>.</p>
	</li>
</ul>

<pre>   # For LAN access 
   Port 22
   # For Internet access
   Port 2345
</pre>

<p><tt>PrintMotd yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not the server should display the message-of-the-day 
	(MOTD). In the Solaris OE, the login shell should display the MOTD at the beginning 
	of interactive logins.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>no</tt>. OpenSSH defaults 
	to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>CheckMail</tt>.</p>
	</li>
</ul>

<pre>   PrintMotd no
</pre>

<p><tt>Protocol</tt> list</p>

<ul>

	<li>

	<p>Specifies the Secure Shell protocols available. The first version of the 
	protocol has been deprecated because of flaws in the protocol allowed packet 
	insertion and password length-determination attacks. The second version of the 
	protocol was developed to address the problems. The client uses the first available 
	protocol in the list.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to <tt>2</tt>. OpenSSH defaults 
	to <tt>2,1</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>2</tt>.</p>
	</li>
</ul>

<pre>   # Protocol 2 only is recommended
   Protocol 2
</pre>

<pre>   # Enable legacy support but default to Protocol 2.
   Protocol 2,1
</pre>

<p><tt>PubKeyAuthentication yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not public keys can be used for Shell software and OpenSSH 
	default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>

	<li>

	<p>See also <tt>PasswordAuthentication</tt>.</p>
	</li>
</ul>

<pre>   PubKeyAuthentication yes
</pre>

<p><tt>RhostsAuthentication yes|no</tt></p>

<ul>

	<li>

	<p>For protocol 1 only, specifies whether or not <tt>rhosts</tt>(4) or hosts.<tt>equiv</tt>(4) 
	authentication is sufficient.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>IgnoreRhosts</tt>.</p>
	</li>
</ul>

<pre>   RhostsAuthentication no
</pre>

<p><tt>RhostsRSAAuthentication yes|no</tt></p>

<ul>

	<li>

	<p>For Protocol 1 only, specifies whether or not <tt>rhosts</tt>(4) or <tt>hosts.equiv</tt>(4) 
	authentication with RSA host authentication is allowed.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>See also <tt>IgnoreUserKnownHosts</tt>.</p>
	</li>
</ul>

<pre>   RhostsRSAAuthentication no
</pre>

<p><tt>RSAAuthentication yes|no</tt></p>

<ul>

	<li>

	<p>For Protocol 1 only, specifies whether or not RSA Protocol 1 user authentication 
	is allowed.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>
</ul>

<pre>   RSAAuthentication yes
</pre>

<p><tt>ServerKeyBits</tt> value</p>

<ul>

	<li>

	<p>For Protocol 1 only, this is the size in bits of the server key.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>768</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>1024</tt>.</p>
	</li>
</ul>

<pre>   ServerKeyBits 1024
</pre>

<p><tt>StrictModes yes|no</tt></p>

<ul>

	<li>

	<p>In case a user&#39;s home directory or <tt>.ssh</tt> files are world writable 
	or if they are owned by someone else, the server will prevent a login. This 
	action prevents a compromise.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>yes</tt>.</p>
	</li>
</ul>

<pre>   StrictModes yes
</pre>

<p><tt>SyslogFacility</tt> value.value</p>

<ul>

	<li>

	<p>Specifies the facility and security codes to use when logging by using
	<tt>syslog</tt>(3).</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>AUTH.INFO</tt>.</p>
	</li>

	<li>

	<p>See also <tt>LogLevel</tt>.</p>
	</li>

	<li>

	<p>Consult <tt>syslog</tt>(3), <tt>syslog.conf</tt>(4), and <tt>syslogd</tt>(1M) 
	for more information.</p>
	</li>
</ul>

<pre>   SyslogFacility AUTH.INFO
</pre>

<p><tt>UseLogin yes|no</tt></p>

<ul>

	<li>

	<p>For OpenSSH only, specifies whether or not <tt>login</tt>(1) is called for 
	interactive sessions. This feature is required for BSM auditing. Turning it 
	on will disable X11 and port forwarding. <tt>cron</tt>(1M) will also partially 
	break. See &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch07#ch07">Auditing</a>&quot; 
	on page 81 for details on the consequences of <tt>UseLogin</tt> and on getting 
	BSM auditing to work successfully. This feature will not work if <tt>UsePrivilegeSeparation</tt> 
	is set to <tt>yes</tt>.</p>
	</li>

	<li>

	<p>The default value is <tt>no</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>
</ul>

<pre>   UseLogin no
</pre>

<p><tt>UsePrivilegeSeparation yes|no</tt></p>

<ul>

	<li>

	<p>For OpenSSH only, specifies whether or not the server separates privileges 
	by having an unprivileged child process deal with incoming network traffic. 
	After successful authentication, a separate process is created with the privileges 
	of the user. This is an attempt to prevent a <tt>root</tt> compromise by any 
	corruption from the incoming network traffic (for example, a buffer overflow). 
	This feature does not work with pluggable authentication modules on the Solaris 
	OE.</p>
	</li>
</ul>

<p>Note</p>

<p>The compilations options presented in
<a href="sshd_configuration.shtml?xmlid=0131429000/ch02#ch02">Chapter 2</a> disable 
this feature.</p>

<ul>

	<li>

	<p>The default value is <tt>yes</tt>.</p>
	</li>

	<li>

	<p>Recommended value is <tt>no</tt>.</p>
	</li>
</ul>

<pre>   UsePrivilegeSeparation no
</pre>

<p><tt>X11DisplayOffset</tt> value</p>

<ul>

	<li>

	<p>Specifies the first display number available for the server&#39;s X11 forwarding. 
	This option prevents interference with real X11 servers.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>10</tt>. For 
	Sun Ray™ appliance servers, if this value is too low, increase by the maximum 
	number of clients, plus a margin for error.</p>
	</li>
</ul>

<pre>   # For desktops or server
   X11DisplayOffset 10
</pre>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app02#PLID48">[View full width]</a></pre>

<pre># For Sun Ray appliance servers, may need to be
 more.
   X11DisplayOffset 100
</pre>

<p><tt>X11Forwarding yes|no</tt></p>

<ul>

	<li>

	<p>Specifies whether or not X11 forwarding is permitted. In OpenSSH, setting
	<tt>UseLogin</tt> to <tt>yes</tt> disables this feature. If you want users to 
	protect their X11 traffic, enable this option.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software and OpenSSH default to <tt>no</tt>.</p>

	<p>Note</p>

	<p>Users with shell access can install their own X11 forwarders. If this is 
	an issue, consider RBAC to limit access. For Solaris 9 OE systems, consider 
	using X with the <tt>-nolisten</tt> flag to limit exposure. This flag limits 
	the X11 applications to running only on the server.</p>
	</li>

	<li>

	<p>See also <tt>AllowTCPForwarding</tt>.</p>
	</li>
</ul>

<pre> 
   # Protect user&#39;s X sessions
   X11Forwarding yes
</pre>

<pre>   # Only allow restricted access for a remote job
   X11Forwarding no
</pre>

<p><tt>XAuthLocation</tt> Value</p>

<ul>

	<li>

	<p>Specifies the location of the <tt>xauth</tt>(1) program. This option will 
	not override the default that is used when the software is compiled.</p>
	</li>

	<li>

	<p>The Solaris Secure Shell software defaults to: <tt>/usr/X/bin/xauth</tt> 
	OpenSSH defaults to: <tt>/usr/openwin/bin/xauth</tt></p>
	</li>

	<li>

	<p>Recommended value is: <tt>/usr/X/bin/xauth</tt></p>
	</li>
</ul>

<pre>   XAuthLocation /usr/X/bin/xauth
 </pre>

<h3>Port Forwarding</h3>

<p>Secure Shell can enscapsulate TCP-based application data streams and then tunnel 
them across its secure connection to and from the client and server. This is referred 
to as port forwarding. Port forwarding is useful for securing communications with 
legacy platforms or internal systems such as the internal web site, internal Internet 
relay chat (IRC) network, or email access.</p>

<p>Port forwarding is not transparent to the application. The application requires 
some configuration to use the forwarded ports. For situations requiring transparency, 
a network-level solution such as IPsec or VPNs must be used. Port forwarding will 
not work for UDP-based protocols or for protocols, such as IRC DCC channels, that 
dynamically allocate a second data stream on a separate port.</p>

<p>Ports to be forwarded can either be specified on the command line or in the client 
configuration file (recommended for a system with multiple forwarded port). Forwarded 
ports can also be local (from client to server) or remote (server to the client). 
Port forwarding and RBAC can provide secure access to an IMAP mail server while 
preventing the users from having access to the server itself.</p>

<p>The following two examples show the local forwarding of port 8080 on the client 
to port 80 on the server.</p>

<p>This example shows forwarding using the <tt>ssh</tt>(1) command:</p>

<pre> $ ssh -L8080:server:80 server
</pre>

<p>This example shows forwarding using the client&#39;s configuration file:</p>

<pre> Host server
 LocalForward 8080 server:80
</pre>

<p>Note</p>

<p>The Solaris Secure Shell software disables port forwarding by default. See &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch03lev1sec3#ch03lev3sec10">Connection 
and X11 Forwarding</a>&quot; on page 46 for more details.</p>

<h4>To Secure WebNFS Mounts With Port Forwarding</h4>

<ol type="1">

	<li>

	<p>Choose an unused local port and forward it to the WebNFS port on the server.</p>

	<p>A different local port will be needed for each server. This connection must 
	be maintained for the life of the mount.</p>
	<table cellspacing="0" cellpadding="5" rules="none" border="1">
		<colgroup>
			<col width="500">
		</colgroup>
		<thead>
		</thead>
		<tr>
			<td valign="top" align="left">

			<pre> $ ssh -f -N -L3030:server:2049 server
</pre>

			<p><br>
&nbsp;</p>
			</td>
		</tr>
	</table>

	<p><br>
&nbsp;</p>
	</li>

	<li>

	<p>Become the superuser.</p>
	</li>

	<li>

	<p>Mount the file system using the forwarded port.</p>
	<table cellspacing="0" cellpadding="5" rules="none" border="1">
		<colgroup>
			<col width="500">
		</colgroup>
		<thead>
		</thead>
		<tr>
			<td valign="top" align="left">

			<pre> # mount nfs://localhost:3030/export/home /mnt
</pre>

			<p><br>
&nbsp;</p>
			</td>
		</tr>
	</table>

	<p><br>
&nbsp;</p>
	</li>
</ol>

<p>Note</p>

<p>This procedure provides transport-level protection only for the WebNFS traffic. 
Using Secure Shell in this manner does not provide additional WebNFS authentication.</p>

<h3>Insecure Service Disablement</h3>

<p>Insecure services can be disabled by commenting them out of <tt>inetd.conf.</tt> 
The comment character is a hash (<tt>#</tt>). Consider making a backup copy of
<tt>inetd.conf</tt> before editing. For information on <tt>inetd</tt>(1M) and
<tt>inetd.conf</tt>(4), consult their respective man pages.</p>

<p>Remove any service not needed for your environment. In particular, remove <tt>
ftp</tt>, <tt>telnet</tt>, <tt>shell</tt>, <tt>login</tt>, and <tt>exec</tt>. Consider 
removing <tt>echo</tt>, <tt>discard</tt>, <tt>daytime</tt>, <tt>chargen</tt>,
<tt>comsat</tt>, and <tt>talk</tt> services as well. These are normally not needed.</p>

<h4>To Disable Insecure Services</h4>

<ol type="1">

	<li>

	<p>Become the superuser.</p>
	</li>

	<li>

	<p>Edit <tt>/etc/inetd.conf</tt> and comment out insecure services.</p>
	</li>

	<li>

	<p>Use the <tt>kill</tt>(2) command to send the <tt>HANGUP</tt> signal to
	<tt>inetd</tt>(1M).</p>
	<table cellspacing="0" cellpadding="5" rules="none" border="1">
		<colgroup>
			<col width="500">
		</colgroup>
		<thead>
		</thead>
		<tr>
			<td valign="top" align="left">

			<pre> </pre>

			<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch05lev1sec5#PLID0">[View full width]</a></pre>

			<pre># ps -ef | grep inetd | grep -v grep
     root   153     1  0   Dec 09 ?       0:02 
/usr/sbin/inetd -s
 # kill -HUP 153
</pre>

			<p><br>
&nbsp;</p>
			</td>
		</tr>
	</table>

	<p><br>
&nbsp;</p>
	</li>

	<li>

	<p>Ensure that the services have been disabled.</p>
	<table cellspacing="0" cellpadding="5" rules="none" border="1">
		<colgroup>
			<col width="500">
		</colgroup>
		<thead>
		</thead>
		<tr>
			<td valign="top" align="left">

			<pre> </pre>

			<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch05lev1sec5#PLID1">[View full width]</a></pre>

			<pre>$ telnet localhost
 Trying 127.0.0.1...
 telnet: Unable to connect to remote host:
 Connection refused
 $ rsh localhost
 localhost: Connection refused
</pre>

			<p><br>
&nbsp;</p>
			</td>
		</tr>
	</table>

	<p><br>
&nbsp;</p>
	</li>
</ol>

<h2>Chapter 6. Managing Keys and Identities</h2>

<p>Secure Shell uses public key cryptography to verify servers (host keys) and, 
optionally, users (identities) on a network that is assumed to be insecure. Challenges 
are made using the public key, and only the private key owner can answer the challenge 
correctly. The price of this security is maintaining a set of secrets (private keys) 
and identifiers (public keys).</p>

<p>The key pairs come in three forms: RSA pairs labeled RSA1 (Protocol 1 only), 
RSA pairs labeled RSA (Protocol 2 only), and DSA pairs labeled DSA (Protocol 2 only). 
The key pairs can range in size from 512 to 8192 bits. The <tt>ssh-keygen</tt>(1) 
command generates the key pairs.</p>

<p>While host and user identity key pairs are given different treatment in this 
book, they are essentially the same. Host keys are unencrypted user identity keys 
stored at a different location</p>

<h3>Host Keys</h3>

<p>A host key is the public and private key pair used to authenticate the Secure 
Shell server to the client. The host key provides assurance that the client is communicating 
only with the correct host by preventing name service spoofing and man-in-the-middle 
attacks (that is, impersonation of the host). The Secure Shell <tt>init</tt> script 
generates a host key pair using the <tt>ssh-keygen</tt>(1) command if the pair is 
not present at startup. When the term host key is used by itself, it refers to the 
public key component of the pair.</p>

<p>At the beginning of a Secure Shell session, the server sends the public host 
key to the client. The client compares the key to the copy it has in its <tt>$HOME/. 
ssh/known_hosts</tt> file. If the key differs, the following warning message is 
displayed:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec1#PLID0">[View full width]</a></pre>

<pre>$ ssh verney
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 @    WARNING: REMOTE HOST IDENTIFICATION HAS
 CHANGED!        @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 Someone could be eavesdropping on you right now 
(man-in-the-middle attack) It is also 
 possible that the RSA host key has been changed.
 The fingerprint for the RSA key sent 
 by the remote host is md5 88:0e:85:4c:69:e2:9d:19
:c1:39:a7:b6:f8:4b:bc:d3. 
 Please contact your system administrator. 
 Add correct host key in /home/melissa/.ssh
/known_hosts 
 Offending key is entry 7 in /home/melissa/.ssh
/known_hosts 
 RSA host key for verney has changed and you have
 requested strict checking.
</pre>

<p>The problem is how to get the public host key securely to the client initially. 
The ideal solution is to use a name service for host key lookups, as in the case 
for IP addresses or login UIDs. This approach would eliminate the need for the client 
to maintain its own database of host keys. Unfortunately, Secure Shell was designed 
as a point-to-point solution without an integrated public key infrastructure. There 
has been an IETF proposal to add host key lookups to the domain name service (DNS), 
but neither the Solaris Secure Shell software or OpenSSH support this functionality 
at this time.</p>

<p>The simplest, but riskiest, solution is for the client to just accept a new host 
key when encountered. This places the client at the risk of a man-in-the-middle 
attack. Advise users who do this to check the host key offered by the Secure Shell 
server with the host key stored on the server. The two keys must match. The intermediate 
solution is to compare existing keys and display an error if the keys differ. If 
a key is newly encountered, prompt the user to accept it or abort the connection. 
The hardest, but safest, solution is to distribute a <tt>known_hosts</tt> file to 
the client with all of the host keys in it. Keys can be gathered out-of-band through 
the console.</p>

<p>In a small environment, gathering host keys out-of-band and distributing them 
is not a problem. For large environments, this is not the case. A program would 
constantly have to search for new machines and update keys as hardware is replaced 
or operating systems reinstalled. Then, the updated key collection would have to 
be distributed to every Secure Shell client. Automation can only partially alleviate 
this issue.</p>

<p>At the Solaris OE install time with the JumpStart software, the machine can be 
given either the current host key collection or a single server host key. Using 
the key provided, the system can poll for updated key collections. This approach 
allows the Secure Shell clients to safely acquire host key information. It does 
not allow Secure Shell servers to safely register newly generated host keys. The 
problem is distinguishing between a host key generated from a fresh Solaris OE installation 
and an imposter on the network.</p>

<p>The obvious solution is to use <tt>ssh-keyscan</tt>(1) to audit the network for 
host keys. You will gather a list of host keys for all of the Secure Shell daemons 
to which your client can connect. It is a nice solution and, at face value, solves 
the problem of largescale host key gathering. The catch is that you cannot trust 
the data because you do not know to whom you are communicating. The client could 
already be impersonated. You do not know if the machine actually exists. The <tt>
ssh-keyscan</tt>(1) command can be used to audit host key changes on the network, 
but you will not immediately know if it is a legitimate change or an impersonation</p>

<h3>User Identities</h3>

<p>A user identity is a public and private key pair used to authenticate a user 
to the system. Secure Shell identities provide an alternative to the standard user 
name and password authentication scheme. The standard scheme is by far the most 
popular method for authentication. However, it suffers from a number of well-documented 
problems. Users tend to write down their passwords, and the scheme allows dictionary 
attacks, social engineering, and sniffing in unsecured transmission channels. Additionally, 
there is nothing unique that a user can possess to distinguish that user from an 
imposter.</p>

<p>A user identity is a two-factor authentication system with three components. 
An identity does not suffer the majority of problems that password-based systems 
have. Each component must be in its proper place before the identity can be used. 
The first component, the public key, must be registered to the Secure Shell server. 
The second component, the encrypted private key (the first factor), must be possessed 
by the user. The third component, the passphrase to decrypt the private key (the 
second factor), must be known to the user.</p>

<p>The drawbacks of identities are increased maintenance costs and lack of scalability. 
If users forget their passphrases, the private keys cannot be recovered. A new identity 
will need to be generated and registered. On systems that allow only key-based authentication, 
the system administration staff will have to register identities on the users&#39; behalf. 
The public key must be safely registered in a manner that cannot be tampered with 
in transit (for example, verifying a MD5 key fingerprint over the phone).</p>

<p>The identity system in OpenSSH and the Solaris Secure Shell software does not 
scale. The server must have file access to the public key to authenticate the identity. 
Every server must have its own copy of the public key, or NFS home directories must 
be used. Currently, there is no support to request public identity keys from some 
other server (for example, an LDAP server).</p>

<p>Caution</p>
<table cellspacing="0" cellpadding="1" width="90%" border="0">
	<tr>
		<td valign="top" width="60"></td>
		<td valign="top">

		<p>With NFS home directories for which the NFS clients have write privileges, 
		any single client can compromise the entire key-based authentication system 
		by creating and registering identities in a user&#39;s home directory. You can 
		reduce this risk in the Secure Shell server configurations by allowing only 
		password authentication.</p>
		</td>
	</tr>
</table>

<p>Revoking an identity can also be problematic because the work required is asymmetrical. 
On the user&#39;s side, the passphrase can be forgotten, and the private key can be 
deleted. On the server&#39;s side, the public key entry must be removed from every
<tt>$HOME/ .ssh/authorized_keys</tt> file. In cases in which the account is a group 
account and the employee is terminated, finding every entry across an enterprise 
can be difficult.</p>

<p>Identities do have their uses. They can be combined with agents (refer to &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch06lev1sec3#ch06lev1sec3">Agents</a>&quot; 
on page 75) to provide secure passphrase-free logins. They also provide a higher 
assurance of security than passwords.</p>

<h4>To Create an Identity</h4>
<table border="0">
	<tr>
		<td valign="top" width="25"><b>1. </b></td>
		<td>Decide on the type and size of identity to create.
<p>
 </td>
	</tr>
	<tr>
		<td valign="top" width="25"><b>2. </b></td>
		<td>Create the identity and enter a passphrase.
<p>
		The following is an example of creating a 1024-bit RSA identity:
<p>

		<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec2#PLID0">[View full width]</a></pre>

		<pre>$ ssh-keygen -t rsa
 Enter file in which to save the key (/home/user/
.ssh/id_rsa):
 Generating public/private rsa key pair.
 Enter passphrase (empty for no passphrase):
 passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh
/id_rsa.pub.
 The key fingerprint is:
 md5 1024 f9:42:d4:0a:af:23:26:22:14:23:4a:8c:22
:14:6f:f7 user@host
</pre>

		<p><br>
 </p>
		</td>
	</tr>
</table>

<h4>To Register an Identity</h4>
<table border="0">
	<tr>
		<td valign="top" width="25"><b>1. </b></td>
		<td>Copy the public key, file <tt>.pub</tt>, to the remote Secure Shell 
		server.
<p>
 </td>
	</tr>
	<tr>
		<td valign="top" width="25"><b>2. </b></td>
		<td>Create the <tt>$HOME/.ssh</tt> directory with mode <tt>go-w</tt> if 
		it does not exist.
<p>
 </td>
	</tr>
	<tr>
		<td valign="top" width="25"><b>3. </b></td>
		<td>Create the <tt>$HOME/.ssh/authorized_keys</tt> file with mode <tt>go-w</tt> 
		if it does not exist.
<p>
 </td>
	</tr>
	<tr>
		<td valign="top" width="25"><b>4. </b></td>
		<td>Add the public key to <tt>$HOME/.ssh/authorized_keys.</tt>
<p>
 </td>
	</tr>
</table>

<h4>To Revoke an Identity</h4>
<table border="0">
	<tr>
		<td valign="top" width="25"><b>1. </b></td>
		<td>On the Secure Shell server, remove the public key entry from the <tt>
		$HOME/.ssh/authorized_keys</tt> file.
<p>
 </td>
	</tr>
	<tr>
		<td valign="top" width="25"><b>2. </b></td>
		<td>On the client, remove the private key.<br>
 </td>
	</tr>
</table>

<h3>Agents</h3>

<p>A Secure Shell agent performs identity cryptographic operations on behalf of 
a client. Whenever a client needs to perform an operation involving a private identity 
key, the request is passed to the agent. The agent computes the result and passes 
it back to the client. The client never sees the actual key. This process requires 
that the agent have the key loaded. Agents allow for passphrase-free logins without 
the risk of unencrypted identities, as in the following example.</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID0">[View full width]</a></pre>

<pre>$ ssh morgan
 Last login: Fri Jan 17 14:52:44 2003 from drake
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 morgan $
</pre>

<p>Agents work by communicating over a private UNIX socket. This socket is stored 
in a user-owned, mode <tt>700</tt> directory in the <tt>/tmp</tt> directory. The 
naming scheme for the socket is <tt>agent.</tt> PID_of_the_ssh-agent. A Secure Shell 
client determines agent usage by the presence of the <tt>SSH_AUTH_SOCK</tt> and
<tt>SSH_AGENT_PID</tt> environment variables. If the variables are present, an attempt 
is made to communicate with the specified agent. If the agent does not respond or 
have a valid identity, the client prompts the user for authentication.</p>

<p>When an agent is started with the <tt>ssh-agent</tt>(1) command, Bourne shell 
commands are output that enable Secure Shell clients to communicate with the agent. 
Using the <tt>-c</tt> option, C shell commands can alternatively be output. Using 
the <tt>eval</tt>(1) built-in shell function, the output can be executed within 
the current shell by setting the needed environment variables, immediately enabling 
agent support to the shell and its future children.</p>

<p>The following is an example of starting an agent:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID1">[View full width]</a></pre>

<pre>$ ssh-agent
 SSH_AUTH_SOCK=/tmp/ssh-kxo27123/agent.27123;
 export SSH_AUTH_SOCK;
 SSH_AGENT_PID=27124; export SSH_AGENT_PID;
 echo Agent pid 27124;
</pre>

<p>The following is an example of starting an agent within the shell:</p>

<pre> $ eval &#39;ssh-agent&#39;
 Agent pid 16867
</pre>

<p>A newly invoked agent has no identities loaded. A separate command, <tt>ssh-add</tt>(1), 
controls the listing, loading, and deleting of identities. The default is to load 
all of the various identity types (<tt>identity</tt> for Protocol 1 only, <tt>id_dsa</tt>, 
and <tt>id_rsa</tt>) serially if they are present. A specific identity can be loaded 
by specifying it on the command line.</p>

<p>The following is an example of listing an empty agent:</p>

<pre> $ ssh-add -1
 The agent has no identities.
</pre>

<p>The following is an example of listing an agent with one RSA key:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID4">[View full width]</a></pre>

<pre>$ ssh-add -1
 md5 1024 13:cd:f7:19:87:4c:8e:5d:6c:c2:cc:51:07
:af:d2:21
 /home/user/.ssh/id_rsa(RSA)
</pre>

<p>The following is an example of adding all identities in the <tt>$HOME/.ssh</tt> 
file:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID5">[View full width]</a></pre>

<pre>$ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa (/home
/user/.ssh/id_rsa)
 Enter passphrase for /home/user/.ssh/id_dsa:
 passphrase
 Identity added: /home/user/.ssh/id_dsa(/home/user
/.ssh/id_dsa)
</pre>

<p>The following is an example of adding a specific identity:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID6">[View full width]</a></pre>

<pre>$ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)
</pre>

<h4>Common Desktop Environment Support</h4>

<p>The Common Desktop Environment (CDE) can have integrated agent support. A single 
agent can be started that will serve all of the child, <tt>dtterm</tt>(1) and
<tt>xterm</tt>(1), terminal windows. Only one agent needs to be started for each 
user on the system. Agent support is added by customizing the <tt>$HOME/.dtprofile</tt> 
file. The changes take effect on the next session.</p>

<p>The <tt>ssh-add</tt>(1) command by itself cannot prompt for passphrases at the 
beginning of a CDE session. An X-based passphrase requestor is needed. The <tt>ssh-add</tt>(1) 
command can use an external passphrase requestor if the <tt>SSH_ASKPASS</tt> and<tt> 
DISPLAY</tt> environment variables are set. The <tt>SSH_ASKPASS</tt> variable must 
be set to the proper requestor <tt>$PATH.</tt> Jim Knoble has written <tt>x11-ssh-askpass</tt>, 
which works well for this purpose. It is available at:</p>

<p><a target="_blank" href="http://www.jmknoble.net/software/x11-ssh-askpass/" target="_blank">http://www.jmknoble.net/software/x11-ssh-askpass/</a></p>

<p>An X-based passphrase requestor is not required to use agents with CDE. Using 
both the agent and the requestor, a limited form of single sign-on can be constructed. 
After a user is authenticated to the system for his or her CDE session and the passphrase 
is authenticated, that user can access any system that honors that identity without 
needing an additional user-visible authentication (that is, a separate password). 
(This is for Secure Shell logins and file transfers only.)</p>

<p>The following is an example of agent support for CDE in the <tt>$HOME/.dtprofile</tt> 
file:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID7">[View full width]</a></pre>

<pre># Start an agent for the session.
 # Use Solaris Secure Shell if available;
 otherwise, use OpenSSH.
 if [ -x /usr/bin/ssh-agent ]; then
      eval &#39;/usr/bin/ssh-agent&#39;
      solarisoe=1;
 elif [ -x /opt/OBSDssh/bin/ssh-agent ]; then
      eval &#39;/opt/OBSDssh/bin/ssh-agent&#39;
      solarisoe=0;
 fi
 # Only add keys if x11-ssh-askpass is available.
 if [ -x /usr/local/libexec/x11-ssh-askpass ]; then
      SSH_ASKPASS=/usr/local/libexec
/x11-ssh-askpass ; export SSH_ASKPASS
 elif [ -x /opt/OBSDssh/libexec/x11-ssh-askpass ];
 then
      SSH_ASKPASS=/opt/OBSD/ssh/libexec
/x11-ssh-askpass ; export SSH_ASKPASS
 fi
 if [ ! -z &quot;$SSH_ASKPASS&quot; ]; then
      if [ $solarisoe -eq 1 ]; then
           /usr/bin/ssh-add
      else
           /opt/OBSD/ssh/bin/ssh-add
      fi
fi
</pre>

<h4>Removing Agents</h4>

<p>When an agent is no longer needed, it should either be terminated, or the identities 
should be deleted from memory. If you are going to be away from the keyboard for 
a while, you should delete the identities. An agent is terminated by calling the
<tt>ssh-agent</tt>(1) command with the <tt>-k</tt> option. Simply logging out will 
not terminate an agent. If a user automatically starts an agent with each login, 
the agents will accumulate until they are terminated with the <tt>-k</tt> option, 
the <tt>kill</tt>(1) command, or a system reboot.</p>

<p>The following is an example of unloading identities:</p>

<pre> $ ssh-add -D
 All identities removed.
</pre>

<p>The following example shows how to unset the two environment variables. Use
<tt>eval</tt>(1) to cause this code to be executed within your current shell:</p>

<pre> $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;
</pre>

<p>If agents were started automatically at the beginning of a CDE session, they 
must be terminated to prevent agent processes from building up on the system. Place 
the needed code in the <tt>$HOME/.dt/sessions/sessionexit</tt> file to terminate 
an agent at logout. See<tt> dtsession</tt>(1X) for more details.</p>

<p>The following is an example of the <tt>$HOME/.dt/sessions/sessionexit</tt> file:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID10">[View full width]</a></pre>

<pre>#!/usr/bin/ksh
 # Eliminate the agent for the session
 if [ -x /usr/bin/ssh-agent ]; then
 if  /usr/bin/ssh-add -D &gt;/dev/null 2&gt;&amp;1; then
        eval &#39;/usr/bin/ssh-agent -k&#39;
 fi
 else if [ -x /opt/OBSDssh/bin/ssh-agent ]; then
 if /opt/OBSDssh/bin/ssh-agent -D &gt;/dev/null 2&gt;&amp;1;
 then
                 eval &#39;/opt/OBSDssh/bin/ssh-agent -k&#39;
 fi
         fi
 fi
</pre>

<h4>Agent Risks</h4>

<p>Agents are not without their risks. The only access control to the agent socket 
is the private user-owned directory in the <tt>/tmp</tt> directory. Another user 
instance or the superuser could easily communicate with the agent and gain access 
to remote hosts. Additionally, the private identity keys are held in memory by the 
agent. Access to the memory by the superuser, a system debugger, or another instance 
of the same user could result in an identity compromise by reading the unencrypted 
private key.</p>

<p>The following is an example of a user agent compromise by the superuser:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID11">[View full width]</a></pre>

<pre># ls -l /tmp/ssh-gsN27129
 total 0
 srwxr-xr-x l user staff             0 Jan 25 16
:19 agent.27129
 # SSH_AUTH_SOCK=/tmp/ssh-gsN27129/agent.27129;
 export SSH_AUTH_SOCK 
 # SSH_AGENT_PID=27130; export SSH_AGENT_PID 
 # ssh-add -l
 md5 1024 bd:bc:2b:4f:5c:ee:14:b3:cd:28:e2:8b:dc
:af:13:4f
 /home/user/.ssh/id_rsa(RSA)
</pre>

<p>Agent forwarding mitigates some of the risks. With agent forwarding, the agent 
runs on a trusted machine, such as a personal laptop. The information needed to 
access the agent is passed through the Secure Shell tunnel throughout the connection 
chain. The intermediary Secure Shell daemons act as proxy agents. This limits the 
existence of the private identity key to the trusted machine. The intermediary machines 
need only a copy of the public identity key.</p>

<p>The following is an example of a simple agent forwarding session:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/ch06lev1sec3#PLID12">[View full width]</a></pre>

<pre>hook $ eval &#39;/usr/bin/ssh-agent&#39;
 Agent pid 602
 hook $ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa(/home/user
/.ssh/id_rsa)
 hook $ cat $HOME/.ssh/config
 Host *
         ForwardAgent yes
 hook $ ssh blood
 Last login: Mon Jan 27 21:29:10 2003 from hook
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 blood $ ssh calicojack
 Last login: Mon Jan 27 21:29:41 2003 from blood
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 calicojack $ ^D
</pre>

<p>In this example, the user starts on<tt> hook</tt>. An agent is started, and one 
key is loaded. The user then logs in to <tt>blood</tt>, then to <tt>calicojack.</tt> 
Notice that <tt>calicojack</tt> did not prompt for authentication. The user&#39;s private 
key never left<tt> hook</tt> because <tt>blood</tt> was not trusted with the private 
identity (key)</p>

<h2>Appendix A. Secure Shell Usage</h2>

<p>This appendix is a basic guide to Secure Shell usage. For more information, refer 
to the Solaris 9 System Administration Guide: Security Services book at
<a target="_blank" href="http://docs.sun.com" target="_blank">docs.sun.com</a> and the following 
man pages:</p>

<ul>

	<li>

	<p><tt>scp</tt>(1)</p>
	</li>

	<li>

	<p><tt>sftp</tt>(1)</p>
	</li>

	<li>

	<p><tt>sftp-server</tt>(1M)</p>
	</li>

	<li>

	<p><tt>ssh</tt>(1)</p>
	</li>

	<li>

	<p><tt>sshd</tt>(1M)</p>
	</li>

	<li>

	<p><tt>ssh-add</tt>(1)</p>
	</li>

	<li>

	<p><tt>ssh-agent</tt>(1)</p>
	</li>

	<li>

	<p><tt>ssh-keygen</tt>(1)</p>
	</li>

	<li>

	<p><tt>ssh_config</tt>(4)</p>
	</li>

	<li>

	<p><tt>sshd_config</tt>(4)</p>
	</li>
</ul>

<h3>Client Usage</h3>

<p>This section covers the client-side usage of Secure Shell. The basics of remote 
host connections and job executions, along with file transfers, are covered. The 
more advanced client usage of identities, agents, port and X forwarding, and proxies 
are also covered. Examples are used to demonstrate the various features. This is 
meant to be a brief introduction, not an in-depth guide.</p>

<h4>Connecting to a Host</h4>

<p>The following example shows the basic syntax of the <tt>ssh</tt>(1) command:</p>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec1#PLID0">[View full width]</a></pre>

<pre>$ ssh remote
 user@remote&#39;s password: password
 Last login: Wed Dec 18 00:12:38 2002 from someplace
 Sun Microsystems Inc.    SunOS 5.9       Generic
 May 2002
 remote $</pre>

</td>
</tr>
<tr>
<td valign="top" align="left"></td>
</tr>
</table>

<h4>Executing a Command on a Remote Host</h4>

<p>The <tt>ssh</tt>(1) command&#39;s remote job form is <tt>ssh </tt>remote_host job, 
as shown in the following example:</p>

<p>Note</p>

<p>Shell variables are expanded on the local side, unless they are escaped.</p>

<pre> $ ssh remote cat /var/sadm/system/admin/CLUSTER
 user@remote&#39;s password: password
 CLUSTER=SUNWCXall
</pre>

<h4>Copying a File</h4>

<p>The <tt>scp</tt>(1) command&#39;s form is <tt>scp </tt>source destination. The following 
example demonstrates how to copy a local file to a remote host:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec1#PLID2">[View full width]</a></pre>

<pre>$ scp 816-5241.pdf remote:/tmp
 user@remote&#39;s password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00
</pre>

<p>The following example demonstrates how to copy a file from a remote host to a 
local host:</p>

<pre>$ scp remote:/tmp/816-5241.pdf /tmp
 user@remote&#39;s password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00
</pre>

<h4>Using Identity Keys</h4>

<p>This section contains examples of generating, registering, and using user identities. 
Agents for passphrase-free logins are also covered.</p>
<h5>Generating an Identity</h5>

<p>Note</p>

<p>OpenSSH has no default key type. The key type must be specified. The Solaris 
Secure Shell software defaults to Protocol 2 RSA keys.</p>

<p>The following example shows how to generate Protocol 2 RSA keys:</p>

<pre>$ ssh-keygen -t rsa
 Enter file in which to save the key(/home/user/
.ssh/id_rsa):
 Generating public/private rsa key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh
/id_rsa.pub.
 The key fingerprint is:
 md5 1024 f9:42:d4:0a:af:23:26:22:14:23:4a:8c:22
:14:6f:f7 user@host
</pre>

<p>The following example shows how to generate a 2048-bit DSA key:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec1#PLID5">[View full width]</a></pre>

<pre>$ ssh-keygen -t dsa -b 2048
 Enter file in which to save the key(/home/user/
.ssh/id_dsa):
 Generating public/private dsa key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/id_dsa.
 Your public key has been saved in /home/user/.ssh
/id_dsa.pub.
 The key fingerprint is:
 md5 2048 3c:dd:5a:8a:37:60:89:ff:ef:4a:bb:b5:bf
:37:d5:78 user@host
</pre>

<p>The following example shows how to generate a Secure Shell Protocol 1 RSA key:</p>

<pre>$ ssh-keygen -t rsa1
 Enter file in which to save the key(/home/user/
.ssh/identity):
 Generating public/private rsa1 key pair.
 Enter passphrase(empty for no passphrase): passphrase
 Enter same passphrase again: passphrase
 Your identification has been saved in /home/user/
.ssh/identity.
 Your public key has been saved in /home/user/.ssh
/identity.pub.
 The key fingerprint is:
 md5 1024 de:30:33:84:45:1d:5d:f5:e7:84:30:58:be
:b5:28:44 user@host
</pre>

<h5>Registering an Identity</h5>

<p>Install the generated public key into the <tt>authorized_keys</tt> file on the 
destination host, as in the following example. The private key is installed on the 
originating host of the connection.</p>

<pre> $ cd ~/.ssh
 $ touch authorized_keys
 $ chmod 744 authorized_keys
 $ cat id_rsa.pub &gt;&gt; authorized_keys
</pre>

<h5>Using the Identity</h5>

<p>The following example shows how to use the key:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec1#PLID8">[View full width]</a></pre>

<pre>$ ssh remote
 Enter passphrase for key &#39;/home/user/.ssh/id_rsa&#39;
: passphrase
 Last login: Thu Dec 19 16:48:43 2002 from server
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 remote $
</pre>

<h4>Using Agents</h4>

<p>This section contains examples of how to set up agents, use agent keys, and stop 
the agent. The following commands are used:</p>

<ul>

	<li>

	<p><tt>ssh-agent</tt>(1)</p>
	</li>

	<li>

	<p><tt>ssh-add</tt>(1)</p>
	</li>
</ul>
<h5>Setting Up Agents</h5>

<p>The following example shows how to set up an agent within the parent shell:</p>

<pre> $ eval `ssh-agent`
 Agent pid 16867
 $
</pre>

<h5>Loading Agents</h5>

<p>The following example shows the default behavior when loading all of the identities 
that are present in the <tt>$HOME/.ssh</tt> directory:</p>

<pre>$ ssh-add
 Enter passphrase for /home/user/.ssh/id_rsa:
 passphrase
 Identity added: /home/user/.ssh/id_rsa(/home/user
/.ssh/id_rsa)
 Enter passphrase for /home/user/.ssh/id_dsa:
 passphrase
 Identity added: /home/user/.ssh/id_dsa(/home/user
/.ssh/id_dsa)
</pre>

<p>The following example shows how to add a specific identity:</p>

<pre> $ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)
</pre>

<h5>Listing Agent Identities</h5>

<p>The command for listing agent identities is the same, no matter how many identities 
have been loaded-only the output changes.</p>

<p>The following example shows the output for listing an empty agent:</p>

<pre> $ ssh-add -l
 The agent has no identities.
</pre>

<p>The following example shows the output for listing an agent with one identity 
loaded:</p>

<pre>$ ssh-add -l
 md5 1024 13:cd:f7:19:87:4c:8e:5d:6c:c2:cc:51:07
:af:d2:21
 /home/user/.ssh/id_rsa(RSA)
</pre>

<h5>Removing Agent Identities</h5>

<p>The following example shows how to unload a specific identity:</p>

<pre> $ ssh-add -d id_rsa
 Identity removed: id_rsa(id_rsa.pub)
</pre>

<p>The following example shows how to unload all of the identities in an agent:</p>

<pre> $ ssh-add -D
 All identities removed.
</pre>

<h5>Stopping the Agent</h5>

<p>The following example shows how to stop an agent. Use <tt>eval</tt>(1) to unset 
the two shell variables.</p>

<pre> $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;
</pre>

<h4>Forwarding Ports</h4>

<p>Note</p>

<p>The Solaris Secure Shell software defaults to having port forwarding disabled 
on the server.</p>

<p>The following example shows a local forward failing because port forwarding is 
disabled on the server:</p>

<pre> $ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is &#39;^]&#39;.
 Connection to localhost closed by foreign host.
</pre>

<h5>Setting Up Local Forwarding</h5>

<p>The form for local forwarding is <tt>ssh -L</tt> local_port:destination_host:destination_port 
host. The destination host for the forwarded port does not need to be the same as 
port on the Secure Shell server. The following example shows the forwarding of the 
local host port, 2020, to the remote host&#39;s port, 23 (Telnet):</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec1#PLID18">[View full width]</a></pre>

<pre>$ ssh -L 2020:remote:23 remote
 Enter passphrase for key &#39;/home/beth/.ssh/id_rsa&#39;
: passphrase
 Last login: Thu Dec 19 20:12:14 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote $
</pre>

<p>The following example shows how to test the forwarded port:</p>

<pre>$ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is &#39;^]&#39;. 


 SunOS 5.9
 login: name Password: password
 Last login: Thu Dec 19 20:14:05 from server
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 remote $
</pre>

<h5>Setting Up Remote Forwarding</h5>

<p>The form for remote forwarding <tt>ssh -R</tt> server_port:destination_host:destination_port 
server. The destination host does not have to be the Secure Shell server. It is 
often the originating host. The following example shows the forwarding of the server&#39;s 
port, 2020, to port 23 (Telnet):</p>

<pre>$ ssh -R 2020:remote:23 remote
 Enter passphrase for key &#39;/home/user/.ssh/id_rsa&#39;
: passphrase
 Last login: Thu Dec 19 20:34:25 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote /home/user $ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is &#39;^]&#39;.
 login: user
 Password: password
 Last login: Tue Dec 17 21:16:25 from remote
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 server $
</pre>

<h5>Enabling X Forwarding</h5>

<p>Note</p>

<p>The Solaris Secure Shell software defaults to having X forwarding disabled on 
the server.</p>

<p>The following example shows how to enable X forwarding by adding the following 
lines to the <tt>~/.ssh/config</tt> file:</p>

<pre> ForwardX11 yes
 XAuthLocation /usr/X/bin/xauth
</pre>

<p>The following example shows how to enable X forwarding by using the -X option:</p>

<pre> $ ssh -X host
</pre>

<h4>Checking the $DISPLAY Variable</h4>

<p>The following example shows how to check the <tt>$DISPLAY</tt> variable:</p>

<pre>$ echo $DISPLAY
 :0.0
 $ ssh remote
 Enter passphrase for key &#39;/home/user/.ssh/id_rsa&#39;
: passphrase
 Last login: Thu Dec 19 19:42:30 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote $ echo $DISPLAY
 remote:10.0
</pre>

<h4>Using Proxies</h4>

<p>Note</p>

<p>The <tt>ssh-http-proxy-connect</tt>(1) command and the <tt>ssh-socks5-proxy-connect</tt>(1) 
command are available only in the Solaris Secure Shell software.</p>

<p>The following example shows how to use a proxy:</p>

<pre>$ ssh -o&#39;ProxyCommand=/usr/lib/ssh
/ssh-socks5-proxy-connect \


 -h socks-gw -p 1080 dmz.foo.com 22&#39; dmz.foo.com
 user@dmz&#39;s password: password
 Last login: Thu Dec 10 23:03:04 2002 from foo.bar.com
 Sun Microsystems Inc.  SunOS 5.8       Generic
 May 2001
 $
</pre>

<h4>Locating Client Configuration Files</h4>

<p>The individual client configuration file and keys are kept in the <tt>.ssh</tt> 
directory in the user&#39;s home directory. The global client configuration file,
<tt>ssh_config</tt>, resides with the other server configuration files and keys.</p>

<p>The following example shows the contents of the <tt>~/.ssh</tt> directory:</p>

<pre>/home/user/.ssh $ ls -al
 total 48
 drwxr-xr-x   2 user staff        512 Dec 10 10:27 .
 drwxr-xr-x  26 user other       2560 Dec 18 10:32 ..
 -rw-r--r--   1 user staff       225 Dec 10 10:27
 authorized_keys
 -rw-r--r--   1 user staff        995 Dec 14 17:06
 config
 -rw-------   1 user staff        951 Dec 10 10:26
 id_rsa
 -rw-r--r--   1 user staff        225 Dec 10 10:26
 id_rsa.pub
 -rw-r--r--   1 user staff       2325 Dec 18 12:51
 known_hosts
</pre>

<p><br>
<a href="sshd_configuration.shtml?x=1&mode=section&sortKey=title&sortOrder=asc&view=&xmlid=0131429000/19991535&g=&catid=&s=1&b=1&f=1&t=1&c=1&u=1&r=&o=1&n=1&d=1&p=1&a=0">
</a></p>

<h3>Server Usage</h3>

<p>This section covers the server-side usage of Secure Shell. The basics of starting 
and stopping the daemon, regenerating host keys, and using TCP Wrappers support 
are covered. Examples are used to demonstrate the various features. This is meant 
to be a brief introduction, not an in-depth guide.</p>

<h4>Starting the Server</h4>

<p>The following example shows how to start the Solaris Secure Shell daemon:</p>

<pre> # /etc/init.d/sshd start
</pre>

<p>The following example shows how to start OpenSSH:</p>

<pre> # /etc/init.d/openssh.server start
</pre>

<h4>Stopping the Server</h4>

<p>The following example shows how to stop the Solaris Secure Shell daemon:</p>

<pre># /etc/init.d/sshd stop
</pre>

<p>The following example shows how to stop OpenSSH:</p>

<pre> # /etc/init.d/openssh.server stop
</pre>

<h4>Generating New Server Host Keys</h4>

<p>Generating new server host keys is a three-step process. First, the Secure Shell 
server must be stopped. Second, the existing keys must be deleted. Third, the Secure 
Shell server must be restarted, as in the following example:</p>

<pre> # /etc/init.d/sshd stop
 # cd config_directory
 # rm ssh_host*
 # /etc/init.d/sshd start
</pre>

<p>Note</p>

<p>Generating new server host keys will cause clients with the existing hosts key 
to display an error message when connecting to the host. The message will persist 
until the clients are updated with the new host key.</p>

<h4>Supporting TCP Wrappers</h4>

<p>See <tt>hosts_access</tt>(4) for details on the format for the <tt>/etc/hosts.allow</tt> 
and <tt>/etc/hosts.deny</tt> files.</p>

<p>Note</p>

<p>TCP Wrappers support is optional in OpenSSH. See &quot;<a href="sshd_configuration.shtml?xmlid=0131429000/ch02lev1sec4#ch02lev1sec4">TCP 
Wrappers</a>&quot; on page 33 for instructions on its inclusion.</p>

<p>The following example shows how to allow only local network hosts access by setting 
up the <tt>hosts.deny</tt> and <tt>hosts.allow</tt> files:</p>

<pre> # echo &quot;sshd: ALL&quot; &gt;&gt; /etc/hosts.deny
 # echo &quot;sshd: LOCAL&quot; &gt;&gt; /etc/hosts.allow
</pre>

<p>This example shows how to test local access:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec2#PLID8">[View full width]</a></pre>

<pre>$ ssh server
 user@server&#39;s password: password
 Last login: Tue Dec 17 21:15:07 2002 from some.place
 Sun Microsystems Inc.     SunOS 5.8       Generic
 Patch   October 2001
 server /home/user $ ^D
 Connection to server closed.
</pre>

<p>This example shows how to test remote access by attempting a connection from 
a remote host outside of the server&#39;s local domain:</p>

<pre> </pre>

<pre><a target="_blank" href="http://safari.oreilly.com/&r=noccc&xmlid=0131429000/app01lev1sec2#PLID9">[View full width]</a></pre>

<pre>$ ssh server.remote
 ssh_exchange_identification: Connection closed by
 remote host
</pre>

<p>Reference</p>

<p>SSHD_CONFIG(5)            
OpenBSD Programmer&#39;s Manual           
SSHD_CONFIG(5)
<p>
<a name="NAME" href="#end"><b>NAME</b></a><br>
     <b>sshd</b><i>_</i><b>config</b> - OpenSSH SSH daemon configuration 
file
<p>
<a name="SYNOPSIS" href="#end"><b>SYNOPSIS</b></a><br>
     <b>/etc/ssh/sshd</b><i>_</i><b>config</b>
<p>
<a name="DESCRIPTION" href="#end"><b>DESCRIPTION</b></a><br>
    
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> reads configuration data from <i>/etc/ssh/sshd_config</i> (or the file<br>
     specified with <b>-f</b> on the command line).  The 
file contains keyword-argu-<br>
     ment pairs, one per line.  Lines starting with `#&#39; 
and empty lines are<br>
     interpreted as comments.  Arguments may optionally 
be enclosed in double<br>
     quotes (&quot;) in order to represent arguments containing spaces.
<p>
     The possible keywords and their meanings are as follows 
(note that key-<br>
     words are case-insensitive and arguments are case-sensitive):
<p>
     <b>AcceptEnv</b><br>
             Specifies 
what environment variables sent by the client will be<br>
             copied 
into the session&#39;s
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=environ&sektion=7&arch=&apropos=0&manpath=OpenBSD+Current">
environ(7)</a>.  See <b>SendEnv</b> in<br>
            
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a> for how to configure the client.  Note that envi-<br>
             ronment 
passing is only supported for protocol 2.  Variables are<br>
             specified 
by name, which may contain the wildcard characters `*&#39;<br>
             and `?&#39;.  
Multiple environment variables may be separated by<br>
             whitespace 
or spread across multiple <b>AcceptEnv</b> directives.  Be<br>
             warned 
that some environment variables could be used to bypass<br>
             restricted 
user environments.  For this reason, care should be<br>
             taken in 
the use of this directive.  The default is not to accept<br>
             any environment 
variables.
<p>
     <b>AddressFamily</b><br>
             Specifies 
which address family should be used by
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>.  Valid<br>
             arguments 
are ``any&#39;&#39;, ``inet&#39;&#39; (use IPv4 only), or ``inet6&#39;&#39;<br>
             (use IPv6 
only).  The default is ``any&#39;&#39;.
<p>
     <b>AllowGroups</b><br>
             This keyword 
can be followed by a list of group name patterns,<br>
             separated 
by spaces.  If specified, login is allowed only for<br>
             users whose 
primary group or supplementary group list matches one<br>
             of the 
patterns.  Only group names are valid; a numerical group<br>
             ID is not 
recognized.  By default, login is allowed for all<br>
             groups.  
The allow/deny directives are processed in the following<br>
             order:
<b>DenyUsers</b>, <b>AllowUsers</b>, <b>DenyGroups</b>, and finally<br>
             <b>AllowGroups</b>.
<p>
             See <i>
PATTERNS</i> in
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a> for more information on patterns.
<p>
     <b>AllowTcpForwarding</b><br>
             Specifies 
whether TCP forwarding is permitted.  The default is<br>
             ``yes&#39;&#39;.  
Note that disabling TCP forwarding does not improve se-<br>
             curity 
unless users are also denied shell access, as they can al-<br>
             ways install 
their own forwarders.
<p>
     <b>AllowUsers</b><br>
             This keyword 
can be followed by a list of user name patterns,<br>
             separated 
by spaces.  If specified, login is allowed only for us-<br>
             er names 
that match one of the patterns.  Only user names are<br>
             valid; 
a numerical user ID is not recognized.  By default, login<br>
             is allowed 
for all users.  If the pattern takes the form US-<br>
             ER@HOST 
then USER and HOST are separately checked, restricting<br>
             logins 
to particular users from particular hosts.  The allow/deny<br>
             directives 
are processed in the following order: <b>DenyUsers</b>,<br>
             <b>AllowUsers</b>,
<b>DenyGroups</b>, and finally <b>AllowGroups</b>.
<p>
             See <i>
PATTERNS</i> in
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a> for more information on patterns.
<p>
     <b>AuthorizedKeysFile</b><br>
             Specifies 
the file that contains the public keys that can be used<br>
             for user 
authentication.  <b>AuthorizedKeysFile</b> may contain tokens<br>
             of the 
form %T which are substituted during connection setup.<br>
             The following 
tokens are defined: %% is replaced by a literal<br>
             &#39;%&#39;, %h 
is replaced by the home directory of the user being au-<br>
             thenticated, 
and %u is replaced by the username of that user.<br>
             After expansion,
<b>AuthorizedKeysFile</b> is taken to be an absolute<br>
             path or 
one relative to the user&#39;s home directory.  The default<br>
             is ``.ssh/authorized_keys&#39;&#39;.
<p>
     <b>Banner</b>  The contents of the specified file 
are sent to the remote user<br>
             before 
authentication is allowed.  If the argument is ``none&#39;&#39;<br>
             then no 
banner is displayed.  This option is only available for<br>
             protocol 
version 2.  By default, no banner is displayed.
<p>
     <b>ChallengeResponseAuthentication</b><br>
             Specifies 
whether challenge-response authentication is allowed.<br>
             All authentication 
styles from
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
login.conf(5)</a> are supported.  The<br>
             default 
is ``yes&#39;&#39;.
<p>
     <b>Ciphers</b><br>
             Specifies 
the ciphers allowed for protocol version 2.  Multiple<br>
             ciphers 
must be comma-separated.  The supported ciphers are<br>
             ``3des-cbc&#39;&#39;, 
``aes128-cbc&#39;&#39;, ``aes192-cbc&#39;&#39;, ``aes256-cbc&#39;&#39;,<br>
             ``aes128-ctr&#39;&#39;, 
``aes192-ctr&#39;&#39;, ``aes256-ctr&#39;&#39;, ``arcfour128&#39;&#39;,<br>
             ``arcfour256&#39;&#39;, 
``arcfour&#39;&#39;, ``blowfish-cbc&#39;&#39;, and<br>
             ``cast128-cbc&#39;&#39;.  
The default is:
<p>
                
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,<br>
                
arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,<br>
                
aes192-ctr,aes256-ctr
<p>
     <b>ClientAliveCountMax</b><br>
             Sets the 
number of client alive messages (see below) which may be<br>
             sent without
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> receiving any messages back from the client.<br>
             If this 
threshold is reached while client alive messages are be-<br>
             ing sent, 
sshd will disconnect the client, terminating the ses-<br>
             sion.  
It is important to note that the use of client alive mes-<br>
             sages is 
very different from <b>TCPKeepAlive</b> (below).  The client<br>
             alive messages 
are sent through the encrypted channel and there-<br>
             fore will 
not be spoofable.  The TCP keepalive option enabled by<br>
             <b>TCPKeepAlive</b> 
is spoofable.  The client alive mechanism is valu-<br>
             able when 
the client or server depend on knowing when a connec-<br>
             tion has 
become inactive.
<p>
             The default 
value is 3.  If <b>ClientAliveInterval</b> (see below) is<br>
             set to 
15, and <b>ClientAliveCountMax</b> is left at the default, unre-<br>
             sponsive 
SSH clients will be disconnected after approximately 45<br>
             seconds.  
This option applies to protocol version 2 only.
<p>
     <b>ClientAliveInterval</b><br>
             Sets a 
timeout interval in seconds after which if no data has<br>
             been received 
from the client,
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> will send a message<br>
             through 
the encrypted channel to request a response from the<br>
             client.  
The default is 0, indicating that these messages will<br>
             not be 
sent to the client.  This option applies to protocol ver-<br>
             sion 2 
only.
<p>
     <b>Compression</b><br>
             Specifies 
whether compression is allowed, or delayed until the<br>
             user has 
authenticated successfully.  The argument must be<br>
             ``yes&#39;&#39;, 
``delayed&#39;&#39;, or ``no&#39;&#39;.  The default is ``delayed&#39;&#39;.
<p>
     <b>DenyGroups</b><br>
             This keyword 
can be followed by a list of group name patterns,<br>
             separated 
by spaces.  Login is disallowed for users whose primary<br>
             group or 
supplementary group list matches one of the patterns.<br>
             Only group 
names are valid; a numerical group ID is not recog-<br>
             nized.  
By default, login is allowed for all groups.  The al-<br>
             low/deny 
directives are processed in the following order:<br>
             <b>DenyUsers</b>,
<b>AllowUsers</b>, <b>DenyGroups</b>, and finally <b>AllowGroups</b>.
<p>
             See <i>
PATTERNS</i> in
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a> for more information on patterns.
<p>
     <b>DenyUsers</b><br>
             This keyword 
can be followed by a list of user name patterns,<br>
             separated 
by spaces.  Login is disallowed for user names that<br>
             match one 
of the patterns.  Only user names are valid; a numeri-<br>
             cal user 
ID is not recognized.  By default, login is allowed for<br>
             all users.  
If the pattern takes the form USER@HOST then USER and<br>
             HOST are 
separately checked, restricting logins to particular<br>
             users from 
particular hosts.  The allow/deny directives are pro-<br>
             cessed 
in the following order: <b>DenyUsers</b>, <b>AllowUsers</b>, <b>DenyGroups</b>,<br>
             and finally
<b>AllowGroups</b>.
<p>
             See <i>
PATTERNS</i> in
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a> for more information on patterns.
<p>
     <b>ForceCommand</b><br>
             Forces 
the execution of the command specified by <b>ForceCommand</b>,<br>
             ignoring 
any command supplied by the client.  The command is in-<br>
             voked by 
using the user&#39;s login shell with the -c option.  This<br>
             applies 
to shell, command, or subsystem execution.  It is most<br>
             useful 
inside a <b>Match</b> block.  The command originally supplied by<br>
             the client 
is available in the SSH_ORIGINAL_COMMAND environment<br>
             variable.
<p>
     <b>GatewayPorts</b><br>
             Specifies 
whether remote hosts are allowed to connect to ports<br>
             forwarded 
for the client.  By default,
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> binds remote port<br>
             forwardings 
to the loopback address.  This prevents other remote<br>
             hosts from 
connecting to forwarded ports.  <b>GatewayPorts</b> can be<br>
             used to 
specify that sshd should allow remote port forwardings to<br>
             bind to 
non-loopback addresses, thus allowing other hosts to con-<br>
             nect.  
The argument may be ``no&#39;&#39; to force remote port forward-<br>
             ings to 
be available to the local host only, ``yes&#39;&#39; to force re-<br>
             mote port 
forwardings to bind to the wildcard address, or<br>
             ``clientspecified&#39;&#39; 
to allow the client to select the address to<br>
             which the 
forwarding is bound.  The default is ``no&#39;&#39;.
<p>
     <b>GSSAPIAuthentication</b><br>
             Specifies 
whether user authentication based on GSSAPI is allowed.<br>
             The default 
is ``no&#39;&#39;.  Note that this option applies to protocol<br>
             version 
2 only.
<p>
     <b>GSSAPICleanupCredentials</b><br>
             Specifies 
whether to automatically destroy the user&#39;s credentials<br>
             cache on 
logout.  The default is ``yes&#39;&#39;.  Note that this option<br>
             applies 
to protocol version 2 only.
<p>
     <b>HostbasedAuthentication</b><br>
             Specifies 
whether rhosts or /etc/hosts.equiv authentication to-<br>
             gether 
with successful public key client host authentication is<br>
             allowed 
(host-based authentication).  This option is similar to<br>
             <b>RhostsRSAAuthentication</b> 
and applies to protocol version 2 only.<br>
             The default 
is ``no&#39;&#39;.
<p>
     <b>HostbasedUsesNameFromPacketOnly</b><br>
             Specifies 
whether or not the server will attempt to perform a re-<br>
             verse name 
lookup when matching the name in the <i>~/.shosts</i>,<br>
             <i>~/.rhosts</i>, 
and <i>/etc/hosts.equiv</i> files during<br>
             <b>HostbasedAuthentication</b>.  
A setting of ``yes&#39;&#39; means that
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a><br>
             uses the 
name supplied by the client rather than attempting to<br>
             resolve 
the name from the TCP connection itself.  The default is<br>
             ``no&#39;&#39;.
<p>
     <b>HostKey</b><br>
             Specifies 
a file containing a private host key used by SSH.  The<br>
             default 
is <i>/etc/ssh/ssh_host_key</i> for protocol version 1, and<br>
             <i>/etc/ssh/ssh_host_rsa_key</i> 
and <i>/etc/ssh/ssh_host_dsa_key</i> for pro-<br>
             tocol version 
2.  Note that
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> will refuse to use a file if<br>
             it is group/world-accessible.  
It is possible to have multiple<br>
             host key 
files.  ``rsa1&#39;&#39; keys are used for version 1 and ``dsa&#39;&#39;<br>
             or ``rsa&#39;&#39; 
are used for version 2 of the SSH protocol.
<p>
     <b>IgnoreRhosts</b><br>
             Specifies 
that <i>.rhosts</i> and <i>.shosts</i> files will not be used in<br>
             <b>RhostsRSAAuthentication</b> 
or <b>HostbasedAuthentication</b>.
<p>
             <i>/etc/hosts.equiv</i> 
and <i>/etc/shosts.equiv</i> are still used.  The de-<br>
             fault is 
``yes&#39;&#39;.
<p>
     <b>IgnoreUserKnownHosts</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should ignore the user&#39;s<br>
             <i>~/.ssh/known_hosts</i> 
during <b>RhostsRSAAuthentication</b> or<br>
             <b>HostbasedAuthentication</b>.  
The default is ``no&#39;&#39;.
<p>
     <b>KerberosAuthentication</b><br>
             Specifies 
whether the password provided by the user for<br>
             <b>PasswordAuthentication</b> 
will be validated through the Kerberos<br>
             KDC.  
To use this option, the server needs a Kerberos servtab<br>
             which allows 
the verification of the KDC&#39;s identity.  The default<br>
             is ``no&#39;&#39;.
<p>
     <b>KerberosGetAFSToken</b><br>
             If AFS 
is active and the user has a Kerberos 5 TGT, attempt to<br>
             acquire 
an AFS token before accessing the user&#39;s home directory.<br>
             The default 
is ``no&#39;&#39;.
<p>
     <b>KerberosOrLocalPasswd</b><br>
             If password 
authentication through Kerberos fails then the pass-<br>
             word will 
be validated via any additional local mechanism such as<br>
             <i>/etc/passwd</i>.  
The default is ``yes&#39;&#39;.
<p>
     <b>KerberosTicketCleanup</b><br>
             Specifies 
whether to automatically destroy the user&#39;s ticket<br>
             cache file 
on logout.  The default is ``yes&#39;&#39;.
<p>
     <b>KeyRegenerationInterval</b><br>
             In protocol 
version 1, the ephemeral server key is automatically<br>
             regenerated 
after this many seconds (if it has been used).  The<br>
             purpose 
of regeneration is to prevent decrypting captured ses-<br>
             sions by 
later breaking into the machine and stealing the keys.<br>
             The key 
is never stored anywhere.  If the value is 0, the key is<br>
             never regenerated.  
The default is 3600 (seconds).
<p>
     <b>ListenAddress</b><br>
             Specifies 
the local addresses
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should listen on.  The fol-<br>
             lowing 
forms may be used:
<p>
                  
<b>ListenAddress</b> <i>host</i>|<i>IPv4_addr</i>|<i>IPv6_addr</i><br>
                  
<b>ListenAddress</b> <i>host</i>|<i>IPv4_addr</i>:<i>port</i><br>
                  
<b>ListenAddress</b> [<i>host</i>|<i>IPv6_addr</i>]:<i>port</i>
<p>
             If <i>port</i> 
is not specified, sshd will listen on the address and all<br>
             prior
<b>Port</b> options specified.  The default is to listen on all<br>
             local addresses.  
Multiple <b>ListenAddress</b> options are permitted.<br>
             Additionally, 
any <b>Port</b> options must precede this option for non-<br>
             port qualified 
addresses.
<p>
     <b>LoginGraceTime</b><br>
             The server 
disconnects after this time if the user has not suc-<br>
             cessfully 
logged in.  If the value is 0, there is no time limit.<br>
             The default 
is 120 seconds.
<p>
     <b>LogLevel</b><br>
             Gives the 
verbosity level that is used when logging messages from<br>
            
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>.  The possible values are: QUIET, FATAL, ERROR, INFO,<br>
             VERBOSE, 
DEBUG, DEBUG1, DEBUG2, and DEBUG3.  The default is INFO.<br>
             DEBUG and 
DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify<br>
             higher 
levels of debugging output.  Logging with a DEBUG level<br>
             violates 
the privacy of users and is not recommended.
<p>
     <b>MACs</b>    Specifies the available MAC 
(message authentication code) algo-<br>
             rithms.  
The MAC algorithm is used in protocol version 2 for data<br>
             integrity 
protection.  Multiple algorithms must be comma-separat-<br>
             ed.  
The default is:
<p>
                   
hmac-md5,hmac-sha1,<a href="/cdn-cgi/l/email-protection#d1a4bcb0b2fce7e591bea1b4bfa2a2b9ffb2bebc"><span class="__cf_email__" data-cfemail="d4a1b9b5b7f9e2e094bba4b1baa7a7bcfab7bbb9">[email&#160;protected]</span></a>,<br>
                   
hmac-ripemd160,hmac-sha1-96,hmac-md5-96
<p>
     <b>Match</b>   Introduces a conditional block.  
If all of the criteria on the<br>
             <b>Match</b> 
line are satisfied, the keywords on the following lines<br>
             override 
those set in the global section of the config file, un-<br>
             til either 
another <b>Match</b> line or the end of the file.  The argu-<br>
             ments to
<b>Match</b> are one or more criteria-pattern pairs.  The<br>
             available 
criteria are <b>User</b>, <b>Group</b>, <b>Host</b>, and <b>Address</b>.  Only 
a<br>
             subset 
of keywords may be used on the lines following a <b>Match</b><br>
             keyword.  
Available keywords are <b>AllowTcpForwarding</b>, <b>Banner</b>,<br>
             <b>ForceCommand</b>,
<b>GatewayPorts</b>, <b>GSSApiAuthentication</b>,<br>
             <b>KbdInteractiveAuthentication</b>,
<b>KerberosAuthentication</b>,<br>
             <b>PasswordAuthentication</b>,
<b>PermitOpen</b>, <b>RhostsRSAAuthentication</b>,<br>
             <b>RSAAuthentication</b>,
<b>X11DisplayOffset</b>, <b>X11Forwarding</b>, and<br>
             <b>X11UseLocalHost</b>.
<p>
     <b>MaxAuthTries</b><br>
             Specifies 
the maximum number of authentication attempts permitted<br>
             per connection.  
Once the number of failures reaches half this<br>
             value, 
additional failures are logged.  The default is 6.
<p>
     <b>MaxStartups</b><br>
             Specifies 
the maximum number of concurrent unauthenticated con-<br>
             nections 
to the SSH daemon.  Additional connections will be<br>
             dropped 
until authentication succeeds or the <b>LoginGraceTime</b> ex-<br>
             pires for 
a connection.  The default is 10.
<p>
             Alternatively, 
random early drop can be enabled by specifying the<br>
             three colon 
separated values ``start:rate:full&#39;&#39; (e.g.<br>
             &quot;10:30:60&quot;). 
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> will refuse connection attempts with a<br>
             probability 
of ``rate/100&#39;&#39; (30%) if there are currently<br>
             ``start&#39;&#39; 
(10) unauthenticated connections.  The probability in-<br>
             creases 
linearly and all connection attempts are refused if the<br>
             number 
of unauthenticated connections reaches ``full&#39;&#39; (60).
<p>
     <b>PasswordAuthentication</b><br>
             Specifies 
whether password authentication is allowed.  The de-<br>
             fault is 
``yes&#39;&#39;.
<p>
     <b>PermitEmptyPasswords</b><br>
             When password 
authentication is allowed, it specifies whether the<br>
             server 
allows login to accounts with empty password strings.  The<br>
             default 
is ``no&#39;&#39;.
<p>
     <b>PermitOpen</b><br>
             Specifies 
the destinations to which TCP port forwarding is per-<br>
             mitted.  
The forwarding specification must be one of the follow-<br>
             ing forms:
<p>
                  
<b>PermitOpen</b> <i>host</i>:<i>port</i><br>
                  
<b>PermitOpen</b> <i>IPv4_addr</i>:<i>port</i><br>
                  
<b>PermitOpen</b> <i>[IPv6_addr]</i>:<i>port</i>
<p>
             Multiple 
forwards may be specified by separating them with<br>
             whitespace.  
An argument of ``any&#39;&#39; can be used to remove all re-<br>
             strictions 
and permit any forwarding requests.  By default all<br>
             port forwarding 
requests are permitted.
<p>
     <b>PermitRootLogin</b><br>
             Specifies 
whether root can log in using
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
ssh(1)</a>.  The argument<br>
             must be 
``yes&#39;&#39;, ``without-password&#39;&#39;, ``forced-commands-only&#39;&#39;,<br>
             or ``no&#39;&#39;.  
The default is ``yes&#39;&#39;.
<p>
             If this 
option is set to ``without-password&#39;&#39;, password authenti-<br>
             cation 
is disabled for root.
<p>
             If this 
option is set to ``forced-commands-only&#39;&#39;, root login<br>
             with public 
key authentication will be allowed, but only if the<br>
             <i>command</i> 
option has been specified (which may be useful for taking<br>
             remote 
backups even if root login is normally not allowed).  All<br>
             other authentication 
methods are disabled for root.
<p>
             If this 
option is set to ``no&#39;&#39;, root is not allowed to log in.
<p>
     <b>PermitTunnel</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=tun&sektion=4&arch=&apropos=0&manpath=OpenBSD+Current">
tun(4)</a> device forwarding is allowed.  The argu-<br>
             ment must 
be ``yes&#39;&#39;, ``point-to-point&#39;&#39; (layer 3), ``ethernet&#39;&#39;<br>
             (layer 
2), or ``no&#39;&#39;.  Specifying ``yes&#39;&#39; permits both ``point-<br>
             to-point&#39;&#39; 
and ``ethernet&#39;&#39;.  The default is ``no&#39;&#39;.
<p>
     <b>PermitUserEnvironment</b><br>
             Specifies 
whether <i>~/.ssh/environment</i> and <b>environment=</b> options in<br>
             <i>~/.ssh/authorized_keys</i> 
are processed by
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>.  The default is<br>
             ``no&#39;&#39;.  
Enabling environment processing may enable users to by-<br>
             pass access 
restrictions in some configurations using mechanisms<br>
             such as 
LD_PRELOAD.
<p>
     <b>PidFile</b><br>
             Specifies 
the file that contains the process ID of the SSH dae-<br>
             mon.  
The default is <i>/var/run/sshd.pid</i>.
<p>
     <b>Port</b>    Specifies the port number 
that
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> listens on.  The default<br>
             is 22.  
Multiple options of this type are permitted.  See also<br>
             <b>ListenAddress</b>.
<p>
     <b>PrintLastLog</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should print the date and time of the<br>
             last user 
login when a user logs in interactively.  The default<br>
             is ``yes&#39;&#39;.
<p>
     <b>PrintMotd</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should print <i>/etc/motd</i> when a user logs<br>
             in interactively.  
(On some systems it is also printed by the<br>
             shell,
<i>/etc/profile</i>, or equivalent.)  The default is ``yes&#39;&#39;.
<p>
     <b>Protocol</b><br>
             Specifies 
the protocol versions
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> supports.  The possible<br>
             values 
are `1&#39; and `2&#39;.  Multiple versions must be comma-separat-<br>
             ed.  
The default is ``2,1&#39;&#39;.  Note that the order of the protocol<br>
             list does 
not indicate preference, because the client selects<br>
             among multiple 
protocol versions offered by the server.  Specify-<br>
             ing ``2,1&#39;&#39; 
is identical to ``1,2&#39;&#39;.
<p>
     <b>PubkeyAuthentication</b><br>
             Specifies 
whether public key authentication is allowed.  The de-<br>
             fault is 
``yes&#39;&#39;.  Note that this option applies to protocol ver-<br>
             sion 2 
only.
<p>
     <b>RhostsRSAAuthentication</b><br>
             Specifies 
whether rhosts or /etc/hosts.equiv authentication to-<br>
             gether 
with successful RSA host authentication is allowed.  The<br>
             default 
is ``no&#39;&#39;.  This option applies to protocol version 1 on-<br>
             ly.
<p>
     <b>RSAAuthentication</b><br>
             Specifies 
whether pure RSA authentication is allowed.  The de-<br>
             fault is 
``yes&#39;&#39;.  This option applies to protocol version 1 on-<br>
             ly.
<p>
     <b>ServerKeyBits</b><br>
             Defines 
the number of bits in the ephemeral protocol version 1<br>
             server 
key.  The minimum value is 512, and the default is 768.
<p>
     <b>StrictModes</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should check file modes and ownership<br>
             of the 
user&#39;s files and home directory before accepting login.<br>
             This is 
normally desirable because novices sometimes accidentally<br>
             leave their 
directory or files world-writable.  The default is<br>
             ``yes&#39;&#39;.
<p>
     <b>Subsystem</b><br>
             Configures 
an external subsystem (e.g. file transfer daemon).<br>
             Arguments 
should be a subsystem name and a command (with optional<br>
             arguments) 
to execute upon subsystem request.  The command<br>
            
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sftp-server(8)</a> implements the ``sftp&#39;&#39; file transfer subsystem.<br>
             By default 
no subsystems are defined.  Note that this option ap-<br>
             plies to 
protocol version 2 only.
<p>
     <b>SyslogFacility</b><br>
             Gives the 
facility code that is used when logging messages from<br>
            
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>.  The possible values are: DAEMON, USER, AUTH, LOCAL0,<br>
             LOCAL1, 
LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.  The de-<br>
             fault is 
AUTH.
<p>
     <b>TCPKeepAlive</b><br>
             Specifies 
whether the system should send TCP keepalive messages<br>
             to the 
other side.  If they are sent, death of the connection or<br>
             crash of 
one of the machines will be properly noticed.  However,<br>
             this means 
that connections will die if the route is down tem-<br>
             porarily, 
and some people find it annoying.  On the other hand,<br>
             if TCP 
keepalives are not sent, sessions may hang indefinitely on<br>
             the server, 
leaving ``ghost&#39;&#39; users and consuming server re-<br>
             sources.
<p>
             The default 
is ``yes&#39;&#39; (to send TCP keepalive messages), and the<br>
             server 
will notice if the network goes down or the client host<br>
             crashes.  
This avoids infinitely hanging sessions.
<p>
             To disable 
TCP keepalive messages, the value should be set to<br>
             ``no&#39;&#39;.
<p>
     <b>UseDNS</b>  Specifies whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should look up the remote host name and<br>
             check that 
the resolved host name for the remote IP address maps<br>
             back to 
the very same IP address.  The default is ``yes&#39;&#39;.
<p>
     <b>UseLogin</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=login&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
login(1)</a> is used for interactive login ses-<br>
             sions.  
The default is ``no&#39;&#39;.  Note that
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=login&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
login(1)</a> is never used<br>
             for remote 
command execution.  Note also, that if this is en-<br>
             abled,
<b>X11Forwarding</b> will be disabled because
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=login&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
login(1)</a> does not<br>
             know how 
to handle
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=xauth&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
xauth(1)</a> cookies.  If <b>UsePrivilegeSeparation</b><br>
             is specified, 
it will be disabled after authentication.
<p>
     <b>UsePrivilegeSeparation</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> separates privileges by creating an un-<br>
             privileged 
child process to deal with incoming network traffic.<br>
             After successful 
authentication, another process will be created<br>
             that has 
the privilege of the authenticated user.  The goal of<br>
             privilege 
separation is to prevent privilege escalation by con-<br>
             taining 
any corruption within the unprivileged processes.  The<br>
             default 
is ``yes&#39;&#39;.
<p>
     <b>X11DisplayOffset</b><br>
             Specifies 
the first display number available for
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>&#39;s X11<br>
             forwarding.  
This prevents sshd from interfering with real X11<br>
             servers.  
The default is 10.
<p>
     <b>X11Forwarding</b><br>
             Specifies 
whether X11 forwarding is permitted.  The argument must<br>
             be ``yes&#39;&#39; 
or ``no&#39;&#39;.  The default is ``no&#39;&#39;.
<p>
             When X11 
forwarding is enabled, there may be additional exposure<br>
             to the 
server and to client displays if the
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> proxy display<br>
             is configured 
to listen on the wildcard address (see<br>
             <b>X11UseLocalhost</b> 
below), though this is not the default.  Addi-<br>
             tionally, 
the authentication spoofing and authentication data<br>
             verification 
and substitution occur on the client side.  The se-<br>
             curity 
risk of using X11 forwarding is that the client&#39;s X11 dis-<br>
             play server 
may be exposed to attack when the SSH client requests<br>
             forwarding 
(see the warnings for <b>ForwardX11</b> in
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current">
ssh_config(5)</a>).  A<br>
             system 
administrator may have a stance in which they want to pro-<br>
             tect clients 
that may expose themselves to attack by unwittingly<br>
             requesting 
X11 forwarding, which can warrant a ``no&#39;&#39; setting.
<p>
             Note that 
disabling X11 forwarding does not prevent users from<br>
             forwarding 
X11 traffic, as users can always install their own<br>
             forwarders.  
X11 forwarding is automatically disabled if <b>UseLogin</b><br>
             is enabled.
<p>
     <b>X11UseLocalhost</b><br>
             Specifies 
whether
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> should bind the X11 forwarding server<br>
             to the 
loopback address or to the wildcard address.  By default,<br>
             sshd binds 
the forwarding server to the loopback address and sets<br>
             the hostname 
part of the DISPLAY environment variable to<br>
             ``localhost&#39;&#39;.  
This prevents remote hosts from connecting to the<br>
             proxy display.  
However, some older X11 clients may not function<br>
             with this 
configuration.  <b>X11UseLocalhost</b> may be set to ``no&#39;&#39; to<br>
             specify 
that the forwarding server should be bound to the wild-<br>
             card address.  
The argument must be ``yes&#39;&#39; or ``no&#39;&#39;.  The de-<br>
             fault is 
``yes&#39;&#39;.
<p>
     <b>XAuthLocation</b><br>
             Specifies 
the full pathname of the
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=xauth&sektion=1&arch=&apropos=0&manpath=OpenBSD+Current">
xauth(1)</a> program.  The default<br>
             is <i>/usr/X11R6/bin/xauth</i>.
<p>
<a name="TIME+FORMATS" href="#end"><b>TIME FORMATS</b></a><br>
    
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a> command-line arguments and configuration file options that speci-<br>
     fy time may be expressed using a sequence of the form:
<i>time</i>[<i>qualifier</i>],<br>
     where <i>time</i> is a positive integer value and <i>qualifier</i> 
is one of the fol-<br>
     lowing:
<p>
           &lt;<b>none</b>&gt;  
seconds<br>
           <b>s</b> | <b>S</b>   
seconds<br>
           <b>m</b> | <b>M</b>   
minutes<br>
           <b>h</b> | <b>H</b>   
hours<br>
           <b>d</b> | <b>D</b>   
days<br>
           <b>w</b> | <b>W</b>   
weeks
<p>
     Each member of the sequence is added together to calculate 
the total time<br>
     value.
<p>
     Time format examples:
<p>
           600     
600 seconds (10 minutes)<br>
           10m     
10 minutes<br>
           1h30m   1 
hour 30 minutes (90 minutes)
<p>
<a name="FILES" href="#end"><b>FILES</b></a><br>
     /etc/ssh/sshd_config<br>
             Contains 
configuration data for
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>.  This file should be<br>
             writable 
by root only, but it is recommended (though not neces-<br>
             sary) that 
it be world-readable.
<p>
<a name="SEE+ALSO" href="#end"><b>SEE ALSO</b></a><br>
    
<a target="_blank" href="http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current">
sshd(8)</a>
<p>
<a name="AUTHORS" href="#end"><b>AUTHORS</b></a><br>
     OpenSSH is a derivative of the original and free ssh 1.2.12 
release by<br>
     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, 
Niels Provos, Theo<br>
     de Raadt and Dug Song removed many bugs, re-added newer 
features and cre-<br>
     ated OpenSSH.  Markus Friedl contributed the support 
for SSH protocol<br>
     versions 1.5 and 2.0.  Niels Provos and Markus Friedl 
contributed support<br>
     for privilege separation.<br>
 </p>

<hr>
<table border="1" width="100%" height="350">
   <tr>
      <td width="100%" align="center" colspan="5" rowspan="4">
      <center>
      <b>Top Visited</b></center>
      <iframe src="/topupdates.shtml" width="100%" height="320">

      <p>Your browser does not support iframes.</p>
      </iframe>
      </td>
      <td bgcolor="#FFFF00" align="center"><b><a href="switchboard.shtml">Switchboard</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b><a href="/index.shtml#Latest">Latest</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b>
      <a href="https://www.google.com/search?q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:y&sa=X&ei=aML0TaHgO4fUgAedxtjzCw&ved=0CAsQpwUoBQ&biw=1256&bih=801&cad=cbv#q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:w&sa=X&ei=csL0TYHsI4LagAeKu7DPCw&ved=0CAwQpwUoAw&fp=fb58e14853731932&biw=1256&bih=801">
      Past week</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b>
      <a href="https://www.google.com/search?q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:m&sa=X&ei=IMD0TdjLHMXUgQe9t6zfCw&ved=0CA0QpwUoBA">
      Past month</a></b></td>
   </tr>
</table
<hr noshade color="#FF0000" size="5">





<hr>

<h2><a name="NEWS_TOC">NEWS CONTENTS</a></h2>
<ul>
<li>20120809 : <a href="#n20120809X_speaking_unix_the_best_kept_secrets_of_unix_power_users"> Speaking UNIX: The best-kept secrets of UNIX power users</a> <i> by Martin Streicher,  Software Developer, Pixel, Byte, and Comma</i>  ( May 25, 2010 , IBM DeveloperWorld ) </li>
</ul>
<h2><a name="News">Old News ;-)</a></h2>

<center><table border="0" width="100"><tr>
<td align="center"><a href="#NEWS_TOC"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20120809X_speaking_unix_the_best_kept_secrets_of_unix_power_users" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#NEWS_TOC"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4>[Aug 09, 2012]
<a target="_blank" href="http://www.ibm.com/developerworks/aix/library/au-spunixpower.html#icomments">
Speaking UNIX: The best-kept secrets of UNIX power users</a> by Martin Streicher, 
Software Developer, Pixel, Byte, and Comma</h4>

<blockquote>
	<h6>May 25,  2010  | IBM DeveloperWorld</h6>

	<p><b>Shhh . . . secrets about SSH</b></p>

	<p>Secure Shell (SSH) is a rich subsystem used to log in to remote systems, 
	copy files, and tunnel through firewalls-securely. Since SSH is a subsystem, 
	it offers plenty of options to customize and streamline its operation. In fact, 
	SSH provides an entire &quot;dot directory&quot;, named $HOME/.ssh, to contain all its 
	data. (Your .ssh directory must be mode 600 to preclude access by others. A 
	mode other than 600 interferes with proper operation.) Specifically, the file 
	$HOME/.ssh/config can define lots of shortcuts, including aliases for machine 
	names, per-host access controls, and more. </p>

	<p>Here is a typical block found in $HOME/.ssh/config to customize SSH for a 
	specific host:</p>

	<pre>Host worker
HostName worker.example.com
IdentityFile ~/.ssh/id_rsa_worker
User joeuser
</pre>

	<p>Each block in ~/.ssh/config configures one or more hosts. Separate individual 
	blocks with a blank line. This block uses four options: <tt>Host</tt>, <tt>HostName</tt>,
	<tt>IdentityFile</tt>, and <tt>User</tt>. <tt>Host</tt>  establishes a 
	nickname for the machine specified by <tt>HostName</tt>. A nickname allows you 
	to type <tt>ssh worker</tt>  instead of <tt>ssh worker.example.com</tt>. 
	Moreover, the <tt>IdentityFile</tt>  and <tt>User</tt>  options dictate 
	how to log in to <tt>worker</tt>. The former option points to a private key 
	to use with the host; the latter option provides the login ID. Thus, this block 
	is the equivalent of the command: </p>

	<pre>ssh <a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="dbb1b4beaea8bea99bacb4a9b0bea9f5bea3bab6abb7bef5b8b4b6">[email&#160;protected]</a> -i ~/.ssh/id_rsa_worker
</pre>

	<p><font color="#FF0000"><i><b>A powerful but little-known option is <tt>ControlMaster</tt>. 
	If set, multiple SSH sessions to the same host share a single connection.
	</b></i></font>Once the first connection is established, credentials are not 
	required for subsequent connections, eliminating the drudgery of typing a password 
	each and every time you connect to the same machine. <tt>ControlMaster</tt>  
	is so handy, you&#39;ll likely want to enable it for every machine. That&#39;s accomplished 
	easily enough with the host wildcard, <tt>*</tt>: </p>

	<pre>Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p</pre>

	<br>
	As you might guess, a block tagged <tt>Host *</tt>  applies to every host, 
	even those not explicitly named in the config file. <tt>ControlMaster auto</tt>  
	tries to reuse an existing connection but will create a new connection if a 
	shared connection cannot be found. <tt>ControlPath</tt>  points to a file 
	to persist a control socket for sharing. <tt>%r</tt>  is replaced by the 
	remote login user name, <tt>%h</tt>  is replaced by the target host name, 
	and <tt>%p</tt>  stands in for the port used for the connection. (You can 
	also use <tt>%l</tt>; it is replaced with the local host name.) The specification 
	above creates control sockets with file names akin to:

	<pre><a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="bfd2decccbdacd92d5d0dacaccdacdffc8d0cdd4dacd91dac7ded2cfd3da91dcd0d2">[email&#160;protected]</a>:22
</pre>

	<br>
	Each control socket is removed when all connections to the remote host are severed. 
	If you want to know which machines you are connected to at any time, simply 
	type <tt>ls ~/.ssh</tt>  and look at the host name portion of the control 
	socket (<tt>%h</tt>).

	<p>The SSH configuration file is so expansive, it too has its own man page. 
	Type <tt>man ssh_config</tt>  to see all possible options. And here&#39;s a 
	clever SSH trick: You can tunnel from a local system to a remote one via SSH. 
	The command line to use looks something like this: </p>

	<pre>$ ssh example.com -L 5000:localhost:3306
</pre>

	<br>
	This command says, &quot;Connect via example.com and establish a tunnel between port 
	5000 on the local machine and port 3306 [the MySQL server port] on the machine 
	named &#39;localhost.&#39;&quot; Because <tt>localhost</tt>  is interpreted on example.com 
	as the tunnel is established, <tt>localhost</tt>  is example.com. With 
	the outbound tunnel-formally called a <i>local forward</i>-established, local 
	clients can connect to port 5000 and talk to the MySQL server running on example.com.

	<p>This is the general form of tunneling:</p>

	<pre>$ ssh <i>proxyhost</i> <i>localport</i>:<i>targethost</i>:<i>targetport</i></pre>

	<p>Here, <tt><i>proxyhost</i></tt>  is a machine you can access via SSH 
	and one that has a network connection (not via SSH) to <tt><i>targethost</i></tt>.
	<tt><i>localport</i></tt>  is a non-privileged port (any unused port above 
	1024) on your local system, and <tt><i>targetport</i></tt>  is the port 
	of the service you want to connect to. </p>

	<p>The previous command tunnels <i>out</i> from your machine to the outside 
	world. You can also use SSH to tunnel <i>in,</i> or connect to your local system 
	from the outside world. This is the general form of an inbound tunnel: </p>

	<pre>$ ssh <i>user</i>@<i>proxyhost</i> -R <i>proxyport</i>:<i>targethosttargetport</i></pre>

	<p>When establishing an inbound tunnel-formally called a <i>remote forward</i>-the 
	roles of <tt><i>proxyhost</i></tt>  and <tt><i>targethost</i></tt>  
	are reversed: The target is your local machine, and the proxy is the remote 
	machine. <tt><i>user</i></tt>  is your login on the proxy. This command 
	provides a concrete example: </p>

	<pre>$ ssh <a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="7812171d381d00191508141d561b1715">[email&#160;protected]</a> -R 8080:localhost:80</pre>

	<p>The command reads, &quot;Connect to example.com as joe, and connect the remote 
	port 8080 to local port 80.&quot; This command gives users on example.com a tunnel 
	to Joe&#39;s machine. A remote user can connect to 8080 to hit the Web server on 
	Joe&#39;s machine. </p>

	<p>In addition to <tt>-L</tt>  and <tt>-R</tt>  for local and remote 
	forwards, respectively, SSH offers <tt>-D</tt>  to create an HTTP proxy 
	on a remote machine. See the SSH man page for the proper syntax. </p>

	<p><i>Martin Streicher is a freelance Ruby on Rails developer and the former 
	Editor-in-Chief of <a target="_blank" href="http://www.linux-mag.com">Linux Magazine</a>. Martin 
	holds a Masters of Science degree in computer science from Purdue University 
	and has programmed UNIX-like systems since 1986. He collects art and toys. You 
	can reach Martin at
	<a href="/cdn-cgi/l/email-protection#e984889b9d8087c79a9d9b8c808a818c9ba98e84888085c78a8684d68a8ad484848a8a9b889b90a99c9ac7808b84c78a8684"><span class="__cf_email__" data-cfemail="6d000c1f190403431e191f08040e05081f2d0a000c0401430e0200">[email&#160;protected]</span></a>.</i></p>
</blockquote>

</em></b></i><h2><hr></h2>
<hr noshade color="#FF0000" size="5">

<h2><a name="Etc">Etc</a></h2>

<p><b>Society</b></p>
<blockquote>

<p><b><a href="/Skeptics/groupthink.shtml"><font size="2">Groupthink</font></a><font size="2"> :
<a href="/Skeptics/Political_skeptic/Two_party_system_as_poliarchy/index.shtml">Two Party System 
as Polyarchy</a> : 
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Corruption_of_regulators/index.shtml">
Corruption of Regulators</a> :
<a href="/Social/Bureaucracy/index.shtml">Bureaucracies</a> :
<a href="/Social/Toxic_managers/Micromanagers/understanding_micromanagers.shtml">Understanding Micromanagers 
and Control Freaks</a> : <a href="/Social/Toxic_managers/index.shtml">Toxic Managers</a> :&nbsp;&nbsp;
<a href="/Skeptics/Pseudoscience/harvard_mafia.shtml">Harvard Mafia</a> :
<a href="/Social/Toxic_managers/Communication/diplomatic_communication.shtml">Diplomatic Communication</a> 
: <a href="/Social/Toxic_managers/surviving_a_bad_performance_review.shtml">Surviving a Bad Performance 
Review</a> : <a href="/Skeptics/Financial_skeptic/index.shtml">Insufficient Retirement Funds as 
Immanent Problem of Neoliberal Regime</a> : <a href="/Skeptics/index.shtml">PseudoScience</a> :
<a href="/Skeptics/Political_skeptic/index.shtml">Who Rules America</a> :
<a href="/Skeptics/Political_skeptic/Neoliberalism/index.shtml">Neoliberalism
</a>&nbsp;: <a href="/Skeptics/Political_skeptic/Elite_theory/iron_law_of_oligarchy.shtml">The Iron 
Law of Oligarchy</a> : </font><a href="/Skeptics/Political_skeptic/libertarianism.shtml">
<font size="2">Libertarian Philosophy</font></a></b></p>
</blockquote>

<p><b>Quotes</b></p>
<blockquote>

<p><b><font size="2" face="Arial"> 
<a href="/Skeptics/Quotes/war_and_peace_quotes.shtml">War and Peace</a> </font>
<font face="Arial"><font size="2">: <a href="/Skeptics/Quotes/financial_quotes.shtml">Skeptical 
Finance</a> : <a href="/Skeptics/Quotes/famous_galbraith_quotes.shtml">John 
Kenneth Galbraith</a> :<a href="/Skeptics/Quotes/talleyrand_quotes.shtml">Talleyrand</a> :
<a href="/Skeptics/Quotes/oscar_wilde_quotes.shtml">Oscar Wilde</a> :
<a href="/Skeptics/Quotes/bismarck_quotes.shtml">Otto Von Bismarck</a> :
<a href="/Skeptics/Quotes/keynes_quotes.shtml">Keynes</a> :
<a href="/Skeptics/Quotes/george_carlin.shtml">George Carlin</a> :
<a href="/Skeptics/skeptical_quotes.shtml">Skeptics</a> :
<a href="/Skeptics/Quotes/propaganda.shtml">Propaganda</a>&nbsp; : <a href="/SE/quotes.shtml">SE 
quotes</a> : <a href="/Lang/quotes.shtml">Language Design and Programming Quotes</a> :
<a href="/Bulletin/quotes.shtml">Random IT-related quotes</a> :&nbsp;
<a href="/Skeptics/Quotes/somerset_maugham.shtml">Somerset Maugham</a> :
<a href="/Skeptics/Quotes/marcus_aurelius.shtml">Marcus Aurelius</a> :
<a href="/Skeptics/Quotes/kurt_vonnegut_quotes.shtml">Kurt Vonnegut</a> :
<a href="/Skeptics/Quotes/eric_hoffer.shtml">Eric Hoffer</a> :
<a href="/Skeptics/Quotes/churchill_quotes.shtml">Winston Churchill</a> :
<a href="/Skeptics/Quotes/napoleon_quotes.shtml">Napoleon Bonaparte</a> :
<a href="/Skeptics/Quotes/ambrose_bierce.shtml">Ambrose Bierce</a> :&nbsp;
<a href="/Skeptics/Quotes/bernard_shaw.shtml">Bernard Shaw</a> : </font>
<a href="/Skeptics/Quotes/mark_twain_quotes.shtml"><font size="2">Mark Twain Quotes</font></a></font></b></p>
</blockquote>

<p><b>Bulletin:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="http://softpanorama.biz/Bulletin/Sp2013_v25/bulletin25_12.shtml">
<font size="2">Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient 
markets hypothesis</font></a><font size="2"> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Bulletin/political_skeptic2013.shtml">
Political Skeptic Bulletin, 2013</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Unemployment/Bulletin/unempoyment2010.shtml">
Unemployment Bulletin, 2010</a> :
<a href="http://softpanorama.biz/Bulletin/Sp2011_v23/bulletin23_10.shtml">&nbsp;Vol 23, No.10 
(October, 2011) An observation about corporate security departments</a> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Fifth_column/Color_revolutions/Euromaydan/Bulletin/euromaydan14_06.shtml">
Slightly Skeptical Euromaydan Chronicles, June 2014</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Casino_capitalism/12_Apostols_of_deregulation/Greenspan/Bulletin/greenspan_bulletin2008.shtml">
Greenspan legacy bulletin, 2008</a> :
<a href="/Bulletin/Sp2013_v25/bulletin25_10.shtml">Vol 25, No.10 (October, 2013) Cryptolocker Trojan 
(Win32/Crilock.A)</a> :
<a href="/Bulletin/Sp2013_v25/bulletin25_08.shtml">Vol 25, No.08 (August, 2013) Cloud providers 
as intelligence collection hubs</a> : 
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2010.shtml">
Financial Humor Bulletin, 2010</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Inequality/Bulletin/inequality2009.shtml">
Inequality Bulletin, 2009</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2008.shtml">
Financial Humor Bulletin, 2008</a> :
<a href="http://softpanorama.biz/Copyright/Bulletin/copyleft_problems2004.shtml">Copyleft Problems 
Bulletin, 2004</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2011.shtml">
Financial Humor Bulletin, 2011</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Energy/Bulletin/energy_bulletin2010.shtml">
Energy Bulletin, 2010</a> : <a href="http://softpanorama.biz/Malware/Bulletin/malware2010.shtml">
Malware Protection Bulletin, 2010</a> : <a href="/Bulletin/Sp2014_v26/bulletin26_01.shtml">Vol 26, 
No.1 (January, 2013) Object-Oriented Cult</a> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Bulletin/political_skeptic2011.shtml">
Political Skeptic Bulletin, 2011</a> :
<a href="/Bulletin/Sp2011_v23/bulletin23_11.shtml">Vol 23, No.11 (November, 2011) Softpanorama classification 
of sysadmin horror stories</a> : <a href="/Bulletin/Sp2013_v25/bulletin25_05.shtml">Vol 25, No.05 
(May, 2013) Corporate bullshit as a communication method</a>&nbsp; : </font><a href="/Bulletin/Sp2013_v25/bulletin25_06.shtml">
<font size="2">Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law</font></a></font></b></p>
</blockquote>

<p align="left"><b>History:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="/History/index.shtml"><font size="2">Fifty glorious years (1950-2000): 
the triumph of the US computer engineering</font></a><font size="2"> :
<a href="/People/Knuth/index.shtml">Donald Knuth</a> : <a href="/People/Knuth/taocp.shtml">TAoCP 
and its Influence of Computer Science</a> : <a href="/People/Stallman/index.shtml">Richard Stallman</a> 
: <a href="/People/Torvalds/index.shtml">Linus Torvalds</a>&nbsp; :
<a href="/People/Wall/index.shtml">Larry Wall </a>&nbsp;:
<a href="/People/Ousterhout/index.shtml">John K. Ousterhout</a> : <a href="/History/ctss.shtml">
CTSS</a> : <a href="/History/multix.shtml">Multix OS</a> <a href="/History/Unix/index.shtml">Unix 
History</a> : <a href="/People/Shell_giants/introduction.shtml">Unix shell history</a> :
<a href="/Editors/Vimorama/history.shtml">VI editor</a> :
<a href="/Scripting/Piporama/history.shtml">History of pipes concept</a> :
<a href="/Solaris/solaris_history.shtml">Solaris</a> : <a href="/History/dos_history.shtml">MS DOS</a> 
:&nbsp; <a href="/History/lang_history.shtml">Programming Languages History</a> :
<a href="/Lang/pl1.shtml">PL/1</a> : <a href="/Lang/simula67.shtml">Simula 67</a> :
<a href="/Lang/Cilorama/history.shtml">C</a> :
<a href="/People/Stallman/history_of_gcc_development.shtml">History of GCC development</a> :&nbsp;
<a href="/People/Scripting_giants/scripting_languages_as_vhll.shtml">Scripting Languages</a> :
<a href="/Scripting/Perlbook/Ch01/perl_history.shtml">Perl history&nbsp; </a>&nbsp;:
<a href="/History/os_history.shtml">OS History</a> : <a href="/Mail/history.shtml">Mail</a> :
<a href="/DNS/history.shtml">DNS</a> : <a href="/Net/Application_layer/SSH/ssh_history.shtml">SSH</a> 
: <a href="/History/cpu_history.shtml">CPU Instruction Sets</a> :
<a href="/Hardware/Sun/history_of_sparc.shtml">SPARC systems 1987-2006</a> :
<a href="/OFM/Paradigm/Ch03/norton_commander.shtml">Norton Commander</a> :
<a href="/Windows/Norton_utilities/history.shtml">Norton Utilities</a> :
<a href="/Windows/Ghosting/ghost_history.shtml">Norton Ghost</a> :
<a href="/Office/Frontpage/history.shtml">Frontpage history</a> :
<a href="/Malware/Malware_defense_history/index.shtml">Malware Defense History</a> :
<a href="/Utilities/Screen/history.shtml">GNU Screen</a> : </font>
<a href="/OSS/oss_early_history.shtml"><font size="2">OSS early history</font></a></font></b></p>
</blockquote>

<p><b>Classic books:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="/Bookshelf/Classic/peter_principle.shtml"><font size="2">The Peter 
Principle</font></a><font size="2"> : <a href="/Bookshelf/Classic/parkinson_law.shtml">Parkinson 
Law</a> : <a href="/Bookshelf/Classic/nineteen_eighty_four.shtml">1984</a> :
<a href="/Bookshelf/Classic/tmmm.shtml">The Mythical Man-Month</a> :&nbsp;
<a href="/Bookshelf/Classic/polya_htsi.shtml">How to Solve It by George Polya</a> :
<a href="/Bookshelf/Classic/taocp.shtml">The Art of Computer Programming</a> :
<a href="/Bookshelf/Classic/teops.shtml">The Elements of Programming Style</a> :
<a href="/Bookshelf/Classic/unix_haters_handhook.shtml">The Unix Hater’s Handbook</a> :
<a href="/Bookshelf/Classic/jargon_file.shtml">The Jargon file</a> :
<a href="/Bookshelf/Classic/true_believer.shtml">The True Believer</a> :
<a href="/Bookshelf/Classic/programming_pearls.shtml">Programming Pearls</a> :
<a href="/Bookshelf/Classic/good_soldier_svejk.shtml">The Good Soldier Svejk</a> : </font>
<a href="/Bookshelf/Classic/power_elite.shtml"><font size="2">The Power Elite</font></a></font></b></p>
</blockquote>

<p><b>Most popular humor pages:</b></p>
<blockquote>

<p><font face="Arial"><b><a href="/Bulletin/Humor/Slackerism/it_slacker_manifest.shtml">
<font size="2">Manifest of the Softpanorama IT Slacker Society</font></a><font size="2"> :
<a href="/Bulletin/Humor/Slackerism/ten_commandments_of_software_slackerism.shtml">Ten Commandments 
of the IT Slackers Society</a> : <a href="/Bulletin/Humor/index.shtml">Computer Humor Collection</a> 
: <a href="/Bulletin/Humor/bsd_logo_story.shtml">BSD Logo Story</a> :
<a href="/Bulletin/Humor/cuckoo_egg.shtml">The Cuckoo&#39;s Egg </a>:
<a href="/Bulletin/Humor/slang.shtml">IT Slang</a> : <a href="/Lang/Cpp_rama/humor.shtml">C++ Humor</a> 
: <a href="/Bulletin/Humor/Archive/humor059.shtml">ARE YOU A BBS ADDICT?</a> :
<a href="/Bulletin/Humor/Archive/humor092.shtml">The Perl Purity Test</a> :
<a href="/Bulletin/Humor/Archive/humor065.shtml">Object oriented programmers of all nations</a> 
: <a href="/Skeptics/Financial_skeptic/Humor/financial_humor.shtml">Financial Humor</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2008.shtml">Financial Humor Bulletin, 
2008</a> : <a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2010.shtml">Financial 
Humor Bulletin, 2010</a> : <a href="/Editors/humor.shtml">The Most Comprehensive Collection of Editor-related 
Humor</a> : <a href="/Lang/programming_languages_humor.shtml">Programming Language Humor</a> :
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Systemic_instability_of_financial_sector/TBTF/Goldman_Sachs/humor.shtml">
Goldman Sachs related humor</a> :
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Twelve_apostles_of_deregulation/Greenspan/greenspan_humor.shtml">
Greenspan humor</a> : <a href="/Lang/Cilorama/humor.shtml">C Humor</a> :
<a href="/Scripting/humor.shtml">Scripting Humor</a> :
<a href="/Bulletin/Humor/real_programmers_humor.shtml">Real Programmers Humor</a> :
<a href="/WWW/humor.shtml">Web Humor</a> : <a href="/Copyright/humor.shtml">GPL-related Humor</a> 
: <a href="/OFM/ofm_humor.shtml">OFM Humor</a> :
<a href="/Skeptics/Political_skeptic/humor.shtml">Politically Incorrect Humor</a> :
<a href="/Security/IDS/humor.shtml">IDS Humor</a> : <a href="/Bulletin/Humor/linux_sucks.shtml">
&quot;Linux Sucks&quot; Humor </a>: <a href="/Links/Russian/Culture/Music/russian_musical_humor.shtml">Russian 
Musical Humor</a> : <a href="/Bulletin/Humor/best_russian_programmer_humor.shtml">Best Russian Programmer 
Humor</a> : <a href="/Bulletin/Humor/Archive/humor070.shtml">Microsoft plans to buy Catholic Church</a> 
: <a href="/People/Stallman/rms_related_humor.shtml">Richard Stallman Related Humor</a> :
<a href="/Admin/humor.shtml">Admin Humor</a> : <a href="/People/Wall/perl_related_humor.shtml">Perl-related 
Humor</a> : <a href="/People/Torvalds/linus_torvalds_related_humor.shtml">Linus Torvalds Related 
humor</a> : <a href="/Skeptics/humor.shtml">PseudoScience Related Humor</a> :
<a href="/Net/net_humor.shtml">Networking Humor</a> :
<a href="/Scripting/Shellorama/humor.shtml">Shell Humor</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2011.shtml">Financial Humor Bulletin, 
2011</a> : <a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2012.shtml">Financial 
Humor Bulletin, 2012</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2013.shtml">Financial Humor Bulletin, 
2013</a> : <a href="/Lang/Javarama/humor.shtml">Java Humor</a> : <a href="/SE/humor.shtml">Software 
Engineering Humor</a> : <a href="/Solaris/humor.shtml">Sun Solaris Related Humor</a> :
<a href="/Education/humor.shtml">Education Humor</a> : <a href="/Admin/Tivoli/ibm_humor.shtml">IBM 
Humor</a> : <a href="/Lang/Asmorama/humor.shtml">Assembler-related Humor</a> :
<a href="/Editors/Vimorama/vim_humor.shtml">VIM Humor</a> : <a href="/Malware/humor.shtml">Computer 
Viruses Humor</a> : <a href="/Bulletin/Humor/Archive/humor034.shtml">Bright tomorrow is rescheduled 
to a day after tomorrow</a> : <a href="/Bulletin/Humor/classic_computer_humor.shtml">Classic Computer 
Humor</a> </font></b></font></p>
</blockquote>

<p align="left"><b><a href="/Bulletin/Humor/last_but_not_least.shtml">The Last but not Least</a> </b> <em>Technology is dominated by 
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. 
Ph.D</em></p>

<hr size="5" noshade color="#FF0000"><font face="Verdana" size="1">

<p><i><b>Copyright © 1996-2021 by </b></i><b><i>Softpanorama Society</i></b>. <a target="_blank" href>www.softpanorama.org</a> 
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (<a target="_blank" href="http://www.un.org/Depts/dhl/sflib/">SDNP</a>) 
without any remuneration. This document is an industrial compilation designed and <b>created exclusively 
for educational use</b> and is distributed under the <a href="/license.shtml">Softpanorama Content License</a>. 
Original materials copyright belong 
to respective owners. <i><b>Quotes are made<font color="#FF0000"> for educational purposes only</font> 
in compliance with the fair use doctrine. </b></i> 
</p>

<p><em><b>FAIR USE NOTICE</b> </em>This site contains 
		copyrighted material the use of which has not always been specifically 
		authorized by the copyright owner. We are making such material available 
		to advance understanding of computer science, IT technology, economic, scientific, and social  
		issues. We believe this constitutes a 'fair use' of any such 
		copyrighted material as provided by section 107 of the US Copyright Law according to which 
such material can be distributed without profit exclusively for research and educational purposes.</p>

<p><b>This is a Spartan WHYFF (We Help You For Free) 
site written by people for whom English is not a native language.</b> Grammar and spelling errors should 
be expected. <b>The site contain some broken links as it develops like a living tree...</b></p>

<table border="0" width="100%">
<tr>
<td>

<p align="center"><font face="Verdana" size="1">
<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
<img alt="" border="0" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" width="1" height="1">
</font></td>
<td><font face="Verdana" size="1">You can use PayPal to to buy a cup of coffee for authors 
of this site </font></td>
</tr>
</table>

<p><b>Disclaimer:</b> </p>

<p><i>The statements, views and opinions presented on this web page are those of the author (or 
referenced source) and are 
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.</i> <i>We do not warrant the correctness 
of the information provided or its fitness for any purpose. </i>The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be 
tracked by Google please disable Javascript for this site. <em>This site is perfectly usable without 
Javascript.</em> 
</font></p>
<p><em>Last modified:
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%B %d, %Y" startspan -->March 12, 2019<!--webbot bot="Timestamp" i-checksum="17043" endspan --></em></p>

<script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>

</html>