Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

SSH Configuration

News SSH Recommended Links SSH troubleshooting Private and Public key management Mini-tutorial Passwordless SSH login
ssh-keygen man page SSH Forwarding Minitutorial X11 forwaring over ssh Reverse SSH Tunnels SSH client SCP Tips ssh & TCP Wrappers
  Unix Sysadmin Tips Sysadmin Horror Stories SSH History Tips Humor Etc

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 (sshd_config), the client command-line options, the user client configuration file (~/.ssh/config), and the global client configuration file (ssh_config). Build-time configuration is the strongest. It cannot be changed without rebuilding the software. This makes it inconvenient if a change is needed.

The server configuration involves the following: how the sshd(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.

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.

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

Configuration files contain two types of entries: comments and keyword-value pairs. Comments are blank lines and lines beginning with the hash mark (#). 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.

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

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

Name of the option and the value or values it takes

Note: Server options override the client's configuration.

Recommendations

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's impact on the whole. This section includes some configuration recommendations and discusses the consequences of their usage.

Note

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.

Server Recommendations

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.

Protocol Support

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.

Network Access

By default, the sshd(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. For architectures such as the Service Delivery Network, in which management traffic is limited to a particular interface, this behavior is a problem. Limit network access with the ListenAddress keyword. Access is limited by a particular IP address, not by a network interface.

 # Listen only to the management network.
 ListenAddress 192.168.0.10

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

For information about traffic-limited architectures, consult the Sun BluePrints OnLine article "Building Secure N-Tier Environments" (October 2000).

Keep-Alives

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.

 KeepAlive yes
Data Compression

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.

[View full width]
# Transferring ASCII data such as interactive logins or log files
 Compression yes 
[View full width]
# Transferring random data such as compressed or
 encrypted files
 # Prevents performance issues and reduces CPU load
 Compression no
Privilege Separation

Privilege separation is an OpenSSH-only feature. The sshd(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.

Note

The compilation options presented in Chapter 2 disable privilege separation.

 # OpenSSH only
 UsePrivilegeSeparation no
Login Grace Time

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.

 LoginGraceTime 60
Password and Public Key Authentication

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 "Managing Keys and Identities" on page 71 for more details. When passwords are deemed sufficient, do not allow empty passwords. They are too easy to guess.

 PasswordAuthentication yes
 PermitEmptyPasswords no
 PubKeyAuthentication yes
 DSAAuthentication yes
Superuser (root) Logins

Neither the Solaris Secure Shell software nor OpenSSH honors the values set in the /etc/default/login file. To prevent network superuser (root) logins, they must be explicitly denied. The Solaris Secure Shell software and OpenSSH default to yes. However, the default sshd_config(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 (su) to the superuser. Enable superuser logins only if the system has no user accounts and the appropriate host protection is in place.

 PermitRootLogin no
Banners, Mail, and Message-of-the-Day

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 Banner keyword. Set Banner to /etc/issue so that only one banner file exists for the entire system.

 Banner /etc/issue

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 no to eliminate the duplication.

 CheckMail no
 PrintMotd no
Connection and X11 Forwarding

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.

Note

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.

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.

If port forwarding is enabled, disable GatewayPorts and notify your users. GatewayPorts 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.

 AllowTCPForwarding yes
 GatewayPorts no
 X11DisplayOffset 10
 X11Forwarding yes
 XAuthLocation /usr/X/bin/xauth
User Access Control Lists

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: AllowGroups, AllowUsers, DenyGroups or DenyUsers.

 # Allow only the sysadmin staff
 AllowGroups staff

 # Prevent unauthorized users.
 DenyUsers cheng atkinson
User File Permissions

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 known_hosts file to allow man-in-the-middle attacks. With StrictModes enabled, the sshd(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.

 StrictModes yes

If you decide to disable StrictModes, 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.

UseLogin Keyword

For OpenSSH only, UseLogin specifies that the OpenSSH sshd(1M) call login(1) instead of performing the initial login tasks itself for interactive sessions. login(1) must be called for BSM auditing. Unless UseLogin is set to yes, cron(1M) will partially break if SunSHIELD BSM auditing is enabled. See "Auditing" on page 81 for details on the consequences of UseLogin and on getting BSM auditing to work successfully. UseLogin will not work if UsePrivilegeSeparation is enabled. Enabling UseLogin disables X11 and port forwarding.

 UseLogin no
Legacy Support

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 rhosts-style authentication methods. Increase the server key size and decrease the ephemeral key regeneration interval to minimize offline factoring attacks against the keys.

 # 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

Configuration Options

AllowGroups pattern

   # Allow only the whell access
   AllowGroups wheel
   # Allow both staff and sysadmin access
   AllowGroups s*
 

AllowUsers pattern

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

   # Allow only Suzie and Buster access.
   AllowUsers suzie buster

AllowTCPForwarding yes | no

Note

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

# Protect user's traffic
   AllowTCPForwarding yes
[View full width]
# Only allow a remote job restricted access to
 gather logs.
   AllowTCPForwarding no

Banner value

   Banner /etc/issue

CheckMail yes | no

   CheckMail no

Ciphers list

   Ciphers aes128-cbc,blowfish-cbc,3des-cbc

Compression yes | no

   Compression yes

DenyGroups pattern

   # Prevent the users from logging in to the server  
   DenyGroups users

DenyUsers pattern

   DenyUsers Cheng Atkinson

DSAAuthentication yes | no

   DSAAuthentication yes

GatewayPorts yes | no

Note

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

   GatewayPorts no

HostKey value

   HostKey /etc/ssh/ssh_host_key
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_dsa_key

IgnoreRhosts yes | no

   IgnoreRhosts yes

IgnoreUserKnownHosts yes | no

   IgnoreUserKnownHosts yes

KeepAlive yes | no

   keepAlive yes

KeyRegenerationInterval value

   KeyRegenerationInterval 1800

ListenAddress value

   ListenAddress 192.168.0.5

LoginGraceTime value

   LoginGraceTime 60

LogLevel value

   LogLevel DEBUG

MACs list

   MACS hmac-sha1, hmac-md5

MaxAuthTries value

   MaxAuthTries 6

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

hook /home/suzi $ ssh blackbeard
   suzi@blackbeard's password: password
   Permission denied, please try again.
   suzi@blackbeard's password: password
   Received disconnect: 2: too many failed
 userauth_requests
   hook /home/suzi $

MaxAuthTriesLog value

   MaxAuthTriesLog 3

MaxStartups value

   MaxStartups 10

PAMAuthenticationViaKBDInt yes|no

   PAMAuthenticationViaKBDInt yes

PasswordAuthentication yes|no

   # Internal mail server
   PasswordAuthentication yes
   # DMZ Bastion host
   PasswordAuthentication no

PermitEmptyPasswords yes|no

   PermitEmptyPasswords no

PermitRootLogin yes|no|without-password|forced-commands-only

   # Force the system admins to su
   PermitRootLogin no

   # Only a root account exists
   PermitRootLogin without-password

PermitUserEnvironment yes|no

   PermitUserEnvironment no

Port value

   # For LAN access 
   Port 22
   # For Internet access
   Port 2345

PrintMotd yes|no

   PrintMotd no

Protocol list

   # Protocol 2 only is recommended
   Protocol 2

   # Enable legacy support but default to Protocol 2.
   Protocol 2,1

PubKeyAuthentication yes|no

   PubKeyAuthentication yes

RhostsAuthentication yes|no

   RhostsAuthentication no

RhostsRSAAuthentication yes|no

   RhostsRSAAuthentication no

RSAAuthentication yes|no

   RSAAuthentication yes

ServerKeyBits value

   ServerKeyBits 1024

StrictModes yes|no

   StrictModes yes

SyslogFacility value.value

   SyslogFacility AUTH.INFO

UseLogin yes|no

   UseLogin no

UsePrivilegeSeparation yes|no

Note

The compilations options presented in Chapter 2 disable this feature.

   UsePrivilegeSeparation no

X11DisplayOffset value

   # For desktops or server
   X11DisplayOffset 10

 
[View full width]
# For Sun Ray appliance servers, may need to be
 more.
   X11DisplayOffset 100

X11Forwarding yes|no

 
   # Protect user's X sessions
   X11Forwarding yes

   # Only allow restricted access for a remote job
   X11Forwarding no

XAuthLocation Value

   XAuthLocation /usr/X/bin/xauth

Port Forwarding

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.

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.

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.

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

This example shows forwarding using the ssh(1) command:

 $ ssh -L8080:server:80 server

This example shows forwarding using the client's configuration file:

 Host server
 LocalForward 8080 server:80

Note

The Solaris Secure Shell software disables port forwarding by default. See "Connection and X11 Forwarding" on page 46 for more details.

To Secure WebNFS Mounts With Port Forwarding

  1. Choose an unused local port and forward it to the WebNFS port on the server.

    A different local port will be needed for each server. This connection must be maintained for the life of the mount.

     $ ssh -f -N -L3030:server:2049 server


     


     

  2. Become the superuser.

  3. Mount the file system using the forwarded port.

     # mount nfs://localhost:3030/export/home /mnt


     


     

Note

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

Insecure Service Disablement

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

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

To Disable Insecure Services

  1. Become the superuser.

  2. Edit /etc/inetd.conf and comment out insecure services.

  3. Use the kill(2) command to send the HANGUP signal to inetd(1M).

     
    [View full width]
    # ps -ef | grep inetd | grep -v grep
     root   153     1  0   Dec 09 ?       0:02 
/usr/sbin/inetd -s
 # kill -HUP 153


     


     

  4. Ensure that the services have been disabled.

     
    [View full width]
    $ telnet localhost
 Trying 127.0.0.1...
 telnet: Unable to connect to remote host:
 Connection refused
 $ rsh localhost
 localhost: Connection refused


     


     

Chapter 6. Managing Keys and Identities

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

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 ssh-keygen(1) command generates the key pairs.

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

Host Keys

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 init script generates a host key pair using the ssh-keygen(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.

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 $HOME/. ssh/known_hosts file. If the key differs, the following warning message is displayed:

 
[View full width]
$ 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.

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.

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 known_hosts file to the client with all of the host keys in it. Keys can be gathered out-of-band through the console.

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.

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.

The obvious solution is to use ssh-keyscan(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 ssh-keyscan(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

User Identities

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.

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.

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

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

Caution

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's home directory. You can reduce this risk in the Secure Shell server configurations by allowing only password authentication.

Revoking an identity can also be problematic because the work required is asymmetrical. On the user's side, the passphrase can be forgotten, and the private key can be deleted. On the server's side, the public key entry must be removed from every $HOME/ .ssh/authorized_keys 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.

Identities do have their uses. They can be combined with agents (refer to "Agents" on page 75) to provide secure passphrase-free logins. They also provide a higher assurance of security than passwords.

To Create an Identity

1. Decide on the type and size of identity to create.

2. Create the identity and enter a passphrase.

The following is an example of creating a 1024-bit RSA identity: 

[View full width]
$ 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


To Register an Identity

1. Copy the public key, file .pub, to the remote Secure Shell server.

2. Create the $HOME/.ssh directory with mode go-w if it does not exist.

3. Create the $HOME/.ssh/authorized_keys file with mode go-w if it does not exist.

4. Add the public key to $HOME/.ssh/authorized_keys.

To Revoke an Identity

1. On the Secure Shell server, remove the public key entry from the $HOME/.ssh/authorized_keys file.

2. On the client, remove the private key.

Agents

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.

 
[View full width]
$ ssh morgan
 Last login: Fri Jan 17 14:52:44 2003 from drake
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 morgan $

Agents work by communicating over a private UNIX socket. This socket is stored in a user-owned, mode 700 directory in the /tmp directory. The naming scheme for the socket is agent. PID_of_the_ssh-agent. A Secure Shell client determines agent usage by the presence of the SSH_AUTH_SOCK and SSH_AGENT_PID 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.

When an agent is started with the ssh-agent(1) command, Bourne shell commands are output that enable Secure Shell clients to communicate with the agent. Using the -c option, C shell commands can alternatively be output. Using the eval(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.

The following is an example of starting an agent:

 
[View full width]
$ 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;

The following is an example of starting an agent within the shell:

 $ eval 'ssh-agent'
 Agent pid 16867

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

The following is an example of listing an empty agent:

 $ ssh-add -1
 The agent has no identities.

The following is an example of listing an agent with one RSA key:

 
[View full width]
$ 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)

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

 
[View full width]
$ 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)

The following is an example of adding a specific identity:

 
[View full width]
$ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)

Common Desktop Environment Support

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

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

http://www.jmknoble.net/software/x11-ssh-askpass/

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

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

 
[View full width]
# Start an agent for the session.
 # Use Solaris Secure Shell if available;
 otherwise, use OpenSSH.
 if [ -x /usr/bin/ssh-agent ]; then
      eval '/usr/bin/ssh-agent'
      solarisoe=1;
 elif [ -x /opt/OBSDssh/bin/ssh-agent ]; then
      eval '/opt/OBSDssh/bin/ssh-agent'
      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 "$SSH_ASKPASS" ]; then
      if [ $solarisoe -eq 1 ]; then
           /usr/bin/ssh-add
      else
           /opt/OBSD/ssh/bin/ssh-add
      fi
fi

Removing Agents

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 ssh-agent(1) command with the -k 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 -k option, the kill(1) command, or a system reboot.

The following is an example of unloading identities:

 $ ssh-add -D
 All identities removed.

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

 $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;

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 $HOME/.dt/sessions/sessionexit file to terminate an agent at logout. See dtsession(1X) for more details.

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

 
[View full width]
#!/usr/bin/ksh
 # Eliminate the agent for the session
 if [ -x /usr/bin/ssh-agent ]; then
 if  /usr/bin/ssh-add -D >/dev/null 2>&1; then
        eval '/usr/bin/ssh-agent -k'
 fi
 else if [ -x /opt/OBSDssh/bin/ssh-agent ]; then
 if /opt/OBSDssh/bin/ssh-agent -D >/dev/null 2>&1;
 then
                 eval '/opt/OBSDssh/bin/ssh-agent -k'
 fi
         fi
 fi

Agent Risks

Agents are not without their risks. The only access control to the agent socket is the private user-owned directory in the /tmp 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.

The following is an example of a user agent compromise by the superuser:

 
[View full width]
# 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)

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.

The following is an example of a simple agent forwarding session:

 
[View full width]
hook $ eval '/usr/bin/ssh-agent'
 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

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

Appendix A. Secure Shell Usage

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 docs.sun.com and the following man pages:

Client Usage

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.

Connecting to a Host

The following example shows the basic syntax of the ssh(1) command:

[View full width]
$ ssh remote
 user@remote's password: password
 Last login: Wed Dec 18 00:12:38 2002 from someplace
 Sun Microsystems Inc.    SunOS 5.9       Generic
 May 2002
 remote $

Executing a Command on a Remote Host

The ssh(1) command's remote job form is ssh remote_host job, as shown in the following example:

Note

Shell variables are expanded on the local side, unless they are escaped.

 $ ssh remote cat /var/sadm/system/admin/CLUSTER
 user@remote's password: password
 CLUSTER=SUNWCXall

Copying a File

The scp(1) command's form is scp source destination. The following example demonstrates how to copy a local file to a remote host:

 
[View full width]
$ scp 816-5241.pdf remote:/tmp
 user@remote's password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00

The following example demonstrates how to copy a file from a remote host to a local host:

$ scp remote:/tmp/816-5241.pdf /tmp
 user@remote's password: password
 816-5241.pdf         100%
 |*****************************| 87388      00:00

Using Identity Keys

This section contains examples of generating, registering, and using user identities. Agents for passphrase-free logins are also covered.

Generating an Identity

Note

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

The following example shows how to generate Protocol 2 RSA keys:

$ 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

The following example shows how to generate a 2048-bit DSA key:

 
[View full width]
$ 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

The following example shows how to generate a Secure Shell Protocol 1 RSA key:

$ 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
Registering an Identity

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

 $ cd ~/.ssh
 $ touch authorized_keys
 $ chmod 744 authorized_keys
 $ cat id_rsa.pub >> authorized_keys
Using the Identity

The following example shows how to use the key:

 
[View full width]
$ ssh remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 16:48:43 2002 from server
 Sun Microsystems Inc.   SunOS 5.9       Generic
 May 2002
 remote $

Using Agents

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

Setting Up Agents

The following example shows how to set up an agent within the parent shell:

 $ eval `ssh-agent`
 Agent pid 16867
 $
Loading Agents

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

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

The following example shows how to add a specific identity:

 $ ssh-add .ssh/remote
 Enter passphrase for .ssh/remote: passphrase
 Identity added: .ssh/remote(.ssh/remote)
Listing Agent Identities

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

The following example shows the output for listing an empty agent:

 $ ssh-add -l
 The agent has no identities.

The following example shows the output for listing an agent with one identity loaded:

$ 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)
Removing Agent Identities

The following example shows how to unload a specific identity:

 $ ssh-add -d id_rsa
 Identity removed: id_rsa(id_rsa.pub)

The following example shows how to unload all of the identities in an agent:

 $ ssh-add -D
 All identities removed.
Stopping the Agent

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

 $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 16867 killed;

Forwarding Ports

Note

The Solaris Secure Shell software defaults to having port forwarding disabled on the server.

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

 $ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
 Connection to localhost closed by foreign host.
Setting Up Local Forwarding

The form for local forwarding is ssh -L 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's port, 23 (Telnet):

 
[View full width]
$ ssh -L 2020:remote:23 remote
 Enter passphrase for key '/home/beth/.ssh/id_rsa'
: passphrase
 Last login: Thu Dec 19 20:12:14 2002 from server
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 remote $

The following example shows how to test the forwarded port:

$ telnet localhost 2020
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'. 


 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 $
Setting Up Remote Forwarding

The form for remote forwarding ssh -R 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's port, 2020, to port 23 (Telnet):

$ ssh -R 2020:remote:23 remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: 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 '^]'.
 login: user
 Password: password
 Last login: Tue Dec 17 21:16:25 from remote
 Sun Microsystems Inc.  SunOS 5.9       Generic
 May 2002
 server $
Enabling X Forwarding

Note

The Solaris Secure Shell software defaults to having X forwarding disabled on the server.

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

 ForwardX11 yes
 XAuthLocation /usr/X/bin/xauth

The following example shows how to enable X forwarding by using the -X option:

 $ ssh -X host

Checking the $DISPLAY Variable

The following example shows how to check the $DISPLAY variable:

$ echo $DISPLAY
 :0.0
 $ ssh remote
 Enter passphrase for key '/home/user/.ssh/id_rsa'
: 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

Using Proxies

Note

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

The following example shows how to use a proxy:

$ ssh -o'ProxyCommand=/usr/lib/ssh
/ssh-socks5-proxy-connect \


 -h socks-gw -p 1080 dmz.foo.com 22' dmz.foo.com
 user@dmz'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
 $

Locating Client Configuration Files

The individual client configuration file and keys are kept in the .ssh directory in the user's home directory. The global client configuration file, ssh_config, resides with the other server configuration files and keys.

The following example shows the contents of the ~/.ssh directory:

/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


Server Usage

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.

Starting the Server

The following example shows how to start the Solaris Secure Shell daemon:

 # /etc/init.d/sshd start

The following example shows how to start OpenSSH:

 # /etc/init.d/openssh.server start

Stopping the Server

The following example shows how to stop the Solaris Secure Shell daemon:

# /etc/init.d/sshd stop

The following example shows how to stop OpenSSH:

 # /etc/init.d/openssh.server stop

Generating New Server Host Keys

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:

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

Note

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.

Supporting TCP Wrappers

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

Note

TCP Wrappers support is optional in OpenSSH. See "TCP Wrappers" on page 33 for instructions on its inclusion.

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

 # echo "sshd: ALL" >> /etc/hosts.deny
 # echo "sshd: LOCAL" >> /etc/hosts.allow

This example shows how to test local access:

 
[View full width]
$ ssh server
 user@server'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.

This example shows how to test remote access by attempting a connection from a remote host outside of the server's local domain:

 
[View full width]
$ ssh server.remote
 ssh_exchange_identification: Connection closed by
 remote host

Reference

SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5)

NAME
sshd_config - OpenSSH SSH daemon configuration file

SYNOPSIS
/etc/ssh/sshd_config

DESCRIPTION
sshd(8) reads configuration data from /etc/ssh/sshd_config (or the file
specified with -f on the command line). The file contains keyword-argu-
ment pairs, one per line. Lines starting with `#' and empty lines are
interpreted as comments. Arguments may optionally be enclosed in double
quotes (") in order to represent arguments containing spaces.

The possible keywords and their meanings are as follows (note that key-
words are case-insensitive and arguments are case-sensitive):

AcceptEnv
Specifies what environment variables sent by the client will be
copied into the session's environ(7). See SendEnv in
ssh_config(5) for how to configure the client. Note that envi-
ronment passing is only supported for protocol 2. Variables are
specified by name, which may contain the wildcard characters `*'
and `?'. Multiple environment variables may be separated by
whitespace or spread across multiple AcceptEnv directives. Be
warned that some environment variables could be used to bypass
restricted user environments. For this reason, care should be
taken in the use of this directive. The default is not to accept
any environment variables.

AddressFamily
Specifies which address family should be used by sshd(8). Valid
arguments are ``any'', ``inet'' (use IPv4 only), or ``inet6''
(use IPv6 only). The default is ``any''.

AllowGroups
This keyword can be followed by a list of group name patterns,
separated by spaces. If specified, login is allowed only for
users whose primary group or supplementary group list matches one
of the patterns. Only group names are valid; a numerical group
ID is not recognized. By default, login is allowed for all
groups. The allow/deny directives are processed in the following
order: DenyUsers, AllowUsers, DenyGroups, and finally
AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is
``yes''. Note that disabling TCP forwarding does not improve se-
curity unless users are also denied shell access, as they can al-
ways install their own forwarders.

AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for us-
er names that match one of the patterns. Only user names are
valid; a numerical user ID is not recognized. By default, login
is allowed for all users. If the pattern takes the form US-
ER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts. The allow/deny
directives are processed in the following order: DenyUsers,
AllowUsers, DenyGroups, and finally AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

AuthorizedKeysFile
Specifies the file that contains the public keys that can be used
for user authentication. AuthorizedKeysFile may contain tokens
of the form %T which are substituted during connection setup.
The following tokens are defined: %% is replaced by a literal
'%', %h is replaced by the home directory of the user being au-
thenticated, and %u is replaced by the username of that user.
After expansion, AuthorizedKeysFile is taken to be an absolute
path or one relative to the user's home directory. The default
is ``.ssh/authorized_keys''.

Banner The contents of the specified file are sent to the remote user
before authentication is allowed. If the argument is ``none''
then no banner is displayed. This option is only available for
protocol version 2. By default, no banner is displayed.

ChallengeResponseAuthentication
Specifies whether challenge-response authentication is allowed.
All authentication styles from login.conf(5) are supported. The
default is ``yes''.

Ciphers
Specifies the ciphers allowed for protocol version 2. Multiple
ciphers must be comma-separated. The supported ciphers are
``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'', ``aes256-cbc'',
``aes128-ctr'', ``aes192-ctr'', ``aes256-ctr'', ``arcfour128'',
``arcfour256'', ``arcfour'', ``blowfish-cbc'', and
``cast128-cbc''. The default is:

aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
aes192-ctr,aes256-ctr

ClientAliveCountMax
Sets the number of client alive messages (see below) which may be
sent without sshd(8) receiving any messages back from the client.
If this threshold is reached while client alive messages are be-
ing sent, sshd will disconnect the client, terminating the ses-
sion. It is important to note that the use of client alive mes-
sages is very different from TCPKeepAlive (below). The client
alive messages are sent through the encrypted channel and there-
fore will not be spoofable. The TCP keepalive option enabled by
TCPKeepAlive is spoofable. The client alive mechanism is valu-
able when the client or server depend on knowing when a connec-
tion has become inactive.

The default value is 3. If ClientAliveInterval (see below) is
set to 15, and ClientAliveCountMax is left at the default, unre-
sponsive SSH clients will be disconnected after approximately 45
seconds. This option applies to protocol version 2 only.

ClientAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the client, sshd(8) will send a message
through the encrypted channel to request a response from the
client. The default is 0, indicating that these messages will
not be sent to the client. This option applies to protocol ver-
sion 2 only.

Compression
Specifies whether compression is allowed, or delayed until the
user has authenticated successfully. The argument must be
``yes'', ``delayed'', or ``no''. The default is ``delayed''.

DenyGroups
This keyword can be followed by a list of group name patterns,
separated by spaces. Login is disallowed for users whose primary
group or supplementary group list matches one of the patterns.
Only group names are valid; a numerical group ID is not recog-
nized. By default, login is allowed for all groups. The al-
low/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

DenyUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. Login is disallowed for user names that
match one of the patterns. Only user names are valid; a numeri-
cal user ID is not recognized. By default, login is allowed for
all users. If the pattern takes the form USER@HOST then USER and
HOST are separately checked, restricting logins to particular
users from particular hosts. The allow/deny directives are pro-
cessed in the following order: DenyUsers, AllowUsers, DenyGroups,
and finally AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

ForceCommand
Forces the execution of the command specified by ForceCommand,
ignoring any command supplied by the client. The command is in-
voked by using the user's login shell with the -c option. This
applies to shell, command, or subsystem execution. It is most
useful inside a Match block. The command originally supplied by
the client is available in the SSH_ORIGINAL_COMMAND environment
variable.

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports
forwarded for the client. By default, sshd(8) binds remote port
forwardings to the loopback address. This prevents other remote
hosts from connecting to forwarded ports. GatewayPorts can be
used to specify that sshd should allow remote port forwardings to
bind to non-loopback addresses, thus allowing other hosts to con-
nect. The argument may be ``no'' to force remote port forward-
ings to be available to the local host only, ``yes'' to force re-
mote port forwardings to bind to the wildcard address, or
``clientspecified'' to allow the client to select the address to
which the forwarding is bound. The default is ``no''.

GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed.
The default is ``no''. Note that this option applies to protocol
version 2 only.

GSSAPICleanupCredentials
Specifies whether to automatically destroy the user's credentials
cache on logout. The default is ``yes''. Note that this option
applies to protocol version 2 only.

HostbasedAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication to-
gether with successful public key client host authentication is
allowed (host-based authentication). This option is similar to
RhostsRSAAuthentication and applies to protocol version 2 only.
The default is ``no''.

HostbasedUsesNameFromPacketOnly
Specifies whether or not the server will attempt to perform a re-
verse name lookup when matching the name in the ~/.shosts,
~/.rhosts, and /etc/hosts.equiv files during
HostbasedAuthentication. A setting of ``yes'' means that sshd(8)
uses the name supplied by the client rather than attempting to
resolve the name from the TCP connection itself. The default is
``no''.

HostKey
Specifies a file containing a private host key used by SSH. The
default is /etc/ssh/ssh_host_key for protocol version 1, and
/etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
tocol version 2. Note that sshd(8) will refuse to use a file if
it is group/world-accessible. It is possible to have multiple
host key files. ``rsa1'' keys are used for version 1 and ``dsa''
or ``rsa'' are used for version 2 of the SSH protocol.

IgnoreRhosts
Specifies that .rhosts and .shosts files will not be used in
RhostsRSAAuthentication or HostbasedAuthentication.

/etc/hosts.equiv and /etc/shosts.equiv are still used. The de-
fault is ``yes''.

IgnoreUserKnownHosts
Specifies whether sshd(8) should ignore the user's
~/.ssh/known_hosts during RhostsRSAAuthentication or
HostbasedAuthentication. The default is ``no''.

KerberosAuthentication
Specifies whether the password provided by the user for
PasswordAuthentication will be validated through the Kerberos
KDC. To use this option, the server needs a Kerberos servtab
which allows the verification of the KDC's identity. The default
is ``no''.

KerberosGetAFSToken
If AFS is active and the user has a Kerberos 5 TGT, attempt to
acquire an AFS token before accessing the user's home directory.
The default is ``no''.

KerberosOrLocalPasswd
If password authentication through Kerberos fails then the pass-
word will be validated via any additional local mechanism such as
/etc/passwd. The default is ``yes''.

KerberosTicketCleanup
Specifies whether to automatically destroy the user's ticket
cache file on logout. The default is ``yes''.

KeyRegenerationInterval
In protocol version 1, the ephemeral server key is automatically
regenerated after this many seconds (if it has been used). The
purpose of regeneration is to prevent decrypting captured ses-
sions by later breaking into the machine and stealing the keys.
The key is never stored anywhere. If the value is 0, the key is
never regenerated. The default is 3600 (seconds).

ListenAddress
Specifies the local addresses sshd(8) should listen on. The fol-
lowing forms may be used:

ListenAddress host|IPv4_addr|IPv6_addr
ListenAddress host|IPv4_addr:port
ListenAddress [host|IPv6_addr]:port

If port is not specified, sshd will listen on the address and all
prior Port options specified. The default is to listen on all
local addresses. Multiple ListenAddress options are permitted.
Additionally, any Port options must precede this option for non-
port qualified addresses.

LoginGraceTime
The server disconnects after this time if the user has not suc-
cessfully logged in. If the value is 0, there is no time limit.
The default is 120 seconds.

LogLevel
Gives the verbosity level that is used when logging messages from
sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO,
VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
higher levels of debugging output. Logging with a DEBUG level
violates the privacy of users and is not recommended.

MACs Specifies the available MAC (message authentication code) algo-
rithms. The MAC algorithm is used in protocol version 2 for data
integrity protection. Multiple algorithms must be comma-separat-
ed. The default is:

hmac-md5,hmac-sha1,[email protected],
hmac-ripemd160,hmac-sha1-96,hmac-md5-96

Match Introduces a conditional block. If all of the criteria on the
Match line are satisfied, the keywords on the following lines
override those set in the global section of the config file, un-
til either another Match line or the end of the file. The argu-
ments to Match are one or more criteria-pattern pairs. The
available criteria are User, Group, Host, and Address. Only a
subset of keywords may be used on the lines following a Match
keyword. Available keywords are AllowTcpForwarding, Banner,
ForceCommand, GatewayPorts, GSSApiAuthentication,
KbdInteractiveAuthentication, KerberosAuthentication,
PasswordAuthentication, PermitOpen, RhostsRSAAuthentication,
RSAAuthentication, X11DisplayOffset, X11Forwarding, and
X11UseLocalHost.

MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.

MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the SSH daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime ex-
pires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the
three colon separated values ``start:rate:full'' (e.g.
"10:30:60"). sshd(8) will refuse connection attempts with a
probability of ``rate/100'' (30%) if there are currently
``start'' (10) unauthenticated connections. The probability in-
creases linearly and all connection attempts are refused if the
number of unauthenticated connections reaches ``full'' (60).

PasswordAuthentication
Specifies whether password authentication is allowed. The de-
fault is ``yes''.

PermitEmptyPasswords
When password authentication is allowed, it specifies whether the
server allows login to accounts with empty password strings. The
default is ``no''.

PermitOpen
Specifies the destinations to which TCP port forwarding is per-
mitted. The forwarding specification must be one of the follow-
ing forms:

PermitOpen host:port
PermitOpen IPv4_addr:port
PermitOpen [IPv6_addr]:port

Multiple forwards may be specified by separating them with
whitespace. An argument of ``any'' can be used to remove all re-
strictions and permit any forwarding requests. By default all
port forwarding requests are permitted.

PermitRootLogin
Specifies whether root can log in using ssh(1). The argument
must be ``yes'', ``without-password'', ``forced-commands-only'',
or ``no''. The default is ``yes''.

If this option is set to ``without-password'', password authenti-
cation is disabled for root.

If this option is set to ``forced-commands-only'', root login
with public key authentication will be allowed, but only if the
command option has been specified (which may be useful for taking
remote backups even if root login is normally not allowed). All
other authentication methods are disabled for root.

If this option is set to ``no'', root is not allowed to log in.

PermitTunnel
Specifies whether tun(4) device forwarding is allowed. The argu-
ment must be ``yes'', ``point-to-point'' (layer 3), ``ethernet''
(layer 2), or ``no''. Specifying ``yes'' permits both ``point-
to-point'' and ``ethernet''. The default is ``no''.

PermitUserEnvironment
Specifies whether ~/.ssh/environment and environment= options in
~/.ssh/authorized_keys are processed by sshd(8). The default is
``no''. Enabling environment processing may enable users to by-
pass access restrictions in some configurations using mechanisms
such as LD_PRELOAD.

PidFile
Specifies the file that contains the process ID of the SSH dae-
mon. The default is /var/run/sshd.pid.

Port Specifies the port number that sshd(8) listens on. The default
is 22. Multiple options of this type are permitted. See also
ListenAddress.

PrintLastLog
Specifies whether sshd(8) should print the date and time of the
last user login when a user logs in interactively. The default
is ``yes''.

PrintMotd
Specifies whether sshd(8) should print /etc/motd when a user logs
in interactively. (On some systems it is also printed by the
shell, /etc/profile, or equivalent.) The default is ``yes''.

Protocol
Specifies the protocol versions sshd(8) supports. The possible
values are `1' and `2'. Multiple versions must be comma-separat-
ed. The default is ``2,1''. Note that the order of the protocol
list does not indicate preference, because the client selects
among multiple protocol versions offered by the server. Specify-
ing ``2,1'' is identical to ``1,2''.

PubkeyAuthentication
Specifies whether public key authentication is allowed. The de-
fault is ``yes''. Note that this option applies to protocol ver-
sion 2 only.

RhostsRSAAuthentication
Specifies whether rhosts or /etc/hosts.equiv authentication to-
gether with successful RSA host authentication is allowed. The
default is ``no''. This option applies to protocol version 1 on-
ly.

RSAAuthentication
Specifies whether pure RSA authentication is allowed. The de-
fault is ``yes''. This option applies to protocol version 1 on-
ly.

ServerKeyBits
Defines the number of bits in the ephemeral protocol version 1
server key. The minimum value is 512, and the default is 768.

StrictModes
Specifies whether sshd(8) should check file modes and ownership
of the user's files and home directory before accepting login.
This is normally desirable because novices sometimes accidentally
leave their directory or files world-writable. The default is
``yes''.

Subsystem
Configures an external subsystem (e.g. file transfer daemon).
Arguments should be a subsystem name and a command (with optional
arguments) to execute upon subsystem request. The command
sftp-server(8) implements the ``sftp'' file transfer subsystem.
By default no subsystems are defined. Note that this option ap-
plies to protocol version 2 only.

SyslogFacility
Gives the facility code that is used when logging messages from
sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0,
LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The de-
fault is AUTH.

TCPKeepAlive
Specifies whether the system should send TCP keepalive messages
to the other side. If they are sent, death of the connection or
crash of one of the machines will be properly noticed. However,
this means that connections will die if the route is down tem-
porarily, and some people find it annoying. On the other hand,
if TCP keepalives are not sent, sessions may hang indefinitely on
the server, leaving ``ghost'' users and consuming server re-
sources.

The default is ``yes'' (to send TCP keepalive messages), and the
server will notice if the network goes down or the client host
crashes. This avoids infinitely hanging sessions.

To disable TCP keepalive messages, the value should be set to
``no''.

UseDNS Specifies whether sshd(8) should look up the remote host name and
check that the resolved host name for the remote IP address maps
back to the very same IP address. The default is ``yes''.

UseLogin
Specifies whether login(1) is used for interactive login ses-
sions. The default is ``no''. Note that login(1) is never used
for remote command execution. Note also, that if this is en-
abled, X11Forwarding will be disabled because login(1) does not
know how to handle xauth(1) cookies. If UsePrivilegeSeparation
is specified, it will be disabled after authentication.

UsePrivilegeSeparation
Specifies whether sshd(8) separates privileges by creating an un-
privileged child process to deal with incoming network traffic.
After successful authentication, another process will be created
that has the privilege of the authenticated user. The goal of
privilege separation is to prevent privilege escalation by con-
taining any corruption within the unprivileged processes. The
default is ``yes''.

X11DisplayOffset
Specifies the first display number available for sshd(8)'s X11
forwarding. This prevents sshd from interfering with real X11
servers. The default is 10.

X11Forwarding
Specifies whether X11 forwarding is permitted. The argument must
be ``yes'' or ``no''. The default is ``no''.

When X11 forwarding is enabled, there may be additional exposure
to the server and to client displays if the sshd(8) proxy display
is configured to listen on the wildcard address (see
X11UseLocalhost below), though this is not the default. Addi-
tionally, the authentication spoofing and authentication data
verification and substitution occur on the client side. The se-
curity risk of using X11 forwarding is that the client's X11 dis-
play server may be exposed to attack when the SSH client requests
forwarding (see the warnings for ForwardX11 in ssh_config(5)). A
system administrator may have a stance in which they want to pro-
tect clients that may expose themselves to attack by unwittingly
requesting X11 forwarding, which can warrant a ``no'' setting.

Note that disabling X11 forwarding does not prevent users from
forwarding X11 traffic, as users can always install their own
forwarders. X11 forwarding is automatically disabled if UseLogin
is enabled.

X11UseLocalhost
Specifies whether sshd(8) should bind the X11 forwarding server
to the loopback address or to the wildcard address. By default,
sshd binds the forwarding server to the loopback address and sets
the hostname part of the DISPLAY environment variable to
``localhost''. This prevents remote hosts from connecting to the
proxy display. However, some older X11 clients may not function
with this configuration. X11UseLocalhost may be set to ``no'' to
specify that the forwarding server should be bound to the wild-
card address. The argument must be ``yes'' or ``no''. The de-
fault is ``yes''.

XAuthLocation
Specifies the full pathname of the xauth(1) program. The default
is /usr/X11R6/bin/xauth.

TIME FORMATS
sshd(8) command-line arguments and configuration file options that speci-
fy time may be expressed using a sequence of the form: time[qualifier],
where time is a positive integer value and qualifier is one of the fol-
lowing:

<none> seconds
s | S seconds
m | M minutes
h | H hours
d | D days
w | W weeks

Each member of the sequence is added together to calculate the total time
value.

Time format examples:

600 600 seconds (10 minutes)
10m 10 minutes
1h30m 1 hour 30 minutes (90 minutes)

FILES
/etc/ssh/sshd_config
Contains configuration data for sshd(8). This file should be
writable by root only, but it is recommended (though not neces-
sary) that it be world-readable.

SEE ALSO
sshd(8)

AUTHORS
OpenSSH is a derivative of the original and free ssh 1.2.12 release by
Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
de Raadt and Dug Song removed many bugs, re-added newer features and cre-
ated OpenSSH. Markus Friedl contributed the support for SSH protocol
versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support
for privilege separation.

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Aug 09, 2012] Speaking UNIX: The best-kept secrets of UNIX power users by Martin Streicher, Software Developer, Pixel, Byte, and Comma

May 25, 2010 | IBM DeveloperWorld

Shhh . . . secrets about SSH

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 "dot directory", 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.

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

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

Each block in ~/.ssh/config configures one or more hosts. Separate individual blocks with a blank line. This block uses four options: Host, HostName, IdentityFile, and User. Host establishes a nickname for the machine specified by HostName. A nickname allows you to type ssh worker instead of ssh worker.example.com. Moreover, the IdentityFile and User options dictate how to log in to worker. 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: 

ssh [email protected] -i ~/.ssh/id_rsa_worker

A powerful but little-known option is ControlMaster. If set, multiple SSH sessions to the same host share a single connection. 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. ControlMaster is so handy, you'll likely want to enable it for every machine. That's accomplished easily enough with the host wildcard, *: 

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

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

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 ls ~/.ssh and look at the host name portion of the control socket (%h).

The SSH configuration file is so expansive, it too has its own man page. Type man ssh_config to see all possible options. And here'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: 

$ ssh example.com -L 5000:localhost:3306

This command says, "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 'localhost.'" Because localhost is interpreted on example.com as the tunnel is established, localhost is example.com. With the outbound tunnel-formally called a local forward-established, local clients can connect to port 5000 and talk to the MySQL server running on example.com.

This is the general form of tunneling:

$ ssh proxyhost localport:targethost:targetport

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

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

$ ssh user@proxyhost -R proxyport:targethosttargetport

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

$ ssh [email protected] -R 8080:localhost:80

The command reads, "Connect to example.com as joe, and connect the remote port 8080 to local port 80." This command gives users on example.com a tunnel to Joe's machine. A remote user can connect to 8080 to hit the Web server on Joe's machine.

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

Martin Streicher is a freelance Ruby on Rails developer and the former Editor-in-Chief of Linux Magazine. 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 [email protected].

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least 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

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE 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.

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

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

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. We do not warrant the correctness of the information provided or its fitness for any purpose. 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. This site is perfectly usable without Javascript.

Last modified: March 12, 2019