1.0 - What is OpenSSH and how do I get it?
- 1.1 - What is OpenSSH and where can I download it?
- 1.2 - Why should it be used?
- 1.3 - What operating systems are supported?
- 1.4 - What about copyright, usage and patents?
- 1.5 - Where should I ask for help?
- 1.6 - Where do I report bugs?
2.0 - General Questions
- 2.1 - Why does ssh/scp make connections from low-numbered ports. My firewall blocks these.
- 2.2 - Why is the ssh client setuid root?
- 2.3 - Why does SSH 2.3 have problems interoperating with OpenSSH 2.1.1?
- 2.4 - Why does OpenSSH print: Dispatch protocol error: type 20
- 2.5 - Old versions of commercial SSH encrypt host keys with IDEA.
- 2.6 - What are these warning messages about key lengths?
- 2.7 - X11 and/or agent forwarding does not work.
- 2.8 - After upgrading OpenSSH I lost SSH2 support.
- 2.9 - sftp/scp fails at connection, but ssh is OK.
- 2.10 - Will you add [foo] to scp?
- 2.11 - How do I use port forwarding?
- 2.12 - My ssh connection freezes or drops out after N minutes of inactivity.
- 2.13 - How do I use scp to copy a file with a colon in it?
- 2.14 - Why does OpenSSH report its version to clients?
3.0 - Portable OpenSSH Questions
- 3.1 - Spurious PAM authentication messages in logfiles.
- 3.2 - Empty passwords not allowed with PAM authentication.
- 3.3 - ssh(1) takes a long time to connect or log in
- 3.4 - "Can't locate module net-pf-10" messages in log under Linux.
- 3.5 - Password authentication doesn't work (eg on Slackware 7.0 or Red Hat Linux 6.x)
- 3.6 - Configure or sshd(8) complain about lack of RSA support
- 3.7 - "scp: command not found" errors
- 3.8 - Unable to read passphrase
- 3.9 - 'configure' missing or make fails
- 3.10 - Hangs when exiting ssh
- 3.11 - Why does ssh hang on exit?
- 3.12 - I upgraded to OpenSSH 3.1 and X11 forwarding stopped working.
- 3.13 - I upgraded to OpenSSH 3.8 and some X11 programs stopped working.
- 3.14 - I copied my public key to authorized_keys but public-key authentication still doesn't work.
- 3.15 - OpenSSH versions and PAM behaviour.
- 3.16 - Why doesn't "w" or "who" on AIX 5.x show users logged in via ssh?
The OpenSSH suite includes the ssh(1) program which replaces rlogin and telnet, and scp(1) which replaces rcp(1) and ftp(1). OpenSSH has also added sftp(1) and sftp-server(8) which implement an easier solution for file-transfer. This is based upon the secsh-filexfer IETF draft.
OpenSSH consists of a number of programs.
The most recent version of OpenSSH is included with the current distribution of OpenBSD, and installed as part of a basic install.
Today, most other operating systems include some version of OpenSSH (often re-badged or privately labeled), so most users can immediately use it. However, sometimes the included versions are quite old, and missing features of the current release of OpenSSH, and you may wish to install the current version, or install it on one of the few OSs that lacked it, and where the OS publisher does not make a modern version available. You may also wish to use OpenSSH on your embedded application.
Non-OpenBSD users will want to download, compile and install the multi-platform Portable distribution from a mirror near you.
OpenSSH is a suite of tools to help secure your network connections. Here is a list of features:
Currently, almost all communications in computer networks are done without encryption. As a consequence, anyone who has access to any machine connected to the network can listen in on any communication. This is being done by hackers, curious administrators, employers, criminals, industrial spies, and governments. Some networks leak off enough electromagnetic radiation that data may be captured even from a distance.
When you log in, your password goes in the network in plain text. Thus, any listener can then use your account to do any evil he likes. Many incidents have been encountered worldwide where crackers have started programs on workstations without the owner's knowledge just to listen to the network and collect passwords. Programs for doing this are available on the Internet, or can be built by a competent programmer in a few hours.
Businesses have trade secrets, patent applications in preparation, pricing information, subcontractor information, client data, personnel data, financial information, etc. Currently, anyone with access to the network (any machine on the network) can listen to anything that goes in the network, without any regard to normal access restrictions.
Many companies are not aware that information can so easily be recovered from the network. They trust that their data is safe since nobody is supposed to know that there is sensitive information in the network, or because so much other data is transferred in the network. This is not a safe policy.
Even though OpenSSH is developed on OpenBSD a wide variety of ports to other operating systems exist. The portable version of OpenSSH is headed by Damien Miller. For a quick overview of the portable version of OpenSSH see OpenSSH Portable Release. Currently, the supported operating systems are:
A list of vendors that include OpenSSH in their distributions is located in the OpenSSH Users page.
The OpenSSH developers have tried very hard to keep OpenSSH free of any patent or copyright problems. To do this, some options had to be stripped from OpenSSH. Namely support for patented algorithms.
OpenSSH does not support any patented transport algorithms. In SSH1 mode, only 3DES and Blowfish are available options. In SSH2 mode, only 3DES, Blowfish, CAST128, Arcfour and AES can be selected. The patented IDEA algorithm is not supported.
OpenSSH provides support for both SSH1 and SSH2 protocols.
Since the RSA patent has expired, there are no restrictions on the use of RSA algorithm using software, including OpenBSD.
There are many places to turn to for help. In addition to the main OpenSSH website, there are many mailing lists to try. Before trying any mailing lists, please search through all mailing list archives to see if your question has already been answered. The OpenSSH Mailing List has been archived and put in searchable form and can be found at marc.info.
For more information on subscribing to OpenSSH related mailing lists, please see OpenSSH Mailing lists.
Information about submitting bug reports can be found at the OpenSSH Reporting bugs page.
If you wish to report a security bug, please contact the private developers list <email@example.com>.
The OpenSSH client uses low numbered ports for rhosts and rhosts-rsa authentication because the server needs to trust the username provided by the client. To get around this, you can add the below example to your ssh_config or ~/.ssh/config file.
Or you can specify this option on the command line, using the -o option to ssh(1) command.
$ ssh -o "UsePrivilegedPort no" host.com
In conjunction with the previous question, (2.1) OpenSSH needs root authority to be able to bind to low-numbered ports to facilitate rhosts authentication. A privileged port is also required for rhosts-rsa authentication to older SSH releases.
Additionally, for both rhosts-rsa authentication (in protocol
version 1) and hostbased authentication (in protocol version 2)
the ssh client needs to access the private host key in order to
authenticate the client machine to the server.
OpenSSH versions prior to 3.3 required the
ssh binary to be
setuid root to enable this, and you may safely remove it if you don't
want to use these authentication methods.
Starting in OpenSSH 3.3,
ssh is not setuid by default. ssh-keysign,
is used for access to the private hosts keys, and ssh does not use privileged
source ports by default. If you wish to use a privileged source port, you must
manually set the setuid bit on
SSH 2.3 and earlier versions contain a flaw in their HMAC implementation. Their code was not supplying the full data block output from the digest, and instead always provided 128 bits. For longer digests, this caused SSH 2.3 to not interoperate with OpenSSH.
OpenSSH 2.2.0 detects that SSH 2.3 has this flaw. Recent versions of SSH will have this bug fixed. Or you can add the following to SSH 2.3 sshd2_config.
Problems in interoperation have been seen because older versions of OpenSSH did not support session rekeying. However the commercial SSH 2.3 tries to negotiate this feature, and you might experience connection freezes or see the error message "Dispatch protocol error: type 20 ". To solve this problem, either upgrade to a recent OpenSSH release or disable rekeying by adding the following to your commercial SSH 2.3's ssh2_config or sshd2_config.
The old versions of SSH used a patented algorithm to encrypt their /etc/ssh/ssh_host_key. This problem will manifest as sshd(8) not being able to read its host key. To solve this, use the command below to convert your ssh_host_key to use 3DES. NOTE: Use the ssh-keygen(1) program from the Commercial SSH product, *NOT* OpenSSH for the example below.
# ssh-keygen -u -f /etc/ssh/ssh_host_key
Commercial SSH's ssh-keygen(1) program contained a bug which caused it to occasionally generate Pubkey Authentication (RSA or DSA) keys which had their Most Significant Bit (MSB) unset. Such keys were advertised as being full-length, but are actually, half the time, smaller than advertised.
OpenSSH will print warning messages when it encounters such keys. To rid yourself of these message, edit your known_hosts files and replace the incorrect key length (usually "1024") with the correct key length (usually "1023").
Check your ssh_config and sshd_config. The default configuration files disable authentication agent and X11 forwarding. To enable it, put the line below in sshd_config:
and put the following lines in ssh_config:
X11 forwarding requires a working xauth(1) binary. On OpenBSD this is in the xbase file set but will probably be different on other platforms. For OpenSSH Portable, xauth must be either found at configure time or specified via XAuthLocation in sshd_config(5) and ssh_config(5).
Note on agent interoperability: There are two different and incompatible agent forwarding mechanisms within the SSH2 protocol. OpenSSH has always used an extension of the original SSH1 agent requests, however some commercial products use a different, non-free agent forwarding protocol. This means that agent forwarding cannot be used between OpenSSH and those products.
NOTE: For users of Linux Mandrake 7.2, Mandrake modifies the XAUTHORITY environment variable in /etc/skel/.bashrc, and thus any bash user's home directory. This variable is set by OpenSSH and for either of the above options to work, you need to comment out the line:
# export XAUTHORITY=$HOME/.Xauthority
Between versions changes can be made to sshd_config or ssh_config. You should always check on these changes when upgrading versions of OpenSSH. After OpenSSH Version 2.3.0 you need to add the following to your sshd_config:
sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing:
ssh yourhost /usr/bin/true
If the above command produces any output, then you need to modify your shell initialization.
Short Answer: no.
Long Answer: scp is not standardized. The closest thing it has to a specification is "what rcp does". Since the same command is used on both ends of the connection, adding features or options risks breaking interoperability with other implementations.
New features are more likely in sftp, since the protocol is standardized (well, a draft standard), extensible, and the client and server are decoupled.
If the remote server is running sshd(8), it may be possible to ``tunnel'' certain services via ssh. This may be desirable, for example, to encrypt POP or SMTP connections, even though the software does not directly support encrypted communications. Tunnelling uses port forwarding to create a connection between the client and server. The client software must be able to specify a non-standard port to connect to for this to work.
The idea is that the user connects to the remote host using ssh, and specifies which port on the client's machine should be used to forward connections to the remote server. After that it is possible to start the service which is to be encrypted (e.g. fetchmail, irc) on the client machine, specifying the same local port passed to ssh, and the connection will be tunnelled through ssh. By default, the system running the forward will only accept connections from itself.
The options most relevant to tunnelling are the -L and -R options, which allow the user to forward connections, the -D option, which permits dynamic port forwarding, the -g option, which permits other hosts to use port forwards, and the -f option, which instructs ssh to put itself in the background after authentication. See the ssh(1) man page for further details.
This is an example of tunnelling an IRC session from client machine ``127.0.0.1'' (localhost) to remote server ``server.example.com'':
ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
This tunnels a connection to IRC server server.example.com, joining channel ``#users'', using the nickname ``pinky''. The local port used in this example is 1234. It does not matter which port is used, as long as it's greater than 1023 (remember, only root can open sockets on privileged ports) and doesn't conflict with any ports already in use. The connection is forwarded to port 6667 on the remote server, since that's the standard port for IRC services.
The remote command ``sleep 10'' was specified to allow an amount of time (10 seconds, in the example) to start the service which is to be tunnelled. If no connections are made within the time specified, ssh will exit. If more time is required, the sleep(1) value can be increased appropriately or, alternatively, the example above could be added as a function to the user's shell. See ksh(1) and csh(1) for more details about user-defined functions.
ssh also has an -N option, convenient for use with port forwarding: if -N is specified, it is not necessary to specify a remote command (``sleep 10'' in the example above). However, use of this option causes ssh to wait around for ever (as opposed to exiting after a remote command has completed), and the user must take care to manually kill(1) the process afterwards.
This is usually the result of a packet filter or NAT device timing out your TCP connection due to inactivity. You can enable ClientAliveInterval in the server's sshd_config, or enable ServerAliveInterval in the client's ssh_config (the latter is available in OpenSSH 3.8 and newer).
Enabling either option and setting the interval for less than the time it takes to time out your session will ensure that the connection is kept "fresh" in the device's connection table.
$ scp ./source:file sshserver:
OpenSSH, like most SSH implementations, reports its name and version to clients when they connect, e.g.
This information is used by clients and servers to enable protocol compatibility tweaks to work around changed, buggy or missing features in the implementation they are talking to. This protocol feature checking is still required at present because versions with incompatibilities are still in wide use.
The portable version of OpenSSH will generate spurious authentication failures at every login, similar to:
"authentication failure; (uid=0) -> root for sshd service"
These are generated because OpenSSH first tries to determine whether a user needs authentication to login (e.g. empty password). Unfortunately PAM likes to log all authentication events, this one included.
If it annoys you too much, set "PermitEmptyPasswords no" in sshd_config. This will quiet the error message at the expense of disabling logins to accounts with no password set. This is the default if you use the supplied sshd_config file.
To enable empty passwords with a version of OpenSSH built with PAM you must add the flag nullok to the end of the password checking module in the /etc/pam.d/sshd file. For example:
auth required/lib/security/pam_unix.so shadow nodelay nullok
This must be done in addition to setting "PermitEmptyPasswords yes" in the sshd_config file.
There is one caveat when using empty passwords with PAM authentication: PAM will allow any password when authenticating an account with an empty password. This breaks the check that sshd(8) uses to determine whether an account has no password set and grant users access to the account regardless of the policy specified by PermitEmptyPasswords. For this reason, it is recommended that you do not add the nullok directive to your PAM configuration file unless you specifically wish to allow empty passwords.
Large delays (more than 10 seconds) are typically caused by a problem with name resolution:
nslookupcommand to check this on both client and server by looking up the other end's name and IP address. In addition, on the server look up the name returned by the client's IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config.
Delays less than 10 seconds can have other causes.
sshthat would cause it to request moduli larger than intended (which when combined with the above resulted in significant slowdowns). Upgrading the client to 3.8 or higher will resolve this issue.
ssh-rand-helperto generate entropy is hanging. This can be investigated by running it in debug mode:
Any significant delays should be investigated and rectified, or the corresponding commands should be removed from ssh_prng_cmds.
time ssh localhost truewith a 1024-bit RSA key on otherwise unloaded hosts. OpenSSH and OpenSSL were compiled with gcc 3.3.x.
|CPU||Time (SSHv1)||Time (SSHv2)|
|170MHz SPARC/sun4m||0.74 sec||1.25 sec|
|236MHz HPPA/8200||0.44 sec||0.79 sec|
|375MHz PowerPC/604e||0.38 sec||0.51 sec|
|933MHz VIA Ezra||0.34 sec||0.44 sec|
|2.1GHz Athlon XP 2600+||0.14 sec||0.22 sec|
The Linux kernel is looking (via modprobe) for protocol family 10 (IPv6). Either load the appropriate kernel module, enter the correct alias in /etc/modules.conf or disable IPv6 in /etc/modules.conf.
For some silly reason /etc/modules.conf may also be named /etc/conf.modules.
If the password is correct password the login is still denied, the usual cause is that the system is configured to use MD5-type passwords but the crypt(3) function used by sshd doesn't understand them.
Affected accounts will have password strings in /etc/passwd or /etc/shadow that start with $1$. If password authentication fails for new accounts or accounts with recently changed passwords, but works for old accounts, this is the likely culprit.
The underlying cause is that some versions of OpenSSL have a crypt(3) function that does not understand MD5 passwords, and the link order of sshd means that OpenSSL's crypt(3) is used instead of the system's. OpensSSH's configure attempts to correct for this but is not always successful.
There are several possible solutions:
Enable sshd's built-in support for MD5 passwords at build time.
This is safe even if you have both types of encryption as sshd will select the correct algorithm for each account automatically.
./configure --with-md5-passwords [options]
If your system has a separate libcrypt library (eg Slackware 7) then you can manually add -lcrypt to the LIBS list so it's used instead of OpenSSL's:
LIBS=-lcrypt ./configure [options]
If your platforms supports PAM, you may configure sshd to use it (see section 3.15). This will mean that sshd will not verify passwords itself but will defer to the configured PAM modules.
Ensure that your OpenSSL libraries have been built to include RSA or DSA support either internally or through RSAref.
scp(1) must be in the default PATH on both the client and the server. You may need to use the --with-default-path option to specify a custom path to search on the server. This option replaces the default path, so you need to specify all the current directories on your path as well as where you have installed scp. For example:
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
Note that configuration by the server's admin will take precedence over the setting of --with-default-path. This includes resetting PATH in /etc/profile, PATH in /etc/environment on AIX, or (for 3.7p1 and above) setting PATH or SUPATH in /etc/default/login on Solaris or Reliant Unix.
Some operating systems set /dev/tty with incorrect modes, causing the reading of passwords to fail with the following error:
You have no controlling tty. Cannot read passphrase.
The solution to this is to reset the permissions on /dev/tty to mode 0666 and report the error as a bug to your OS vendor.
If there is no 'configure' file in the tar.gz file that you downloaded or make fails with "missing separator" errors, you have probably downloaded the OpenBSD distribution of OpenSSH and are attempting to compile it on another platform. Please refer to the information on the portable version.
OpenSSH may hang when exiting. This can occur when there is an active background process. This is known to occur on Linux and HP-UX. The problem can be verified by doing the following:
Try to use this instead:
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
A work around for bash users is to place "shopt -s huponexit" in either /etc/bashrc or ~/.bashrc. Otherwise, consult your shell's man page for an option to enable it to send a HUP signal to active jobs when exiting. See bug #52 for other workarounds.
ssh needs to hang, because it needs to wait:
$ ssh host command
commanddoes not need more input.
commanddoes not produce more output.
commandexits because sshd needs to tell the exit status from
In general, X11 clients using X11 R6 should work with the default setting. Some vendors, including HP, ship X11 clients with R6 and R5 libs, so some clients will work, and others will not work. This is true for HP-UX 11.X.
As documented in the 3.8 release notes,
ssh will now use untrusted X11 cookies by
default. The previous behaviour can be restored by setting
ForwardX11Trusted yes in ssh_config.
Possible symptoms include:
BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)
Typically this is caused by the file permissions on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys being more permissive than sshd allows by default.
In this case, it can be solved by executing the following on the server.
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
If this is not possible for some reason, an alternative is to set StrictModes no in sshd_config, however this is not recommended.
To use PAM at all, this option must be provided at build time. The run-time behaviour when PAM is built in varies with the version of Portable OpenSSH, and on later versions it must also be enabled by setting UsePAM to yes in sshd_config.
./configure --with-pam [options]
The behaviour of the relevant authentications options when PAM support is built in is summarised by the following table.
|<=3.6.1p2||Not applicable||Uses PAM||Uses PAM if PAMAuthenticationViaKbdInt is enabled|
|3.7p1 - 3.7.1p1||Defaults to yes||Does not use PAM||Uses PAM if UsePAM is enabled|
|3.7.1p2 - 3.8.1p1||Defaults to no||Does not use PAM ||Uses PAM if UsePAM is enabled|
|3.9p1||Defaults to no||Uses PAM if UsePAM is enabled||Uses PAM if UsePAM is enabled|
 Some vendors, notably Redhat/Fedora, have backported the PasswordAuthentication from 3.9p1 to their 3.8x based packages. If you're using a vendor-supplied package then consult their documentation.
OpenSSH Portable's PAM interface still has problems with a few modules, however we hope that this number will reduce in the future. As at the 3.9p1 release, the known problems are: