 
Join Date: Aug 2013
Posts: 511
 |
Anonymity: Secure Shell, Tutorial to creating a SSH
1. About Secure Shell
This section should answer general questions about Secure Shell and what it does and doesn't do. Click here for the contents of this section. 1.1. What is Secure Shell? To paraphrase the README file: Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for telnet, rlogin, rsh, and rcp. For SSH2, there is a replacement for FTP: sftp. Additionally, Secure Shell provides secure X connections and secure forwarding of arbitrary TCP connections. You can also use Secure Shell as a tool for things like rsync and secure network backups. The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways. It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends in the clear). The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions which are transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users. There are two versions of Secure Shell available: SSH1 and SSH2. This FAQ does its best to distinguish when the situation calls for the difference between the two. 1.2 How widespread is its use? The most current figures available are over 2 million Secure Shell users in over 60 countries. This is not an accurate amount, but an estimate. It also does not necessarily include the different implementations of Secure Shell for different operating systems. Note that this includes both SSH1 and SSH2 implementations. 1.3 What protocols does Secure Shell use? It should be noted that the SSH1 and SSH2 protocols are in fact different and not compatible with each other. For the SSH1 protocol, you can find this information in an old IETF draft available here. It is also available with the latest source distribution for SSH1 at ftp.ssh.com/pub/ssh/ssh-1.2.27.tar.gz. For the SSH2 protocol, you can find this information in the SSH2 IETF drafts: http://www.ietf.org/ids.by.wg/secsh.html The fifth IETF draft for Secure Shell, Generic Message Exchange Authentication For Secure Shell is no longer available and expired after 6 months. 1.4 What encryption algorithms does Secure Shell use? Secure Shell uses the following ciphers for encryption: Cipher SSH1 SSH2 DES yes no 3DES yes yes IDEA yes no Blowfish yes yes Twofish no yes Arcfour no yes Cast128-cbc no yes Secure Shell uses the following ciphers for authentication: Cipher SSH1 SSH2 RSA yes no DSA no yes Ciphers may be added or deleted later depending on implementations. 1.5 How does Secure Shell authenticate? Secure Shell authenticates using one or more of the following: Password (the /etc/passwd or /etc/shadow in UNIX) User public key (RSA or DSA, depending on the release) Kerberos (for SSH1) Hostbased (.rhosts or /etc/hosts.equiv in SSH1 or public key in SSH2) Since there is quite a big demand for it, there are some patches available for various forms of authentication. It is up to the authors to make those available. If you wish to have a particular type of authentication in Secure Shell, please submit a feature request to the SSH Secure Shell team. For OpenSSH features, please contact the OpenSSH team. 1.6 What does Secure Shell protect against? Secure Shell protects against (again, from the README): IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside. IP source routing, where a host can pretend that an IP packet comes from another, trusted host. DNS spoofing, where an attacker forges name server records Interception of cleartext passwords and other data by intermediate hosts Manipulation of data by people in control of intermediate hosts Attacks based on listening to X authentication data and spoofed connection to the X11 server In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypt or play back the traffic, or hijack the connection. The above only holds if you actually use encryption. Secure Shell does have an option to use encryption of type "none" this is only for debugging purposes, and should not be used. 1.7 What doesn't Secure Shell protect against? Secure Shell will not help you with anything that compromises your host's security in some other way. Once an attacker has gained root access to a machine, he can then subvert ssh, too. If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your home directory is exported via NFS. 1.8 What is the difference between SSH1 and SSH2? The difference between SSH1 and SSH2 is they are two entirely different protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1 uses server and host keys to authenticate systems where SSH2 only uses host keys. SSH2 is a complete rewrite of the protocol, and it does not use the same networking implementation that SSH1 does. Also, SSH2 is more secure. Because of the different protocol implementation, they are not compatible. In a nutshell, SSH2 is a rewrite of the SSH1 protocol, with improvements to security, performance, and portability. 1.9 Who maintains Secure Shell? SSH Communications Security, is the developer of Secure Shell (secsh) protocol and maintains the releases of SSH1 and SSH2. The IETF maintains the Secure Shell standards, which is vendor-neutral. The standards are currently in draft form; once there are two independent implementations available, then they can be submitted as an RFC. There are currently several implementors, both freeware and commercial, of Secure Shell. 1.10 Can I run Secure Shell legally? Most likely. It depends on your country's laws for cryptography and which version of Secure Shell that you're using. Check out the information on licensing, cryptography laws, and patents on cryptographic algorithms below. 1.10.1 Licensing The licensing for SSH2 as of the 2.1.0 release has been completely revised. You can use Secure Shell for free if you are a university user (student, professor, staff, etc) or if you are using it for non-commercial use (playing games, checking personal email, etc.). For any commercial use, you need to have the appropriate license for Secure Shell. Click here for the current licensing information and click here for an FAQ on the licensing from SSH Communications Security. The UNIX version of ssh 1.2.27 may be used freely for non-commercial purposes and may not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license. The definition of "commercial use" is generally interpreted as using ssh for anything that would generate financial gain, such as logging into a customers system to do administration, or providing ssh as a secure login to your partners or vendors. Other licensing is developer-dependent. 1.10.2 Cryptography laws In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a special permit. If you are in the United States, you should be aware that, while ssh was written outside the United States using information publicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once it has been imported, including putting it on a ftp site. Contact the Bureau of Export Administration, which is under the Department of Commerce. There's a really good link that keeps up to date with the Wassenaar Agreement and the cryptography laws throughout the world. Check out Bert-Jaap Koops Crypto Law Survey. 1.10.3 Patents on Cryptographic algorithms The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linking against the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US. You may need to obtain licenses for commercial use of IDEA; ssh can be configured without IDEA and works perfectly fine without it. For information on software patents in general, see the League for Programming Freedom's homepage at http://lpf.ai.mit.edu/. 1.11 What operating systems does Secure Shell run on? From the Secure Shell home page: For SSH1 and the current release of SSH2 (2.2.0), check out the portability page at http://www.ssh.com/ssh/portability.html. For compatability with OpenSSH, check out http://www.openssh.com/portable.html. There are also non-commercial ports of Secure Shell for SSH1 including PalmOS, Windows, Macintosh, OS/2, BeOS, WindowsCE, Java, and OpenVMS. See section 2 of this FAQ for information on how to get Secure Shell. 1.12 . Shouldn't I be using only SSH2? Maintainer's note: Since this brought up an interesting discussion on the mailing list, it seems to be a good idea to incorporate some of the helpful information that folks brought up. Thanks! Also, if someone has a better way to organize this section, please let me know. The SSH1 protocol is not being developed anymore, as SSH2 is being developed as the standard. Even if you are not using SSH2, many folks are establishing a path towards it. With three implementations (and growing) of SSH2 currently in the works, there is growing support (especially with the SSH2 protocol in IETF draft). However, there are arguments for and against running SSH1. Note: If you have any additional arguments either way, I'll post them. -AC There are structural weaknesses in SSH1 which leave it open to additional attacks SSH1 is subject to a man-in-the-middle attack SSH1 has more supported platforms SSH1 supports .rhosts authentication (it's against the draft for SSH2 SSH1 has more diverse authentication support (AFS, Kerberos, etc.) Performance for SSH2 is not equal to SSH1 Rick Moen posted this software matrix on the mailing list that shows software from diverse authors will perhaps partially explain protocol 1.5's persistence: Highest protocol version supported in software that is: Servers Straight Proprietary Gratis-Usage (non-commercial) Unconditional Gratis-usage Open Source [1] OpenVMS - - - 1.5 OS/2 - 1.5 none none UNIX 2.0 2.0 none 2.0 Win32 - 2.0 none 2.0 Clients Straight Proprietary Gratis-Usage (non-commercial) Unconditional Gratis-usage Open Source [1] Amiga OS 1.5 1.5 none none BeOS - 1.5 none none Java - - none 1.5 [2] Macintosh 2.0 - 1.5 none OpenVMS - - - 1.5 OS/2 2.0 1.5 none none PalmOS - - 1.5 none UNIX 2.0 2.0 1.5 2.0 Win16 2.0 1.4 none none Win32 2.0 2.0 1.5 2.0 WinCE 1.5 none - none [1] As is defined by the Open Source Initiative at http://www.opensource.org/osd.html. The three columns leftwards are breakdowns of all non-open-source categories, i.e., different classes of proprietary licences. [2] Mats Andersson says MindTerm will soon support secsh 2.0. Diane Yi of the Beckman Institute had some slides that compare the protocols: http://www.beckman.uiuc.edu/biss/sec...02/tsld001.htm If you are installing a daemon, check to make sure your remote clients are connecting to you with the right version of Secure Shell. An SSH1 daemon will only work with SSH1 clients. An SSH2 daemon will work with SSH2 clients. However, an SSH2 daemon built with SSH1 compability will support both SSH1 and SSH2 clients. For more information on building SSH2 with SSH1 compatibility, see Section 9.5. 2. Getting Secure Shell This section should give you information on where to pick up different implementations of Secure Shell. Click here for the contents of this section. 2.1. Where is the official Secure Shell distribution and mirror sites? If you're looking for the official release of Secure Shell, it is listed below. Remember that non-commercial users (Universities, non-profit, and personal use) is free of charge. Otherwise, SSH Secure Shell must be properly licensed. All official releases are signed, and now you can use DSS/DSA signatures to check for those of us who have to deal with the RSA patents *grumble* *grumble*. 2.1.1 Offical site The central site for distributing ssh is at SSH Communication Security. The application is available at ftp://ftp.ssh.com/pub/ssh/. If you wish to license SSH Secure Shell for either commercial or university distribution (remember, no cost to universities or non-profit organizations), please go to http://commerce.ssh.com Information on how to check signatures is available at ftp.ssh.com/pub/ssh/HOWTO-CHECK-SIGNATURES. Official releases of SSH1 are PGP-signed (RSA only), with the following key ID: Type Bits Key ID Date User ID RSA 1024 DCB9AE01 1995/04/24 Ssh distribution key <[email protected]> Key fingerprint = C8 90 C8 5A 08 F0 F5 FD 61 AF E6 FF CF D4 29 D9 Official releases of SSH2 are PGP-signed (both RSA and DSA), with the following key IDs *: Type Bits Key ID Date User ID RSA 2048 AFCA7459 1998/07/11 Ssh 2 Distribution Key <[email protected]> Key fingerprint = 2A 06 2C 83 F0 A6 72 52 3A 4D 4A FA 20 15 EE 74 DSA 1024 83FB127C 2000/06/13 Ssh 2 Distribution Key <[email protected]> Key fingerprint = A348 205D F1D8 2297 0A46 D961 ED7B 28CD 83FB 127C Note: These keys also use the [email protected] address for signing. 2.1.2 Mirrors Secure Shell is also available via anonymous ftp from the sites listed at http://www.ssh.com/ssh/download.html. Because they are updated regularly, it is too difficult to keep them up to date here. 2.2 How about getting other relatively free versions of Secure Shell? Here is a list of other implementations Secure Shell clients and servers. The official distribution from SSH Communications Security is not included with these downloads. Please note that they should interoperate with each other; however, this is developer-dependent. Please note that these distributions may or may not be actively maintained. The owners may not notify people if they are still maintaining the software, and it may or may not work. This information is up here for your information, and if you legally can run the software--to play with it. If you're looking for a really complete list of Secure Shell clients, take a look at Rick Moen's list at http://linuxmafia.com/pub/linux/security/ssh-clients. 2.2.1 UNIX Niels Mцller is developing a GPL'd C implementation of the ssh version 2 protocol. Pick up the latest release (which is currently at 0.9.13) at http://www.net.lut.ac.uk/psst/download.html. The folks from OpenBSD has also created a free Secure Shell implementation of SSH1 and SSH2. You can find it at http://www.openssh.com/. The ports are available for Linux, Solaris, FreedBSD, and many others. OpenSSH is part of the base OS for OpenBSD, just as rsh, telnet, ksh, etc are installed. If you download the ftp://ftp.openbsd.org/pub/OpenBSD/2..../base26.tar.gz you will find that ./usr/bin/ssh is one of the files included. In other words, it is part of the base tarball that everybody on every install gets. At the end of the install, one has the option of installing the usa based RSA implementation, the international RSA implementation, or no RSA implementation; in this last case, only protocol v2 will be used. (if installed, RSA gets retrieved via ftp to avoid patent problems). You can also get Bjoern Groenvall's ossh (an older freeware port of SSH1) at ftp://ftp.pdc.kth.se/pub/krypto/ossh/. 2.2.2 Java There are a couple of different Java implementations of Secure Shell. Cйdric Gourio's SSH1 java-applet - http://www.cl.cam.ac.uk/~fapp2/software/java-ssh/. Mindterm and Mindtunnel - http://www.mindbright.se/english/technology MindVNC, a Virtual Network Computer using SSH1 - http://www.mindbright.se/english/technology Java Telnet Application has an Secure Shell plugin - http://www.mud.de/se/jta/doc/plugins/SSH.html 2.2.3 Windows For some reason, a lot of people have created Secure Shell ports to Windows :-). This is the current list of Windows ports. Robert O'Callahan's TTSSH, SSH1 extension to TeraTerm client - http://www.zip.com.au/~roca/ttssh.html Gorden Chaffee's command line port of ssh1 and scp1 - http://bmrc.berkeley.edu/people/chaffee/winntutil.html Sergey Okhapkin's SSH1 and SSH2 servers and clients port to 32-bit Windows - http://www.lexa.ru/sos/ Corinna Vinschen has ported OpenSSH to Cygwin- ftp://ftp.franken.de/pub/win32/devel...Corinna/V1.1.1 PuTTY, Simon Tatham's 32-bit Windows (SSH 1 & 2) client - http://www.chiark.greenend.org.uk/~sgtatham/putty.html FiSSH, Mass Confusion's 32-bit SSH1 client for Windows - http://mit.edu/ssh/FiSSH Cynus Win32 port of Secure Shell 1.2.2 by Raju Mathur - http://reality.sgi.com/raju/software.html PenguiNet Secure Shell and Telnet client - http://www.siliconcircus.com/penguinet (Shareware) Cedomir Igaly's SSH1 Windows 16 and 32 bit clients are no longer available. 2.2.4 Macintosh NiftyTelnet 1.1 Secure Shell is Jonas Wallden's implementation of SSH1 for Macintosh. It is available at http://www.lysator.liu.se/~jonasw/freeware.html. MacSSH is an SSH2 implementation for Mac clients. You can find it at http://www.macssh.com. 2.2.5 OpenVMS There is David Jones' OpenVMS SSH1 server available at http://www.er6.eng.ohio-state.edu/~jonesd/ssh/. The OpenVMS SSH1 client is done by Christer Weinigel and Richard Levitte and is available at http://www.free.lp.se/fish/. 2.2.6 Handheld devices The ISAAC group released a version of the SSH1 client for the Palm Pilot, Top Gun ssh 1.2. It's available at http://www.isaac.cs.berkeley.edu/pilot/. Mov Software has released a port of SSH1 to WindowsCE called sshCE. You can register for beta testing at http://www.movsoftware.com/sshce.htm. Please note that this has been in "late beta testing" for over a year now, so we're not sure if this is actively being worked on. 2.2.7 BeOS The current BeOS R4 port of SSH1 for Intel and PowerPC platforms is available through Bebits at http://www.bebits.com/app/703. Also, check out the sshLogin client at http://www.bebits.com/app/746. 2.2.8 OS/2 The most current port of the SSH1 client to OS/2 is available at ftp://hobbes.nmsu.edu/pub/os2/apps/i...-1.2.27-b1.zip, which runs on OS/2 Warp 3+. There is also another Secure Shell program available at ftp://hobbes.nmsu.edu/pub/os2/apps/i.../sshos203.zip; however, we have no idea what it is. 2.2.9 DOS There's now a port of SSH1 to DOS (yes, Disk Operating System) available at http://www.vein.hu/~nagyd. 2.3 How about getting commerically supported versions of Secure Shell? There are three current commercial releases of Secure Shell. They are distributed by SSH Communication Security, F-Secure (formally Datafellows), and Van Dyke Software. 2.3.1 SSH Secure Shell SSH Secure Shell is available from http://www.ssh.com/ssh. The product includes clients for Windows (which integrates secure file transfer in a GUI) and UNIX (which includes a server that allows two simultaneous connetions), and server available for UNIX as well. Please contact SSH Communications Security directly for more information. 2.3.2 Van Dyke Software SecureCRT SecureCRT is available at http://www.vandyke.com/products/securecrt/. This Secure Shell client runs on Windows platforms and supports the SSH1 and SSH2 protocol. They also have SecureFX, a file transfer product that does FTP tunneling over SSH2. Please contact Van Dyke directly for more information. 2.3.3 F-Secure Tunnel and Terminal F-Secure Tunnel and Terminal is available at http://www.f-secure.com/products/cry...hy/f-sshtt.htm. It runs on UNIX, Windows, and Macintosh. It implements the SSH2 protocol, and does have a command-line scp for Windows. Please contact F-Secure directly for more information. 2.3.4 Appgate Client and Server Appgate provides a gateway for applications using a centralized database for authentication using Secure Shell. It works on Win16, Win32, UNIX, OS/2, and Macintosh. Go to http://www.appgate.com for more information. 2.3.5 EmTec ZOC EmTec's ZOC is a terminal emulator that supports Secure Shell. It runs on OS/2 and Windows 32-bit. For more information, please see http://www.emtec.com/zoc/. 3. Installing Secure Shell This section gives you basic information on how to install the Secure Shell distribution from SSH Communications Security. Click here for the contents of this section. 3.1. What is the latest version of Secure Shell? The latest version of SSH1 is 1.2.27, and SSH2 is 2.2.0. If you are not using the latest version, you may run into problems. The latest version of lsh is 0.9.14, and be aware that lsh is still in testing mode and is not ready for prime-time yet. 3.2. How do I install Secure Shell? To install Secure Shell (either SSH1 or SSH2), download the tar files and place in a directory (either /tmp or /usr/local/src). Then do the following: # gzip -dc ssh-2.2.0.tar.gz | tar -xvf - # cd ssh-2.2.0 # ./configure # make # make install Please read the INSTALL file for more specifc instructions on SSH1, and for SSH2, please read the README. If you run into any problems, check out the troubleshooting section before sending it to the Secure Shell mailing list. Note: You may have to use specific options with configure to get Secure Shell to work the way you want (with certain ciphers, using TCP Wrappers, socks support, etc.). 3.3 Does it make sense to install Secure Shell as a non-root user on UNIX? If you run the server, sshd or sshd2, as a user other than root then you can only login as that user. If you install the client, ssh or ssh2, non setuid root you will still be able to connect and login to remote servers, but you will not be able to use hostbased authentication. You can also start up sshd yourself as non-root, supplying the -p option so it binds to a non-privileged port (port number higher than 1024), and then connect from another system with ssh -p. This will only allow connections to your own account, and sshd will, as a rule, not be restarted when your machine reboots. You will have to decide whether this is useful for you or not. 3.4 Where do I get pre-compiled binaries for Secure Shell? Redhat RPMs: ssh-2.2.0 - ftp://ftp.ssh.com/pub/ssh/rpms. This includes both binaries (with and without X) and source ssh-2.0.11 - ftp://ftp.zedz.net/pub/cryptoI/linux/redhat/test_rpms OpenSSH - ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm Solaris 2.6, 2.7: ssh-1.2.27 with SDI patch - ftp://ftp.parc.xerox.com/pub/jean/so...g/5.6/sshsdi.Z pgp signature - ftp://ftp.parc.xerox.com/pub/jean/so...6/sshsdi.Z.asc SSH Communications Security and F-Secure also include binaries for several flavors of UNIX. 4. Running Secure Shell This section gives you basic information on how to run the clients and servers from SSH1 and SSH2. This covers the Secure Shell distribution from SSH Communications Security. Click here for the contents of this section. 4.1. How do I run SSH1? This part goes into some very basic usage about the latest release of SSH1, 1.2.27. If this doesn't answer your question, try the man pages that came with the distribution (Read the Fine Manual :-). 4.1.1 ssh1 To use ssh1 to login to a computer with the same username: $ ssh remote.example.org To use ssh1 to login to a computer with a different username: $ ssh -l username remote.example.org To use ssh1 to securely send a command to a remote system: $ ssh remote.example.org command You can also define the cipher, turn on compression, define configuration file location, forwarding, and many other things. For more information, check out the ssh1 man page. 4.1.2 scp1 To use scp1 to copy a file to a remote system: $ scp localdir/to/filelocation user@host:/dir/for/file To use scp1 to copy a remote file to the local system: $ scp user@host:/dir/for/file localdir/to/filelocation To keep the file attributes of the source file from the source host, use -p: $ scp -p user@host:/dir/for/file localdir/to/filelocation For more information, check out the scp1 man page. 4.1.3 sshd1 To run the sshd1, just type it on the command line (usually as root, unless you're not running an ssh daemon as root). # sshd You can also define the host key files, the configuration files, the port, and the number of bits in the server key. See the man page for more details. Note: To make sure the ssh daemon starts up whenever the system is rebooted, be sure to add it to your startup scripts. Do not try to start sshd from init. 4.1.4 ssh-agent1 To put public keys in memory, use ssh-agent. To run it by itself, it will run in the background and load your public key into memory: $ ssh-agent If you want to run it with an x-window (like xterm or dtterm), you can run it like so: $ ssh-agent xterm & Here's the man page. 4.1.5 ssh-add1 You can add other identities to ssh-agent using ssh-add. You can also list and delete identities with ssh-add (which should have been named ssh-identity manager :-). To add an identity: $ ssh-add identityfile If used without any file defined, it will automatically add the default identification file. See the man page for more details. 4.2. How do I run SSH2? This part goes into some very basic usage about the latest release of SSH2, 2.0.13. If this doesn't answer your question, like SSH1--try the man pages that came with the distribution. 4.2.1 ssh2 In ssh2, it uses similar syntax that ssh1 uses. To use ssh2 to login to a computer with the same username: $ ssh2 remote.example.org To use ssh2 to login to a computer with a different username: $ ssh2 -l username remote.example.org To use ssh2 to securely send a command to a remote system: $ ssh2 remote.example.org command You can play with more functionality on ssh2 than ssh1 like toggling the forwarding for the authentication agent and X traffic. Note that the options are different from ssh1. For more information, check out the ssh2 man page. 4.2.2 scp2 To use scp2 to copy a file to a remote system: $ scp2 localdir/to/filelocation user@host:/dir/for/file To use scp2 to copy a remote file to the local system: $ scp2 user@host:/dir/for/file localdir/to/filelocation To keep the file attributes of the source file from the source host, use -p: $ scp2 -p user@host:/dir/for/file localdir/to/filelocation Also note that scp2 has other functionality such as simulating a smv (secure move) command with the -u option. For more information, check out the scp2 man page. 4.2.3 sshd2 To run the sshd2, just type it on the command line (usually as root, unless you're not running an ssh daemon as root). # sshd2 You can also define the host key files, the configuration files, the port, and other options (there is no server key in sshd2). See the man page for more details. Note: To make sure the ssh daemon starts up whenever the system is rebooted, be sure to add it to your startup scripts. Do not try to start sshd from init. 4.2.4 ssh-agent2 To put public keys in memory for SSH2, use ssh-agent2. To run it by itself, it will run in the background and load your public key into memory: $ ssh-agent2 If you want to run it with an x-window (like xterm or dtterm), you can run it like so: $ ssh-agent2 xterm & Here's the man page. 4.2.5 ssh-add2 You can add other identities to ssh-agent2 using ssh-add2. You can also list and delete identities with ssh-add2 (which should have been named ssh-identity2 manager :-). To add an identity: $ ssh-add2 identityfile If used without any file defined, it will automatically add the default identification file. See the man page for more details. 4.2.6 sftp2 To transfer data using Secure Shell, use the sftp2 client. The syntax is: $ sftp2 remoteserver user The remote server should be running sshd2. See the man page for details. 4.3. How do I administer Secure Shell after I have the daemon running? The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with public key host authentication, the server needs to know the client's public key. For SSH1, you can collect these automatically each night using either make-ssh-known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://ftp.ssh.com/pub/ssh/contrib/. With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable). There will be more information later for managing host keys with SSH2. 4.4. How do I get hostbased authentication to work with SSH2? For SSH2 release earlier than 2.2, please upgrade. It's so much easier to get hostbased authentication working with 2.2 than the earlier releases. Most of this is from the FAQ that comes with the 2.2 distribution; however, I've made some more additions to this to make it easier. Megatron is the Secure Shell server into which you're trying to connect. MegatronUser is the username on the Server into which you'd like to login. Optimus is the machine running a Secure Shell client. OptimusUser is the username on the Client that you'd like to allow to login to the megatron as the Server User. Step 1. Of course, install Secure Shell on the Megatron and Optimus machines. Do not forget to install the hostkey. If your installation did this, or you already have a copy of your /etc/ssh2/hostkey and /etc/ssh2/hostkey.pub, you do not need to do this: # ssh-keygen2 -P /etc/ssh2/hostkey Step 2 - SSH2 Copy the Optimus's /etc/ssh2/hostkey.pub file over to Megatron and name it to /etc/ssh2/knownhosts/optimus.ssh.com.ssh-dss.pub. You'll want to use the long hostname (the fully qualified hostname). At least Linux can be a real pain if the system doesn't recognize the hostname as megatron.ssh.com and recognizes it as megatron. You can find this out while running sshd2 in verbose mode when trying to make connections. To make sure that Secure Shell finds your complete domain name, not just the hostname, you can make sure you change the following line in the configuration file /etc/ssh2/ssh2_config: DefaultDomain your.domain.here This gives Megatron Optimus's public key so Megatron can verify Optimus's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication. Step 3. On Megatron, create a file in the megatronUser's home directory named .shosts. The contents of this file should be the Optimus hostname, some tabs or spaces, and the optimusUser username. Contents of ~/.shosts: optimus.ssh.com optimusUser Be sure to chown and chmod the .shosts file. The .shosts file must be owned by the remote user and should be mode 0400. Step 4 - SSH2. Check the file /etc/ssh2/sshd2_config and make sure that AllowedAuthentications contains the word hostbased For example, it may read: AllowedAuthentications hostbased,passwd It doesn't matter what's in there, just make sure that the hostbased variable is in the list somewhere. If you had to modify the sshd2_config file, you'll have to HUP the sshd to make the change take effect. # kill -HUP `cat /var/run/sshd2_22.pid` Step 5. On Optimus, you need to make sure that you have the AllowedAuthentications field in /etc/ssh2/ssh2_config set to included hostbased. If hostbased is not in there, this will not work. Step 6. You should be all set. On Optimus, log in as the ClientUser and try this: $ ssh megatronUser@Server uptime You should get back the results of uptime run on the remote server. Note: The first time you run ssh to that particular server, you'll have to answer "yes" when asked if you want to connect to the server. This is because the local ssh doesn't yet have the remote server's Secure Shell public key. This will only happen the first time. Troubleshooting With SSH2, did you name the hostkey file appropriately? It should be /etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the short hostname or the long hostname. If you're not using DNS, you'll need to make sure you're /etc/hosts file has the long host name (FQDN) listed: myhost.example.com myhost Did you copy the hostkey properly? Did it get mangled when you copied it over? Check your spelling in the .shosts file. Make sure the .shosts file is owned by the megatronUser? Run the server with the -v flag (for ssh2). This is a great way to see if a hostkey file is missing, or if something is misconfigured. 4.5. How do I get user public key authentication to work with SSH2? From the FAQ in the 2.2 distribution (I'll add more to this later): In remote_host (this is the host where you want to connect to): Add the following line to file ~/.ssh2/authorization: key id_dsa_1024_a.pub #or whatever is your pub keys name In local_host (this is the host you want to connect from): Add the following line to ~/.ssh2/identification: idkey id_dsa_1024_a #or whatever is your private keys name You have to create your keypair in local_host, and transfer the .pub-part to remote_host to your $HOME/.ssh2/ there. Generate the keys using ssh-keygen (see 'man ssh-keygen' for details). 4.6. Can I run Secure Shell from inetd? Yes, you can. No, you generally shouldn't. And boy, do I hate this question When the Secure Shell daemon is started, it processes its configuration file and generates a cryptographic key. This can take several seconds, especially on a slow or busy server, and the startup time can be unacceptably long. However, as Mike Friedman writes: "What many people (including me) do is run a 'backup' sshd at a non-standard port out of inetd, for use just when the standalone sshd has failed. This gives you a way to login to restart the regular sshd (or to investigate why it won't start!), but the latter would still be what most users normally connect to (at the standard port 22)." If you decide to run Secure Shell via inetd: To reduce the startup time for SSH1, you can reduce the size of the key that is generated with the -b flag (e.g. "-b 512"). The default keysize is 768 bits, and a keysize of 512 bits should be small enough to reduce the startup time. This is not recommended, however, as a 512-bit key is significantly easier to break than a larger key. The key size cannot be altered at runtime with SSH2; a new server key must be generated with ssh-keygen2. When starting sshd from inetd, be sure to pass it the -i flag so it behaves properly. 5. Secure Shell and other applications This section gives you some information on how getting Secure Shell to work with other applications. Click here for the contents of this section. 5.1. Can I run backups over ssh? Yes. The easiest possible way to do this is: # tar cvf - | ssh user@host "dd of=/dev/tape" Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. You can use datbkr by David Cinege, which uses Secure Shell to do backups over an Secure Shell connection. You can get datbkr at http://www.psychosis.com/datbkr. You can also use rdist and rsync, which there is more information at below. 5.2. Can I use ssh to communicate across a firewall? Yes. All you need is an open port on the firewall and the sshd or sshd2 listening on the other side. Most people do this on port 22 (the standard port for Secure Shell), but if you have a BOFH, you can also tunnel through another open port through the firewall (I'm sure all those system admins love me now :-) by running a daemon on the remote side on a port that's allowed through a firewall, like SSL (port 443). Set up the remote daemon running sshd on port 443: # sshd -p 443 Then, on your local system, open a connection on port 443: $ ssh -p 443 remotehost.example.org You can also use Secure Shell to tunnel insecure traffic like POP, IMAP, and others through the firewall as well. 5.3. Can I use rdist or rsync with ssh? Yes. If you use rdist, don't forget to compile the path to ssh into it. Alternatively, you may specify the -P option so rdist uses ssh, and not rsh. If you use password authentication with rdist 6.1.2 through 6.1.5, you will need to apply the following patch to rdist to make it work: --- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996 +++ src/rshrcmd.c Tue Jun 11 16:52:05 1996 @@ -63,7 +63,7 @@ /* child. we use sp[1] to be stdin/stdout, and close sp[0]. */ (void) close(sp[0]); - if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) { + if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) { error("dup2 failed: %s.", SYSERR); _exit(255); } This also applies if you get a "Warning: Denied agent forwarding because the other end has too old version." error (which occurs if your client is 1.2.17 or later, and it connects to an older server). Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at http://rsync.samba.org/rsync. You can use the --rsh=/usr/local/bin/ssh option to use Secure Shell as a transport. 5.4. Can I use ssh to securely connect two subnets across the Internet? You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh-ppp-new.txt for a working solution. It's a good idea to enable compression for this. Another implementation of this is available at http://www.linuxdoc.org/HOWTO/mini/VPN.html. However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html . Also look into Magnus Lundstrцm's replacement for ssh-ppp in C for Linux, which is now being ported to other OS's. See http://detached.net/vpnstarter. The vpnstarter is more reliable (and easier to set up) than ssh-ppp. 5.5. Can I use ssh to securely forward UDP-based services, such as NFS or NIS? This is not currently implemented in SSH1 or SSH2. However, there is a general working solution for RPC-based services. This project uses Secure Shell to increase the security of RPC-based services; so far this has been implemented for NIS and NFS. You can download the latest version of this software from http://www.math.ualberta.ca/imaging/snfs/. More information is available at ftp://ftp.tu-chemnitz.de/pub/Local/i...rpc/README.RPC 5.6. Can I use ssh to protect services like FTP or POP? If you want to avoid sending FTP passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall. You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand. SSH1: Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost. Note: You need to use -g if you're forwarding to localhost (SSH1 only). Then, in another window, you do myhost$ ftp localhost 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in. This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd. For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV. Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping. SSH2: Just use sftp instead. :-) For POP, Stephane Bortzmeyer ([email protected]) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.internatif.org/pub/unix/gwpop/ . Or, you can use similar means for secure POP: myhost$ ssh -L 1234opserver.example.com:110 ssh-server Other services could be secured by similar means. 5.7. Can I use ssh across a Socks firewall? Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work. 5.8. Is there ssh support for AFS/Kerberos? There's two patches available for AFS in Secure Shell. See Section 6 of the Secure Shell FAQ. 5.9. Can I use TCP wrappers for added security on Secure Shell? Yes, the Secure Shell daemon can use TCP wrappers. Unlike other tcpwrapped services, the Secure Shell daemon is NOT run via inetd and tcpd (doing that will give "packet too long" errors). TCP wrapper support (also called "libwrap support") is compiled into the sshd binary and the sshd runs as a standalone daemon. To build Secure Shell with libwrap support, run ./configure with the --with-libwrap=PATH flag, where PATH is the full pathname to the libwrap.a file that you installed when you built the TCP wrappers. For example: ./configure --with-libwrap=/usr/local/lib/libwrap.a When you installed TCP wrappers, you should have kept the tcpd.h and libwrap.a files. Usually tcpd.h goes in /usr/local/include and libwrap.a goes in /usr/local/lib. By default, installing TCP wrappers doesn't install these two files, so you may need to grab the TCP wrappers source and recompile it, then install those two files. In the /etc/hosts.allow and /etc/hosts.deny files, make an entry for the Secure Shell daemon. Be sure that the name of the service matches the name of the sshd binary you're running. e.g. If you run the daemon as "sshd2" then the service must be named "sshd2", and if you run it as "sshd" then the service name must be "sshd" Here are some example hosts.allow entries. For more examples, check the hosts_access(5) man page that came with the TCP wrapper distribution. # Example 1 - Allow Secure Shell from this one subnet # Secure Shell daemon is started as /usr/local/sbin/sshd sshd: 192.168.1.0/255.255.255.0 # Example 2 - Allow Secure Shell access from two subnets # Secure Shell is started as /usr/sbin/sshd2 sshd2: 192.168.1.0/255.255.255.0 10.0.0.0/255.0.0.0 # Example 3 - Won't work because service name is wrong, unless # you really start your daemon as ssh instead of sshd! ssh: 10.0.0.0/255.0.0.0 See the TCP Wrappers documentation for more details. 5.10. How do I tunnel X through Secure Shell? To configure the sources and create an Secure Shell build that supports X forwarding: # ./configure --with-x Run make and make install normally. You'll also want to make sure your configuration file is set properly. Note that this is the default, and you really do not need --with-w defined. 5.10.1 Basic configuration For SSH1: In /etc/ssh_config: ForwardX11 yes In /etc/sshd_config: X11Forwarding yes For SSH2: In /etc/ssh2/sshd2_config: ForwardX11 yes Note that you do not have to change the /etc/ssh2/ssh2_config file. If you are running TCP Wrappers along with X forwarding, you need to make sure you add the necessary sshdfwd-X11: line in the /etc/hosts.allow file. This should not contain the host you are coming from. You also do not need to open any additional ports. Everything is sent through port 22. 5.10.2 Can I configure XDM to go through Secure Shell? It is not possible to forward XDMCP over ssh, because it uses UDP, not TCP. See section 5.5 of this FAQ. In a nutshell: if you want the PC to look like an X terminal, you can't do this securely. But maybe you'll be able to start dtwm manually after having logged in, if your X server on the PC allows you to use a window manager on the remote end instead of using Windows for that purpose. I seem to remember eXceed used to allow this, but it's a good while since I did anything with Windows, so I'm not so sure about the current breed. Thanks to Atro Tossavainen for this information. 5.11. Can I forward SGI GL connections over ssh? It is not likely that this will be implemented. GL uses a totally different protocol from X, and at least gld would have to be replaced. OpenGL, when run as an X server extension, should pose no problem. You may need to set the environment variable GLFORCEDIRECT=no. 5.12. Does Secure Shell support digital certificates? No, not currently. As digital certificates become more popular, Secure Shell will probably support digital certificates in the future. 5.13. Does Secure Shell work with PGP keys? Only in SSH2. It's supported in release 2.0.13 or later. 6. Patches for Secure Shell This section gives you information on how to get and apply patches for Secure Shell. Click here for the contents of this section. 6.1. Applying patches for Secure Shell When you download the patch, make sure you store it in the directory that the distribution is in. For example, if you download the source and store it in /usr/local/src, put the patch in /usr/local/src. Please cd to your ssh source directory, and give the command: % patch -p 0 < /path/to/sshpath Then run make uninstall, make distclean, configure, make, and make install again. For each individual patch, you may have to follow different instructions. Also, check man patch for more details. The patch command is different on different operating systems. 6.2. Official patch distribution from SSH Communications Security The official location for recent patches to SSH1 and SSH2 is available from http://www.ssh.com/ssh/patches.html. 6.3. Other patch distributions These patches may use different instructions than the ones listed above. Jim Barlow's AFS/Kerberos5 patch - http://www.ncsa.uiuc.edu/General/CC/.../AFS_KRB5.html. Dug Song's AFS/Kerberos4 patch - http://www.monkey.org/~dugsong/ssh-afs. Secure Shell User Contributed Patches - http://www.tigerlair.com/ssh/patches. James Barlow maintains a repository for ssh patches at: http://www.ncsa.uiuc.edu/General/CC/...ch_repository/ His comments: "I have put in a few patches we have done, a few that have been posted to the newsgroup, and a few others that I know of. There is a page that describes submitting patches, and if anybody has comments they can let me know. Most of the patches currently relate to the 1.2.x version, but I can put up patches for the 2.0.x version as well." 7. Troubleshooting Secure Shell This section gives you very basic information on how to troubleshoot Secure Shell. This section is especially crucial to get any additions or corrections as Secure Shell continues to grow and get used. Click here for the contents of this section. 7.1. Common compiling problems This section goes over compiling problems that may affect any platform. 7.1.1 Compiling fails with some error messages from the assembler. For some operating systems, there are bugs in the gmp assembler routines. Try: # make distclean # configure --disable-asm # make # make install to compile. 7.1.2 The configure process cannot find xauth! Check your path. Make sure you can find xauth with the "whereis xauth" or "which xauth" command. If not, add the path to xauth the way your shell likes you to do this, then run ./configure again. Another option is to ./configure --without-x. 7.1.3 The configure process cannot find nm" Under Solaris, the directory /usr/ccs/bin should be in your PATH. 7.2. General troubleshooting tips This section covers some of the problems with running Secure Shell that are not operating system dependent. 7.2.1 Secure Shell is doing wrong things for multi-homed hosts! Check whether gethostbyname() really returns the complete lists of possible IP addresses (you might, for example, have your system configured to search /etc/hosts first, which might contain only one of the IP addresses). 7.2.2 Ssh asks me for passwords despite .rhosts! There are several possibilities why this could be the case in SSH1; common ones include The remote hosts's /etc/ssh_known_hosts is not world readable. The client host key is not stored in the known_hosts file. Note that this has to be the canonical (usually, the fully qualified) domain name. The client host does not have a reverse mapping in the name servers. Note that ssh requires that it has both a reverse mapping, and a forward mapping that contains the original IP address. A multi-homed client or host does not have all of its IP addresses listed in the DNS entry. Note that versions prior to 1.2.12 have bugs in handling multi-homed hosts. User's home directory or ~/.rhosts is world or group-writable (see StrictModes server configuration option). On some machines, if the home directory is on an NFS volume, ~/.rhosts and your home directory may need to be world-readable. The root account has to use ~/.rhosts or ~/.shosts; /etc/shosts.equiv and /etc/hosts.equiv are disregarded for root. Confusion between RhostsRSAAuthentication and RSAAuthentication. RhostsRSAAuthentication is a functional replacement for the 'r' utilities; this requires the ssh program to be setuid root, a secret key in /etc/ssh_host_key file on the client, a corresponding public key entry in /etc/ssh_known_hosts, plus entries in ~/.[sr]hosts or /etc/[s]hosts.equiv. RSAAuthentication is done on a per-user basis and requires a ~/.ssh/identity file on the client side (to be generated with ssh-keygen), plus a matching ~/.ssh/authorized_keys on the server side. 7.2.3 Why does ssh loop with "Secure connection refused'? This is a configuration problem. SSH1 attempts to fall back to the "r" commands when it cannot connect to an ssh daemon on the remote host. It does this by execing your old rsh to use the old protocol. There are two possibilities why this could be: You probably have installed ssh as rsh, and forgotten to give the --with-rsh=PATH option to configure the second time. When ssh is looking for rsh, it keeps executing itself (or an older version of itself). To solve this, recompile ssh with the correct place for rsh. You moved the old rsh and rlogin into a different directory and correctly are calling the old rsh. The old rsh has a hard-coded path to the old rlogin program, so you wind up execing the old rsh which in turn execs the new replacement (ssh)rlogin. In that case, you might want to move the old rsh and rlogin binaries into /usr/old, patch the old rsh binary by running the Perl script perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh which will generate a patched version of rsh and save the old one in /usr/old/rsh.orig. Reconfigure ssh with --with-rsh=/usr/old/rsh. SSH2 doesn't ever use rsh. And won't in the future, either. It would be against the draft. 7.2.4 ssh hangs when forwarding multiple TCP connections. This is due to a known race condition in the ssh protocol before 1.2.13. Some changes have been made to the protocol in 1.2.14 to prevent this. Unfortunately, these changes may also cause hangs when using TCP forwarding between 1.2.14 and earlier versions. In these cases, upgrade to 1.2.27 on both ends. 7.2.5 I still see cleartext packages on the net when I run ssh! It is very likely that you are looking at a telnet, rlogin or X session to the machine that you run ssh on. Check that those packets really are ssh packets (for example by checking their port number; sshd listens on port 22). 7.2.6 I have problems with RSAREF, something to do with too many bits! This is a limitation in the RSAREF library. You should set a host key with at most 896 bits. 7.2.7 Connections are forwarded as root by ssh! When a client connects, sshd forks a child that does the protocol handling, and this child forks a second child for the user shell or command. The problem is that the setuid() call to the correct user appears only in the second child, so the first child keeps running as root. Among other potential problems this means that connections redirected with -Lxstort will be made from the root uid to hostort, since the first child does them. This means that when the target host does an ident query, it gets back only "root" and no indication of the actual user. This has been reported as a bug; it is not known wether this will be fixed in a future release. 7.2.8 Why do I get a connection refused message? Your ssh daemon is likely not running (or unreachable through a firewall). try telnet hostname 22 and see if Secure Shell answers. Also, make sure that the ssh daemon is started by your system's startup scripts, or else the daemon will not automatically start when the system is rebooted. 7.3. X11 Forwarding problems This section goes over some known problems with forwarding X traffic through Secure Shell. 7.3.1 ssh otherhosh xclient & does not work No, it doesn't. Use "ssh -f otherhost xclient" instead, or "ssh -n otherhost xclient &" if you want a script to be compatible with rsh. 7.3.2 ssh-agent does not work with rxvt! rxvt closes all file descriptors when starting up, including the one used by ssh-agent. Use xterm, or look at the mailing list archives at http://www.cs.hut.fi/ssh/ssh-archive/ for Timo Rinne's rxvt patch. 7.3.3 X authorization always fails. This can happen if the xauth program was not found at configure time. Correct the path, reconfigure and recompile. It can also happen if ssh was configured with the --with-libwrap option and the necessary sshdfwd-X11: line in the /etc/hosts.allow file doesn't contain the host you are coming from. Another problem is with Solaris. Cameron Simpson's experience: We have a longstanding problem with xauth on Solaris. About a year ago the Solaris X distribution was rebuilt to put the UNIX socket in a special directory in /var to avoid a security issue with having it in /tmp (an attacker could move it sideways and insert a fake one). Then some months later the X distribution was modified again, moving the socket back because the better fix was more careful use of permissions in /tmp. Meanwhile, we'd built our own X distributions for extra stuff and because the Sun one lags behind the X.org one. So now we have various X servers and xauth programs lying around which have different ideas about where the X socket it, and ssh forwarding can break if the xauth the sshd runs and the X server the user is using have different mindsets. The solution is to make sure your homegrown X builds match the current OS distribution's ideas. So we're going to have to clean out our old local copies and rebuild, but we've not had time yet. The workaround is to put a symlink in one spot pointing at the other, so both paths to the socket work. At any rate, you should add "xauth and the X server have different ideas about where the UNIX domain socket is" to the list of possible causes of xauth failure, listing the above situation as an example. 7.3.4 What does Warning: remote host denied X11 forwarding mean? Either the remote end has disabled X11 forwarding (ForwardX11 No in the config file), or either the xauth command or the X11 libraries were not found when compiling the server. 7.4. Linux This section goes over some known problems with Secure Shell on Linux systems. 7.4.1 X11 forwarding does not work for an SCO binary with the iBCS2 emulator under Linux. You need to set the hostname to the fully qualified domain name for this to work. Some Linux distributions set the hostname to the first part of the FQDN only. 7.4.2 On Linux, compilation aborts with some error message about libc.so.4 This is an incorrectly configured Linux system; do a "cd /usr/lib; ln -s libc.sa libg.sa" as root to remedy this. 7.5. Solaris This section goes over some known problems with Secure Shell on Solaris systems. 7.5.1 Compiling with Solaris 2.5 fails! Set the CPP environment variable to "cc -E -Xs" before running configure. 7.5.2 Ssh fails with "Resource temporarily unavailable" for Solaris For Solaris 2.4, this s a kernel bug. Get the patch 101945-37 to fix it. Please note that at least one earlier version, 101945-36, seems to have reintroduced the bug. If you experience the same problem with Solaris 2.5.1, upgrade to ssh 1.2.27 (this was fixed in 1.2.14), which should solve the problem. 7.5.3 Sshd hangs under Solaris 2.5! This is a problem with the Solaris shared library code, which causes a hang with some name server functions. Get Patch 103187-02 (for x86, 103188-02) to fix this. This problem may or may not be fixed in Solaris 2.5.1. 7.5.4 ssh-keygen dumps core on Solaris or SunOS This is a bug in gcc 2.7.0, which causes it to generated incorrect code without optimization. Supply the "-O" or "-O -g" options to gcc when compiling. Alternatively, upgrade to gcc 2.7.2 or later. 7.5.5 I can't get TCP wrappers to work under Solaris Some known bugs in Secure Shell and Solaris: Hostbased authentication does not work under Solaris is TCP wrappers are used with an Secure Shell implementation before 2.1.0.pl2 (the connection hangs) TCP wrappers do not work at all wtih SSH2 under Solaris 2.5.1 (the connection hangs) 7.6. Other operating systems This section goes over some known problems with Secure Shell on other operating systems not covered above. This currently includes AIX, HP-UX, and Alpha OSF/1. 7.6.1 ssh-keygen dumps core on Alpha OSF! For Alpha OSF/1 1.3.2, this is due to a bug in the vendor-supplied compiler with maximum optimization. Turn off all optimization for ssh-keygen, or use gcc. Gcc 2.7.2 is known to have problems on the Alpha, however. 7.6.2 On HP-UX 9, X authorization sometimes fails. This is believed to be a bug in HP-UX 9 xauth, SR 5003209619. Patch PHSS_5568 is believed to fix this problem. 7.6.3 Userid swapping is broken under AIX! This is a bug in AIX 3.2.5, reported as APAR IX38941, and fixed by patches U435001, U427862, U426915, and a few others. Contact your IBM representative for details. 8. Getting support for Secure Shell This section gives you a list of references to help you when you run into a problem with Secure Shell.Click here for the contents of this section. 8.1. Who provides support for Secure Shell? Before going to anyone for support, please read the FAQ (this document :-). Please also read the README and SSH2.QUICKSTART for any general help with SSH2. The other thing to note is that SSH Communications Security provides support for their commercial customer; however, they do not have bandwidth to handle non-commercial users. For the non-commercial releases of Secure Shell (including other implementations for UNIX, Windows, etc.), please use the ssh mailing list for support. There are other links listed below including tutorials and publications that may help you. If you are using the non-commercial release of SSH Secure Shell as an evaluation before purchasing, please contact SSH Communications Security directly. 8.1.1. What groups can help me with the "free" versions? Even though Secure Shell does not provide support for the non-commercial release, you can always ask the nice people on the Secure Shell mailing list for help. :-) Also, you'll see SSH Communications Security staff on the list answering questions at times as well. 8.1.2. How can I get commercial support for UNIX Secure Shell? Contact SSH Communications Security directly. If you have purchased another vendor's product, please contact them for commercial support. 8.1.3. How can I get SSH Secure Shell support for universities? Note: If you know where the SANS link is to this, please let one of the maintainers know. From Steve Acheson, who is responsible for the SANS University Secure Shell program: SSH2 is now fully available for University use and distribution. The software is available from the SSH, Inc. web site for download with a minimal registration procedure. The License file is included with the software and is also posted on the web at http://www.ssh.com/products/ssh/ssh_...agreement.html. This license covers the use of the software by any student, faculty member, researcher, employee or administrator affiliated with a university, other accredited non-profit educational or university-affiliated research institution, or charitable organization. There is also the ability for any of the above organizations to register for a redistribution license in the event they wish to distribute the software to their constituents themselves. To get the non-commercial version of the software go to http://commerce.ssh.com and scroll to the bottom of the page and click on the link for the version you are interested in. To get the re-distribution license, please go to http://www.ssh.com/commerce/non-comm...e_request.html and register for the license. Support for the software is not provided by SSH, Inc. If you are having trouble with the software or have questions, please refer them to the mailing list, [email protected]. SANS is drafting up a plan to coordinate support issues for Universities by a few key universities, when this is available SANS will issue additional information at that time. 8.2. If F-Secure sells Secure Shell, what does SSH Communications Security do? SSH Communications Security develops the SSH technology along with IPSec toolkits. However, up until now, SSH Communications Security was not selling Secure Shell--they were licensing it strictly through F-Secure. SSH Communications Security now sells Secure Shell, both Windows and UNIX applications. F-Secure still licenses the UNIX server, but sells their own clients for Windows and Macintosh. If you have support issues with your commercial product, please contact the appropriate company. Please do not contact SSH Communications Security for problems with F-Secure products, and do not contact F-Secure with problems with SSH Communications Security products. 8.3. Secure Shell Mailing List If these resources don't help, you can post to the Usenet newsgroup comp.security.ssh or send email to the gatewayed mailing list for ssh users at [email protected]. 8.3.1. Subscribing To subscribe to the Secure Shell Mailing List, send an email to [email protected], leave the subject and body empty. If you would like to reduce the volume of messages you receive from the list, but still want to stay informed on the discussions, you can receive a digest of all messages once daily rather than each message individually. To subscribe to the digest, email: [email protected], leave the subject and body empty. Remember to unsubscribe from the regular list if you were subscribed and decide to receive the digest instead. When you subscribe to the list or digest, you will receive a confirmation message back to the subscribed address. When you receive it, simply follow the instructions to complete the subscription. 8.3.2. Unsubscribing To remove your address from the list, just send a message to the address in the ``List-Unsubscribe'' header of any list message. If you haven't changed addresses since subscribing, you can also send a message to: [email protected] or to unsubscribe from the digest, send a message to: [email protected] Remember to leave the subject and body empty. When you receive the confirmation message, simply follow the instructions to complete the transaction. 8.3.3. Help / Administration For help and a description of available commands, send a message to: [email protected] If you need to get in touch with the human owner of this list, please send a message to: [email protected] Please include a FORWARDED list message with ALL HEADERS intact to make it easier to help you. 8.3.4. Mailing List Archives Before subscribing, you might like to take a look at the archives of the mailing list, at http://www.mail-archive.com/[email protected]#00416 http://www.progressive-comp.com/List...2#secure-shell 8.4. Tutorials There is a decent user level tutorials available on the web: Kimmo Suominen's introduction to Secure Shell: http://www.tac.nyc.ny.us/~kim/ssh/ 8.5. Web pages There are some web pages on various aspects of Secure Shell. Here are the ones I have: http://www.rhic.bnl.gov/RCF/Software...SSH/index.html http://staff.washington.edu/dittrich/misc/ssh/ http://wks.uts.ohio-state.edu/sysadm...ysadm-558.html 8.6. Publications There are two articles in SunWorld by Steve Acheson on Secure Shell: Introduction to Secure Shell, features, etc: http://www.sunworld.com/sunworldonli...-security.html Configuration, installation, etc: http://www.sunworld.com/sunworldonli...-security.html There is a book out on Secure Shell (both SSH1 and SSH2), UNIX Secure Shell, ISBN 0071349332 by Anne Carasik, available from McGraw-Hill Publishing. For those outside of the United States, the book is available without the CD-ROM. I hate the US crypto laws.. :-( 9. Tips and Tricks of Secure Shell This section gives you some tips from folks out there who have found some cool ways to get Secure Shell working in their environment. Click here for the contents of this section. 9.1 Making Secure Shell more transparent to users Here is a simple script by Ross Golder to make using ssh more transparent. When you first login (open an Xterm etc.), you'll be prompted for your passphrase. After that, it will automatically configure your environment to the ssh-agent it started. When logging out of a multi-user machine, I just use a 'killall ssh-agent' (not as root!). Install the following file as $HOME/.ssh/setup and set the execute permission (chmod 700 setup), and add a call to it in your $HOME/.bashrc. #!/bin/sh # # This script is intended to reside in your ~/.ssh directory (don't # forget to 'chmod 700'), and be included in your shell init script. # # It works by checking for a working ssh agent, otherwise it starts one # and requests the passphrase. # # If used on a network-connected machine that is up 24/7, you should # take care to kill your agent when you leave your machine, using # "eval `ssh-agent -k`". # # For bash and ksh users: # # include the following in your ~/.bashrc or ~/.kshrc or ~/.profile # # . $HOME/.ssh/setup # # For csh and tcsh users: # # include the following in your ~/.cshrc or ~/.tcshrc # # source $HOME/.ssh/setup # #---------------# # Configuration # #---------------# # Enable this if using you have GNOME and the following program. #SSH_ASKPASS=/usr/libexec/ssh/gnome-ssh-askpass #export SSH_ASKPASS # If using NFS-based home directories, you probably should specify one # main workstation here, otherwise it could cause mayhem. SSH_WORKSTATION=durban.rossg.home.lan SSH_ENV=$HOME/.ssh/environment.`hostname` #----------------------# # End of configuration # #----------------------# function start_agent { echo "Initialising new Secure Shell agent..." ssh-agent | head -2 > ${SSH_ENV} chmod 600 ${SSH_ENV} . ${SSH_ENV} > /dev/null ssh-add /dev/null ps ${SSH_AGENT_PID} > /dev/null || { start_agent; } else start_agent; fi fi 9.2. How do I find out which version of Secure Shell is running at the remote end? The simpliest way is to do a telnet hostname 22. The response you get is something like SSH-[1.99]-2.x.x for a version 2 server and SSH-[1.5]-1.x.x for a version 1 server. Trying 127.0.0.1... Connected to hostname.example.com. Escape character is '^]'. SSH-1.99-2.1.0.pl2 SSH Secure Shell 9.3. How do I get SSH2 to compile on a MacOSX server? (Contributed from Dorian Moore) Here's what I had to do: # untar ssh1 # cd # cp /usr/libexec/config.* . # ./configure --host=nextstep --disable-asm # mv gmp-2.0.2-ssh-2/gmp-impl.h gmp-2.0.2-ssh-2/gmp-impl.h.old # sed "s/\!defined(NeXT)/defined(NeXT)/g" gmp-2.0.2-ssh-2/gmp-impl.h.old > \ gmp-2.0.2-ssh-2/gmp-impl.h # make And it seems to work fine, though the make install doesn't work. I don't know if there is a way of patching the makefile to do the above changes, as thats not really my area. Credit for this info goes to Joshua Marker ([email protected]) and I found the info via: http://www.omnigroup.com/OldLook/Mai...1999/4091.html 9.4. Running SSH2 With SSH1 Compatibility Since there are many folks still running SSH1, many people want to run SSH2. Even though the protocols are incompatible, you can set up "compatibility" with SSH1 and SSH2--so SSH2 forwards the SSH1 connections to the sshd1. 9.4.1 What Is SSH1 Compatibility? The SSH1 and SSH2 protocols are not compatible. This means that SSH1 clients cannot connect to a SSH2 daemon. However, the SSH2 daemon can be configured to start up a SSH1 daemon when it receives a connection from a SSH1 client. This allows both SSH1 and SSH2 clients to connect to such a Secure Shell daemon. The process of handing off to a SSH1 daemon is transparent to the end user. 9.4.2 Setting Up Compatibility By default, SSH2's ./configure process will look for a compatible SSH1 and will build itself with support for SSH1 compatibility. This means that if you want to set up SSH2 with SSH1 compatibility on a machine that' s not running any Secure Shell at all, you should install SSH1 first so that SSH2's configure process will find it. If you are already running SSH2 and you want to add in SSH1 compatibility, it is not necessary to rebuild SSH2. Build and install SSH1. Then, in the sshd2_config file, make sure that the "Ssh1Compatibility" variable is set to "yes" and that the "Sshd1Path" variable is set to the path to your sshd1 binary. Example: Ssh1Compatibility yes Sshd1Path "/usr/local/sbin/sshd1" Be careful about the "sshd" symbolic link. The installation process for both SSH1 and SSH2 changes the sshd symbolic link to point to their binary, either sshd1 or sshd2. If you run your Secure Shell daemon as "sshd", make sure that the symbolic link is correct so that the right daemon is being started! A Note on Startup Performance When a SSH1 request comes in, a SSH1 daemon is started up at that time to process the incoming connection. Because the SSH1 daemon has to initialize itself at that time, the initial connection for SSH1 clients can take longer than if the SSH1 server were running as a standalone daemon. The effect is much the same as running the SSH1 daemon via inetd, which is discussed elsewhere in section 4.6. Making Changes to the sshd_config File Since the SSH1 daemon is started up with every connection, it will reread the sshd_config file with each new connection. If the sshd_config file is modified, there is no need to HUP the SSH2 daemon to make the SSH1 daemon see the changes. 9.4.3 About TCP Wrappers and SSH1 Compatibility The SSH2 daemon answers the incoming requests. As such, the tcpwrapper entries pertaining to your SSH2 daemon prevail and any such entries pertaining to your SSH1 daemon aren't processed at all. For example, if you had these entries in your /etc/hosts.allow file, then SSH1 connections would in fact be allowed from the entire subnet because it is the sshd2 that answers the incoming request. # Allow SSH1 only from a specific computer sshd1: 192.168.1.100 # Allow SSH2 from the entire subnet sshd2: 192.168.1.0/255.255.255.0 9.4.4 Authentication in Compatibility Mode The SSH2 daemon handles the incoming connection, including tcpwrapper processing. After that point, it hands off to the SSH1 daemon. This means that the SSH1 daemon handles authentication for SSH1 clients, and the SSH2 daemon handles authentication for SSH2 clients. This means that if a SSH1 client is trying to use hostbased or publickey authentication, the SSH1 daemon must be properly configured to handle those requests. The SSH2 daemon doesn't need to be configured to handle those requests at all (in fact, those authentication methods could be disabled in the SSH2 daemon), unless such requests will be coming from SSH2 clients. 9.4.5 How do I get hostbased authentication to work with SSH2 and SSH1? Below is a stepwise HOWTO for setting up hostbased authentication for SSH1 or SSH2 or SSH2 with SSH1 compatibility. Also included are some notes on using SSH2 with SSH1 compatibility. Note that, before SSH 2.1.0.pl2, hostbased authentication does not work properly on a Solaris 2.6 server if libwrap support is compiled into the ssh daemon. For older version fo the ssh daemon, a workaround using SSH2 with SSH1 compatiblity is discussed below. Here, I'll use the following terms: The Server is the Secure Shell server into which you're trying to connect. The ServerUser is the username on the Server into which you'd like to login. The Client is the machine running a Secure Shell client. The ClientUser is the username on the Client that you'd like to allow to login to the Server as the Server User. As an example, our backups are done via username "backup" on host Tapeserv. On our Authserv server, user "root" is trying to connect to Tapeserv to make Authserv's backups on Tapeserv's tape drive. This means that the Server is Tapeserv, the ServerUser is backup, the Client is Authserv, and the ClientUser is "root". Step 1. Of course, install Secure Shell on the Server and Client machines. Step 2 - SSH1. On the Client, cat the file /etc/ssh_host_key.pub and copy-n-paste it into Notepad or some other text editor. It will look something like this: 1024 35 1255908028087833976430... root@authserv (the actual number will be much longer) Remove the root@Client from the end and add the Client hostname to the beginning: authserv 1024 35 1255908028087833976430... Then copy-n-paste this single, very long line into Server's /etc/ssh_known_hosts file. This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication. Step 3 - SSH2. Copy the Client's /etc/ssh2/hostkey.pub file over to the Server and name it /etc/ssh2/knownhosts/authserv.ssh-dss.pub Of course, since your host isn't named Authserv, use your own hostname. Generally, you'll want to use the "short" hostname and not the fully qualified hostname. This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication. Step 4. On the Server, create a file in the ServerUser's home directory named ".shosts". The contents of this file should be the Client hostname, some tabs or spaces, and the ClientUser username. For example, to allow root@Authserv to log into backup@Tapeserv, I'd place this .shosts file into backup's home directory on Tapeserv: authserv root Be sure to chown and chmod the .shosts file. The .shosts file must be owned by the remote user and should be mode 0400. Step 5 - SSH1. Make sure that this line exists in /etc/sshd_config: RhostsRSAAuthentication yes This enables the SSH1 daemon to do what we need it to do. For safety, you may also want to verify this line: RhostsAuthentication no This disables the use of rhosts-style authentication without corresponding public key authentisation. If you had to modify the sshd_config file, you have to HUP the sshd to make the change take effect. Step 6 - SSH2. Check the file /etc/ssh2/sshd2_config and make sure that AllowedAuthentications contains the word "hostbased" For example, it may read: AllowedAuthentications hostbased,password If you had to modify the sshd2_config file, you'll have to HUP the sshd to make the change take effect. Step 7. You should be all set. On the Client, log in as the ClientUser and try this: ssh ServerUser@Server uptime You should get back the results of "uptime" run on the remote server. The first time you run ssh to that particular server, you'll have to answer "yes" when asked if you want to connect to the server. This is because the local ssh doesn't yet have the remote server's Secure Shell public key. This will only hapen the first time. Common Pitfalls Did you copy the hostkey properly? Did it get mangled when you copied it over? With SSH2, did you name the hostkey file appropriately? It should be /etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the short hostname or the long hostname. Check your spelling in the .shosts file Is the .shosts file owned by the ServerUser? Try running the server with the -v flag (for SSH2) or the -d flag (for SSH1) and see if anything useful is generated. This is a great way to see if a hostkey file is missing. About SSH1 and SSH2 Compatibility At our site we use SSH2 with password-based authentication for interactive sessions. Because hostbased authentication doesn't work with SSH2 on Solaris, we installed SSH2 with SSH1 compatibility and we use SSH1 for noninteractive hostbased-authenticated backups. It is important to note that it is SSH1 and not SSH2 which handles the hostbased sessions, which means the following: The Server's SSH2 doesn't need the client's SSH2 hostkey. The Server's SSH1 needs the Client's SSH1 hostkey. The Server's SSH2 doesn't need hostbased authentication enabled. There's no need to HUP anything on the Server. The sshd1 is spawned on demand and will see the changes to /etc/sshd_config at that time. On the Client, be sure to use "ssh1" to be sure that the right client is being invoked, e.g.: ssh1 backup@authserv uptime 10. The ever-popular miscellaneous section This section covers some miscellaneous things about Secure Shell.Click here for the contents of this section. 10.1. Should I turn encryption off, for performance reasons? No; you should keep it turned on, for security reasons. Today's CPUs are fast enough that performance losses (if any) only are noticable for local Ethernet speeds, or faster. You might want to specify blowfish encryption instead of the default, IDEA for SSH1 and 3DES for SSH2, with -c blowfish, for faster operation. Following are some measurements where the different encryption methods were applied between a P5/90 and a 486/100, both running Linux, for copying files with scp across a lightly loaded Ethernet. The model chosen was t=a+x/b; a is the startup time in seconds, and b the sustainable transfer rate in kB/s. Also given are the 68.3% confidence intervals for the data, as determined by the Levenberg-Marquardt algorithm as implemented a pre-3.6 version of gnuplot. Encryption a[s] da[s] b[kB/s] db[kB/s] none 2.37 0.37 386.1 5.8 rc4 1.96 0.27 318.2 2.9 tss 2.33 0.37 298.5 3.5 des 2.07 0.19 218.8 1.0 idea 2.25 0.45 169.6 1.3 3des 1.92 0.11 118.2 0.2 Across a heavily loaded Ethernet, rc4 encryption together with compression may actually be faster than using rcp. 10.2. Known security bugs with Secure Shell All versions of ssh prior to 1.2.12 had a security flaw which allowed local users to get access to the secret host key. This is fixed in 1.2.13 and later. Upgrade to 1.2.27 to fix this. If you run ssh 1.2.13 on Alpha OSF 1.3 or SCO in C2 security mode, local users can gain root access. Upgrade to 1.2.27 to fix this. or by upgrading to 1.2.27. Versions of ssh prior to 1.2.17 had problems with authentication agent handling on some machines. There is a chance (a race condition) that a malicious user could steal another user's credentials. This should be fixed in 1.2.17. The arcfour cipher is used in a way which makes it susceptible in version 1 of the ssh protocol. Therefore, its use has been disabled in 1.2.18 and later. In versions prior to 1.2.23 there was a CRC32 Compensation attack that allowed the possibility of executing arbitrary commands. Make sure you upgrade to 1.2.27. With 2.0.12,an sshd connection would not die, even if a complete connection was never fully established. That is, when he came from server B to server A, the session on server A would hang when he exits. Upgrading to 2.0.13 should fix this problem. 10.3 I don't like the commercial aspects of ssh. The licensing of SSH Secure Shell has changed so that if you are using it for non-commercial use, you can use it free of charge. See the licensing agreement for more details. The good news is the protocols ssh uses are freely available. There are no restrictions if anybody wants to write a version that is available under different conditions and is interoperable with existing Secure Shell installations. Secure Shell 2 is also on the Internet Standards Track. This means that a second, independent implementation is required. The other current SSH2 implementations are lsh and OpenSSH. For SSH1, you have quite a few resources as well, check out section 2. You will have to be aware of patents, like RSA and IDEA, and export control issues before writing a second implementation. 10.4 Alternatives to Secure Shell There are several other secure connection or authentication bits of software about. You might want to check them out as well. srp: http://srp.stanford.edu/ stunnel: http://www.stunnel.org/ OpenSSL: http://www.openssl.org ssleay-related: http://www.psy.uq.edu.au:8080/~ftp/Crypto/ stone: http://hp.vector.co.jp/authors/VA000770/stone/ excellent post shtirlitz! list of free shell provides: http://www.bylur.net/free/ http://freeshell.org http://sdf-eu.or http://www.grex.org http://www.nyx.net http://m-net.arbornet.org http://www.xox.pl http://www.rootshell.be http://www.daforest.org http://www.vectorstar.net http://www.polarhome.com http://vmsbox.cjb.net http://www.titanix.net http://www.bur.st/ http://full-house.net http://deathrow.vistech.net http://nic-nac-project.de http://aragon.marway.org http://www.magnesium.net/ http://cyberunners.org/ http://www.metawire.org http://www.jvds.com/freeshells/ http://www.linuxnetbox.de/ http://www.unixdaemons.com/ http://www.celuloza.ro/ http://www.polarhome.com/ http://shells.thinkgeek.co.uk http://www.biglamers.org http://www.silenceisdefeat.org/ http://www.hbx.us/ http://www.hwee.org/ http://phynix.darkwired.org/ http://www.zsuatt.org/ http://www.rulex.net/ http://www.aeshells.org/ http://www.wanadobe.biz/ http://freeshell.simosnap.com/ http://freebsd.prohostuk.net/ http://www.celebris.net http://the1.no-ip.com/ http://www.mlg3.net/ http://www.zerged.com http://www2.steve-gibbs.co.uk/ http://www.suxxsbox.info http://www.shellsnet.org http://bsd.miki.eu.org/ http://www.chules.net/ http://freeshell.datadrain.org/ http://jiyu.gnook.org/ http://shell.yaphog.org/ http://www.gibbs-hosting.co.uk/freehosting.html http://shells.humpmeg.net http://www.plexerv.info http://www.phoenix-network.org/ http://www.shells.oceanius.com/ http://freeshells.mtveurope.org/ http://www.systemshell.net/ http://www.kverka.no/ http://a2b2.com/ http://www.humpmeg.net another list of free shells: http://www.devilix.net/freeshells/ another list of free shells: http://www.themlg.net/shells/links.php |
|
|
 |
«
Previous Thread
|
Next Thread
»
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Finding bins without 3D-secure | Cartographer | Tutorials | 4 | 12-24-2017 12:59 AM |
| TUTORIAL**CC>UKASH>LR tutorial * | Cartographer | Tutorials | 2 | 11-10-2015 04:57 AM |
| Настраиваем и юзаем SSH Tunnels | Cartographer | Статьи | 0 | 08-26-2013 06:47 PM |
| Verified by Visa и MasterCard Secure Code | Cartographer | Статьи | 0 | 08-22-2013 03:29 PM |