所属类别：网络技术

文章作者：wdl111_1

特别推荐：免费发布信息 承包关键词~~抢爆了！^HOT!

Configuring OpenSSH for theSolaris™ Operating EnvironmentNetworks have never been secure. As the demand on open networks for remoteaccess has grown, the risks of compromised systems and accounts has kept pace.Tools for securing networks, such as OpenSSH, were developed to counter thethreats of password theft, session hijacking, and other network attacks. However,these tools come with the price of planning, configuration, and integration. Thisarticle provides recommendations for configuring and managing OpenSSH.Specifically, this article deals with client and server configuration, key handling, andthe integration of OpenSSH into existing environments that run the Solaris™Operating Environment (Solaris OE.) For details about the compilation ofOpenSSH’s components, consult the Sun BluePrints™ OnLine article “Building andDeploying OpenSSH for the Solaris Operating Environment” (July, 2001).This article does not discuss general OpenSSH usage. Consult the OpenSSH manpages and SSH, The Secure Shell for that information. For technical details about theunderlying protocols, refer to the Internet Drafts of the Secure Shell (SECSH)working group.This article was drafted using OpenSSH 2.9p2.Security PolicyThe primary purpose of security policy is to inform those responsible for protectingassets such as hardware, software, and data of their obligations. Managementestablishes a security policy based on the risks it is willing to tolerate. The policyitself does not set goals, but serves as a bridge between management’s goals and thetechnical implementation.2 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002OpenSSH was designed to be a secure replacement for unsafe network commandssuch as rlogin, rsh, rcp, telnet, and ftp. The way you configure OpenSSHshould reflect a site’s local security policy. For example, you might consider whetherpassword authentication is appropriate, or whether a more rigorous two-factor(public-key based) authentication is required. Further, you might consider whetherthe policy allows OpenSSH to tunnel TCP and X windows connections and whetherit allows for remote access to internal web sites. Again, OpenSSH configurationshould match local policy.If a site does not have a security policy, one should be crafted before configuringOpenSSH. For guidance on crafting a security policy, consult the references in theBibliography.ConfigurationOpenSSH has many capabilities not all of which are appropiate depending on yourlocal policy. Configure OpenSSH to conform to your policy. OpenSSH is configuredin three places: compilation (compile time), server configuration, and clientconfiguration. Compile time configuration covers basic details such as whichentropy source to use, the location of configuration files, and whether binaries areSUID. Compile time configuration has the advantage that it can not be overriden.Server configuration concerns how and to whom the OpenSSH server shouldpresent itself on the network. Server configuration details include which protocolsand authentication methods are offered, which users have been granted access, andhow much logging of each connection should be done. Server configuration can notbe overridden by the client. Client configuration covers which server tocommunicate with, server verification, and user ease of use.Configuration in order of precedence is: software compile time, the serverconfiguration file (sshd_config), client command line options, individual clientconfiguration file (~/.ssh/config), and the global client configuration file(ssh_config). The location of sshd_config and ssh_config vary dependingupon compile time options. They are usually located in /etc, /etc/ssh, or/usr/local/etc.A defensive in-depth strategy of setting the preferred configuration redundantly atcompile time, server configuration, and client configuration is recommended. Thisreduces the chances that a single accidental misconfiguration will weaken theintegrity of the system.Example client and server configuration files that document the recommendedconfiguration are presented later in this document. Not all of the options presentedin the files are described in this document.Recommendations 3RecommendationsOpenSSH offers a number of features to protect network connections between twohosts. There are choices of protocol, authentication method, port forwarding, useraccess, and network access. When setting up OpenSSH, you will have to make tradeoffs between security, ease of use, and legacy compatibility. The choices you makedepend on local security policy.Protocol SupportThere are two major versions of the secure shell protocol: SSH1 and SSH2. SSH1 wasthe first protocol developed and has been replaced with SSH2. It is highlyrecommended that you disable the use of SSH1 since the protocol has been found tohave several vulnerabilities including packet insertion attacks and password lengthdetermination. In sshd_config and ssh_config, set Protocol to 2, as follows.For legacy client and server support, allow SSH1 but set the default to SSH2, asfollows.Unfortunately, many legacy clients and servers only support SSH1. Considerupgrading legacy clients and servers to those that support SSH2. If you wish toaudit installed base of ssh servers, consider using scanssh by Niels Provos. It isdesigned to scan a network and report the version strings of any ssh servers found.(You can also use ssh-keyscan and shell scripting to accomplish the same thing ina much less efficient manner.)# Protocol 2 only is recommended.Protocol 2# Enable legacy support but default is Protocol 2.Protocol 2,14 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002Network AccessBy default, the OpenSSH server daemon listens to all network interfaces. Forworkstations and other systems where accessibility is desired on all interfaces, this isnot a problem. For architectures where a single interface is dedicated to managementor administration, it is preferable not to expose OpenSSH to the other networks.Limit network access with ListenAddress in sshd_config as shown here.To further narrow down what the server will listen to (for example, a specificaddress range or single host), use either a host-based firewall or a tool liketcpwrappers.Note C OpenSSH does support the use of TCP wrappers but support needs to becompiled into the server. Consult the build documentation of OpenSSH forinformation.Connection ForwardingOpenSSH can create a secure tunnel to provide some protection for insecureprotocols. This is referred to as connection forwarding and only works for TCPbasedconnections. During connection forwarding, a local TCP port is opened andOpenSSH waits for a connection. When OpenSSH receives a connection, it forwardsthe data to the OpenSSH server on the other end. The server then sends the data toits final destination. Responses follow the same process, in reverse.Note C Data is protected only until it reaches the OpenSSH server. After that, it ishandled the same as normal network traffic.Connection forwarding is useful for protecting commonly used, noncryptographicprotocols like IMAP, which is used for email. It can also be used to provide remoteusers with access to internal resources such as news, email, and web access. If policyis such that remote users are to be granted access to these resources, enableconnection forwarding.There are two caveats with connection forwarding. Firstly, connection forwarding isan all or nothing mechanism. Once forwarding is allowed, the client can forwardany port to any location on the remote side. If this is an issue, consider using hostbasedfirewalls on the OpenSSH server to limit connections. Secondly, because traffic# Listen only on management networkListenAddress 192.168.0.10Recommendations 5that travels through connection forwarding is encrypted, neither a firewall, nor anintrusion detection system can detect when abnormal events occur. The OpenSSHserver on the remote side is traffic agnostic. It does not know if data coming out is anormal IMAP request for a message or if it is buffer overflow exploit against theIMAP server. Plan firewall and intrusion detection sensors accordingly. Add thefollowing to sshd_config to allow TCP forwarding.An example of a client forwarding in ssh_config.Gateway PortsGateway ports work in conjunction with connection forwarding. Normally,connection forwarding allows only the local host to send data to the other side of aconnection. By using a gateway port, you enable other machines to connect andforward data. In effect, gateway ports create a tunnel from one network to anothernetwork. This is highly risky and in general should always be disabled. For example,an user sitting in an airport connected over a 802.11b wireless link with gatewayports turned on and a local forward to an internal web server would allow everyonein the immediate vicinity access to the web server. Set the following in bothsshd_config and ssh_config.X ForwardingOpenSSH can also securely tunnel X traffic. Because the X protocol travels in theclear, it is vulnerable to sniffing and hijacking. OpenSSH emulates an X server on theremote side and passes traffic back through the tunnel to the local client. In addition# Server configurationAllowTCPForwarding yes# client configuration# Allow remote users access to an internal web server.LocalForward 8080 www.corp.acme.com:80# Server and client configurationGatewayPorts no6 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002to its usefulness for remote users, this can also help decrease the potential for usersto use xhost + to disable all access controls. Add the following lines to bothsshd_config and ssh_config.The following is an example of the values of $DISPLAY on a local host and over anX forwarded tunnel.User AccessSome sites require that a banner be displayed once users connect to a system, butbefore they log in. If this is required, set the banner to /etc/issue insshd_config, as shown in the following example, so only one banner exists for thewhole system.The default login grace time is ten minutes. This value is too high. Considerreducing it in the sshd_config to thirty or sixty seconds as shown here.User access control lists can be specified in OpenSSH; however, no part of the SolarisOE honors this access control list (ACL). The two available options are to allow onlyspecified users access, or to specifically deny a user access. The default is to allow# Server and client configurationX11Forwarding yeshost $ echo $DISPLAY:0.0host $ ssh remotehostuser@remotehost’s password:XXXXXXXXremotehost $ echo $DISPLAYremotehost:11.0Banner /etc/issueLoginGraceTime 60Recommendations 7anyone access. You can also specify access with group membership. Note that thegroups options only apply to the primary group (the group listed in /etc/passwd).An example of both allow and deny ACLs in sshd_config appears as follows.By default, the root user can log in using OpenSSH. This is fine for systems withoutuser accounts. However, disabling root logins and requiring administrators to use suto root is more secure and leaves an audit trail. If you have remote jobs that run asroot, you can configure OpenSSH to only execute scripts. This requires the use oftwo-factor (key-based) authentication. If root logins are required at your site, onlyuse key-based authentication as discussed later in this article. To set this up, add thefollowing to sshd_config.AuthenticationOpenSSH supports multiple forms of authentication: the traditional login andpassword, two- factor (public-key-based), and host-based. Each method has differentbenefits. Password authentication fits well in existing structures. Two-factorauthentication offers improved security, although with higher maintenance costs.Host-based authentication provides the most convenience, although it is extremelyunsafe and easily abused.Password authentication is the most common way for systems to authenticate users.The drawback to this method is that passwords can be shoulder-surfed, guessedwith dictionaries, and sniffed in transit across the network. While OpenSSH protectspasswords by encrypting them, this only prevents sniffing while they are in transit,and can’t do anything to minimize the effects of other threats. To counter otherthreats, OpenSSH provides two-factor or key- based authentication.# Allow sysadmin staffAllowGroups staff# Or limit a particular user’s access off a machineDenyUsers kaw alex# Only add one of these settings.# Forces sysadmins to su.PermitRootLogin no# If remote jobs require root priviledges.PermitRootLogin forced-commands-only8 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002Key-based authentication is a challenge and response system which is grounded inthe mathematics of public-key cryptography. There are essentially two elements: apublic key that resides on all servers the user will access, and a private key that onlythe user knows. The private key is additionally protected by a passphrase. Thissystem is more secure than passwords alone because in addition to being based on apassphrase the user knows, it is also based on something the user has in theirpossession, the private key.The system works roughly as follows. OpenSSH generates a key pair, stores thepublic key on the OpenSSH server, and leaves an encrypted version of the privatekey on the user’s machine with a passphrase. When the user connects to the server,OpenSSH prompts the user for a passphrase to decrypt the private key. TheOpenSSH client and server then go through a challenge and response to prove thatthe two keys are related. If the server agrees that user really does have the privatekey, it grants the user access. The private key is never stored on the server ortransmitted to it, and the public key is useless without the private key, and viceversa. For a system to be subverted (leaving out program flaws like bugs), someonewould have to acquire a copy of the private key and the passphrase.Because private keys are often stored on NFS home directories, good passphrases arecritical to the success of this approach. Examples of bad phrases might includesimple sentences with no punctuation and no capitalization, or extremely commonphrases like “to be or not to be.” Examples of good phrases include phrases orwords the user can easily remember and won’t write down. If a user looses apassphrase, you will need to generate a new key pair, as a passphrase cannot berecovered. Further, passphrases tend to be resistant to shoulder surfing due to theirlength.Host-based authentication trusts a connection based on where it comes from. This isvery unsafe and easily abused. Rlogin and rsh also use this method ofauthentication as denoted by their dependence on .rhosts files.Key Handling 9It is recommended that sites disable any semblance of host-based authentication.Sites that support a large number of internal users should consider staying withpasswords to reduce training costs. Sites with remote users and sites that need toautomate jobs should consider using key-based authentication. Add the following tosshd_config for the preceding recommendations.Key HandlingPublic-key cryptography is used in two places: server identification and two-factorauthentication. This means that there are keys to be managed, protected,transported, and eventually destroyed. Key handling is the largest obstacle to thewide-scale deployment of OpenSSH. Because OpenSSH was designed as a point-topointsolution with no public-key infrastructure in place, all key operations must bedone manually. This is not a problem for small deployments; however, the problemdoes not scale.Because they are the foundation for systems security, keys must be handled withcare. If private keys are divulged, security is compromised because the systemappears to be secure when, in fact, it is not.Host KeysServer identification is accomplished by a host key pair. The openssh.serverinit script, which you can find on the Sun BluePrints website, generates a key set ifit cannot find a host key. This key set is used to identify the server to the client. Theprivate key remains private to ensure the integrity of the system. The client# Disable unsafe hosts based authenticationHostbasedAuthentication noRhostsAuthentication noIgnoreRhosts yes# Empty passwords are trivial to guessPermitEmptyPasswords no# For internal servers, passwords ok. Bastion hosts - no.PasswordAuthentication yes# For remote access, automated jobs, and advanced usersPubkeyAuthentication yes10 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002downloads the public key and compares it to its copy in known_hosts. If the key isdifferent than it is expected to be, a warning message is printed and the connectionis refused. The following is an example of this warning.The problem is how to get the public host key to the client in the first place. Anotherproblem is what to do when the public host key has been regenerated due to loss,server upgrade, or compromise. Having multiple users call support because of thepreceding warning message could create quite a support headache. Further, havingusers change keys manually would be even less desirable.The client configuration option StrictHostKeyChecking controls how the clientreacts to new hosts keys. If you set this option to yes, OpenSSH will not makeconnections to unknown servers. If you set the option to ask, OpenSSH will promptusers to accept a new host key if the server is unknown. If you set the option to no,OpenSSH will add new host keys without prompting users. The no option settingwill allow connections to servers with modified host keys.The easiest solution is to simply disable StrictHostKeyChecking by setting it tono. Blindly accepting new keys allows man-in-the-middle attacks and is notrecommended. If your users can be trusted to act responsibly, then set the option toask. Users can manually verify the host key by comparing the value inknown_hosts to the value ssh_host_key.pub, ssh_host_dsa_key.pub, orssh_host_rsa_key.pub depending on the protocol and public cryptographicsystem used to connect. If the values don’t match, something odd has happened.This could be caused by an active attack or possibly just a server reinstallation.Respond according to your local policy.$ /opt/OBSDssh/bin/ssh some_host@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!Someone could be eavesdropping on you right now (man-in-themiddleattack)!It is also possible that the RSA host key has just been changed.The fingerprint for the RSA key sent by the remote host isc3:6f:30:ff:84:e1:e0:d6:ef:28:e7:76:f2:49:ea:be.Please contact your system administrator.Add correct host key in /export/home/user/.ssh/known_hosts toget ridof this message.Offending key in /export/home/user/.ssh/known_hosts:2RSA host key for some_host has changed and you have requestedstrict checking.$Key Handling 11Another solution is distribute a known_hosts file to users; however, it is difficult todo this in a secure fashion. You must decide how to securely collect public host keysand how to securely distribute the file to the users. Again, there are problems ofscalability with any solution. Fortunately, changes to host keys should be infrequent.The most secure method of gathering keys is to log in to every server and manuallycopy the public host key to a portable medium such as a floppy disk, CD-RW, orsmartcard. For sites with a large number of machines, or during the first deploymentof OpenSSH, this burden is significant. Alternatively, you can configure a client withStrictHostKeyChecking set to no, access every single host, copy the public hostkey, exit, and then compare the key with the value in known_hosts. Display awarning message for any server with a differing key. This can be automated usingKorn shell, PERL, or some other scripting language.Ssh-keyscan can also be used to generate a list of host keys. The risk is getting thehost key of a compromised machine. None of the solutions are perfect. There aresome serious tradeoffs between convience and security. At the minimum, setStrictHostKeyChecking to ask and train your users to check the host keys.A novel use of ssh-keyscan is to regularly check for altered keys. At routineintervals, probe the servers and check if keys have been altered. This can providewarning of an intrusion or a non-logged installation.With public host keys gathered, you must decide how to securely distribute the fileto users. An easy solution is to integrate the file into the deployment packaging suchas the OBSDssh package. The file can be placed on an ftp or http server. Alsodistribute a preferably signed hash (MD5 or SHA-1) of the file so the user can verifythe integrity of the file. (OpenSSL has the capability of performing the hashes.)For sites with a public-key infrastructure, a pretty good privacy installation, or aGnu privacy-guard installation, distribute the file and its hash cryptographicallysigned.With the hassle of users seeing an unfamiliar warning about a changed host key,there is the temptation to archive the public and private host key pairs onto asystem. The key pairs would be replaced after a system was reinstalled or replaced.This is risky and not recommended. Any system storing the keys would be atempting target and if it was comprised all keys within it would also becompromised. It is better to deal with the occasional host key change through usereducation and notices of reinstallation. If it is necessary to archive keys, store themoffline, in encrypted format, and in secure storage such as a safe.In the event of a server compromise, destroy host keys. An attacker with knowledgeof the private portion of a host key could impersonate the host and perform a manin-the-middle attack.12 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002User Identity KeysUsers may optionally authenticate themselves using cryptographic keys. Public-keyauthentication is more secure than password authentication for following reasons.First, the private-identity key is protected by a passphrase which may be muchlonger than the eight character password limit. Second, neither the passphrase northe private key is ever transmitted to the server. There is no secret information tosnoop off the network. Third, in order to compromise an account, the intruder mustfirst gather the private key stored on the users machine and determine thepassphrase in the user’s head. Fourth and finally, computer generated cryptographickeys are infeasible to guess and not subject to dictionary attacks.Note C Poor passphrases are susceptible to dictionary attacks, so good password/passphrase discipline is still required.For public-key authentication, the user creates an identity key pair withssh-keygen. The resulting public key, either id_dsa.pub or id_rsa.pub, is thenstored in ~/.ssh/authorized_keys2. For hosts where users are unable to placetheir public keys, such as bastion hosts, public keys may be emailed to the ITsupport staff. Have the staff verify out of band the key fingerprint. Once public keysare placed into ~/.ssh/authorized_keys2, users are no longer prompted for apassword. Instead, they will be prompted for the passphrase for the private key.Integration 13The following is an example an user identity key generation.User-identity private keys still need some protection even when they are storedencrypted. It is preferable not to store them on NFS shares where they can be copiedunnoticed. If this is not avoidable, stress the importance of good passphrases lest thekeys are decrypted offline through a passphrase dictionary attack. In the event ofportable computer theft, revoke all effected keys by removing them from theauthorized_keys file and generate new keys. In case of a server compromise,check for the addition of backdoor user identity keys.IntegrationIntegrating OpenSSH into daily usage is not difficult. It can be used as astraightforward method for replacing rlogin, rsh, and telnet for interactive hostlogins that requires minimal user retraining. It can also provide added security toremote jobs and file transfers, it can tunnel through proxy servers to secureconnections to outside the corporate intranet, and it can add single-sign on typeconvenience. You can also add your desired local configuration to the OBSDsshpackage for easy deployment./home/user/.ssh $ /opt/OBSDssh/bin/ssh-keygen -b 2048 -t dsaGenerating public/private dsa key pair.Enter file in which to save the key (/home/user/.ssh/id_dsa):Enter passphrase (empty for nopassphrase):XXXXXXXXXXXXXXXXXXXXXXXXEnter same passphrase again: XXXXXXXXXXXXXXXXXXXXXXXXYour 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:9b:9c:c4:fb:30:66:25:46:5b:b1:95:d9:a1:90:86:f9 user@host/home/user/.ssh $ lsid_dsa id_dsa.pub known_hosts2 random_seed/home/user/.ssh $ cat id_dsa.pub > authorized_keys/home/user/.ssh $ chmod 600 authorized_keys/home/user/.ssh $ /opt/OBSDssh/bin/ssh remote_hostEnter passphrase for key ’/home/user/.ssh/id_dsa’:XXXXXXXXXXXXXXXXLast login: Sun Jul 15 13:37:45 2001 from hostSun Microsystems Inc. SunOS 5.8 Generic February 2000remote_host /home/user $ ^DConnection to remote_host closed./home/user/.ssh $14 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002ssh-agentAgents perform an action on the behalf of something else. Ssh-agent performscryptographic operations on the behalf of an ssh process. Instead of an ssh processknowing the key to a remote host, the agent holds the key and does the work.Ssh-agent works by setting two environment variables: SSH_AUTH_SOCK andSSH_AGENT_PID. Because environment variables are inherited by children, settingup ssh-agent when first logging on to an environment like CDE means all terminalwindow shells will know about the agent and use it if possible. The followingexample shows a system with ssh-agent running.A ssh-agent can do nothing until a key is loaded into it. Once a key is loaded, allof the ssh processes that are aware of that agent may use that key. This provides aform of single signon. The drawback is that if a shell is compromised, whateveraccess the loaded keys granted may be abused. Agent functionality is used toautomate actions and make user’s lives easier.Ssh-add is used to add and list keys (referred to as identities by OpenSSH.)Ssh-agent can remove all keys held in memory and can only add a single key at atime. The following is an example of identity management.Autonomous ActionsYou can use OpenSSH to greatly improve the security of automated scripts and filetransfers. However, note that any kind of unattended authentication still presentssecurity risks. It is recommended that you use plain-text public-key authentication(keys are not protected by a passphrase.) The file permissions of the keys must behost $ env grep SSHSH_AUTH_SOCK=/tmp/ssh-PNq12519/agent.12519SSH_AGENT_PID=12520host $ ssh-addNeed passphrase for /home/user/.ssh/identityEnter passphrase for user@host Identity added: /home/user/.ssh/identity (user@host)host /opt/OBSDssh $ bin/ssh-add -l2048 d1:0b:59:c3:ff:8a:20:ff:98:84:15:98:ff:63:e8:41 user@host(RSA1)host $ bin/ssh-add -D All identities removed.host $ bin/ssh-add -lThe agent has no identities.Integration 15strict to ensure that others cannot read them. Even with this obvious flaw, thisscheme is more secure than host-based authentication and embedding passwordsinto scripts.This process requires more setup than the traditionally insecure method of .rhostsor /etc/host.equiv. You must generate a keyfile with ssh-keygen and distributeit to the remote hosts and the script calling host. Next, replace rsh calls with sshcalls as follows.Then, replace rcp calls with scp calls as follows.Sites desiring a more secure approach should use agents. At the system boot time, auser would provide the passphrases needed. This scheme would not work in alights-out style environment.Keys do need to be protected. Where security is a concern, load them by hand toprevent tampering. For sites when scalability is the largest concern, place a copy ofthe keys on your JumpStart™ server and copy them at installation time.Common Desktop Environment (CDE)A limited form of single sign on can be accomplished with ssh-agent, an Xwindows-based passphrase requestor, and some shell code in a user’s~/.dtprofile. Users will enter their passphrases once and will then be able to login to any host that honors the key from any local shell window. The downside is thatthe security of the system is limited by the screensaver password and by uservigilance never to leave an unattended, unlocked session.A fairly simple X passphrase requestor is x11-ssh-askpass available athttp://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/. The toolis simple to build and easy to install. After building the tool, integrate it intoOpenSSH by installing it as ssh-askpass in /libexec. You canrsh host -l user ssh host -i keyfile -l user rcp file user@host:scp -i keyfile file user@host:16 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002also integrate this tool into the deployment mechanism. An updated version ofmakeOpenSSHPackage.ksh will add x11-ssh-askpass if it is present during theOBSDssh package creation.The following are instructions for integration.The following code fragment is needed in the ~/.dtprofile. When the users log into a CDE session, x11-ssh-askpass (ssh-askpass) prompts them for thepassphrases to their keys. If users have multiple keys to add, then successive calls tossh-add with the keys identity strings will be needed.ProxiesYou can integrate OpenSSH with a SOCKS proxy with the runsocks command.Unfortunately, this requires the user to type a long command line or requires thecreation of a small shell script. The following is an example proxy connection shellscript.$ su -# cp x11-ssh-askpass /usr/local/ssh/libexec/ssh-askpass# cd /usr/local/ssh/libexec# chmod 555 ssh-askpass# chown root:other ssh-askpass# This example is specific to OBSDssh# ssh agent support# if /opt/OBSDssh/bin/ssh-agent does not exist, then do not run.if [ -f /opt/OBSDssh/bin/ssh-agent ]; theneval `/opt/OBSDssh/bin/ssh-agent‘# add keys here. Need one ssh-add per key. Consult the man page.# Only add keys if the X passphrase requestor is present.if [ -x /opt/OBSDssh/libexec/ssh-askpass ]; then/opt/OBSDssh/bin/ssh-addfifi#!/usr/bin/ksh# Some sites may require SOCKS_SERVER and LD_LIBRARY_PATHexplicitly set/usr/bin/env SOCKS_SERVER=sockserver:1080 LD_LIBRARY_PATH=/usr/local/socks/lib \/usr/local/socks/bin/runsocks /opt/OBSDssh/bin/sshremote.host.comSummary 17Within OpenSSH, there is also the ProxyCommand user configuration option. Youcan use this option to specify a helper application that OpenSSH will read and writeto for accessing the remote host. The creation of this application is outside the scopeof this article. Consult the man page for ssh(1) and SSH, The Secure Shell for moredetails.makeOpenSSHPackage.kshYou can add local configuration files to the OBSDssh package by replacingsshd_config.out with your server configuration and by replacingssh_config.out with your global client configuration. Then, run themakeOpenSSHPackage.ksh script to generate the OBSDssh package. You can alsomodify this script to include x11-ssh-askpass as ssh-askpass into the packageas well. (Find the section where the sftp-server executable is packaged.)SummaryThe network was never secure. OpenSSH provides strong authentication, protectednetwork connections, support for wrapping legacy protocols, and improved remoteX windows security. The price of this protection is careful consideration ofconfiguration details and the issues with key handling. Being aware of thedifficulties should provide a successful integration of OpenSSH into the enterprise.Consider disabling unsafe network services such as telnetd, ftpd, rlogind, andrshd after the deployment of OpenSSH.18 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002Appendix AExample server configuration## Example sshd_config with recommended server defaults.## Protocol two for securityProtocol 2# Only if legacy clients are an issue# If legacy SSH version one support is turned on, there areother# configuration options to consider. Consult the sshd(8)manpage.#Protocol 2,1## If your jurisdiction requires a banner#Banner /etc/issue## Allow encrypted tunnels for insecure protocolsAllowTCPForwarding yesGatewayPorts noX11Forwarding yesX11DisplayOffset 10XAuthLocation /usr/X/bin/xauth#KeepAlive yes## Turn on for BSM auditing. Feature is not compatible with Xforwarding.# Do NOT turn on with a version of OpenSSH previous to 3.0.2 duea local root exploit.UseLogin no## Allow sftp access.Subsystem sftp /opt/OBSDssh/libexec/sftp-serverAppendix A 19## Authentication methods# Do not allow weak rhosts style authenticationHostbasedAuthentication noRhostsAuthentication noIgnoreRhosts yes# Do not allow empty passwordsPermitEmptyPasswords no# Force users to su to rootPermitRootLogin no# If machine lives on the Internet, public key onlyPasswordAuthentication noPubkeyAuthentication yes# Sixty seconds to loginLoginGraceTime 60## User management details# Login shell should check for email and display Message Of TheDayCheckMail noPrintMotd noPrintLastLog yes# Prevent tampering of user’s ~/.ssh due to poor permissionsStrictModes yes### Legacy Protocol one options# Use only if supporting legacy clients#KeyRegenerationInterval 1800#ServerKeyBits 768#RSAAuthentication yes#RhostsRSAAuthentication no20 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002Example client configuration## Example ~/.ssh/config with recommended user defaults.## standard host with a nicknameHost fooHostName foo.eng.acme.com## standard host with a port forwardedHost testHostName test.corp.acme.com# Allow HTTP access to the corporate internal serverLocalForward 8080 www.corp.acme.com:80## Host with only legacy SSH1 supportHost legacyHostName legacy.acme.comProtocol 1User oldtimer## Global defaultsHost *# Only allow SSH version two protocol except where specificallylisted.Protocol 2# After three connection attempts give upConnectionAttempts 3# Allow X display forwardingForwardX11 yes# Do not allow other hosts to connect to forwarded portsGatewayPorts no# Check if host key has changed due to DNS spoofingCheckHostIP yes# Never use the insecure rshFallBackToRsh no# If encountering a new host, ask about accepting the host keyStrictHostKeyChecking ask# Solaris location of xauthXAuthLocation /usr/X/bin/xauth# Detect if unable to connect to the server temporarilyKeepAlive yesBibliography 21BibliographyBarret and Silverman, SSH The Secure Shell, 2001. O’Reilly & Associates.CORE SDI S. A., “SSH Insertion Attack,”http://www.corest.com/pressroom/advisories_desplegado.php?idxsection=10&idx=131.Griffin, Wesley. “Storing SSH Host Keys in DNS,”draft-ietf-secsh-dns-key-format-00.txt, NAI Labs, Glenwood, MD, May2001.Knoble, Jim, x11-ssh-askpass,http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/NEC Corporation, SOCKS, http://www.socks.nec.com/Noordergraaf, Alex, “Solaris Operating Environment Minimization for Security: ASimple, Reproducible and Secure Application Installment Methodology - Updatedfor Solaris 8 Operating Environment” Sun BluePrints OnLine, November 2000,http://www.sun.com/blueprints/1100/minimize-updt1.pdfOrnaghi, Alberto and Valleri, Marco, Ettercaphttp://ettercap.sourceforge.netProvos, Niels, scanssh, http://www.monkey.org/~provos/scansshReid, Jason and Watson, Keith, “Building and Deploying OpenSSH for the SolarisOperating Environment,” Sun BluePrints OnLine, July 2001,http://www.sun.com/blueprints/0701/openSSH.pdfRSA Laboratories, RSA Cryptography FAQ,http://www.rsa.com/rsalabs/faq/index.htmlSECSH IETF Working Group,http://www.ietf.org/html.charters/secsh-charter.htmlSolar Designer, “Passive Analysis of SSH Traffic,” http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txtvan der Lubbe, Jan C A, Basic Methods of Cryptography, 1998. Cambridge UniversityPressWeise, Joel, “Public Key Infrastructure Overview,” Sun BluePrints OnLine, August2001, http://www.sun.com/blueprints/0801/publickey.pdf22 Configuring OpenSSH for the Solaris™ Operating Environment • January 2002本文出自 51CTO.COM技术博客

....