Professional Documents
Culture Documents
OpenSSH FAQ
OpenSSH FAQ
OpenSSH FAQ
OpenSSH FAQ
1.0 - What Is OpenSSH and Where Can I Get It? 1.1 - What is OpenSSH and where can I download it?
OpenSSH provides end-to-end encrypted replacement of applications such as telnet, rlogin, and ftp. Unlike these legacy applications, OpenSSH never passes anything (including username and password) over the wire in unencrypted form, and provides host authentication, to verify that you really are talking to the system that you think you are and that no one else can take over that session. 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.
www.openssh.org/faq.html 1/10
7/23/12
OpenSSH FAQ
OpenSSH consists of a number of programs. sshd(8) - Server program run on the server machine. This listens for connections from client machines, and whenever it receives a connection, it performs authentication and starts serving the client. Its behaviour is controlled by the config file sshd_config(5). ssh(1) - This is the client program used to log into another machine or to execute commands on the other machine. slogin is another name for this program. Its behaviour is controlled by the global config file ssh_config(5) and individual users' $HOME/.ssh/config files. scp(1) - Securely copies files from one machine to another. ssh-keygen(1) - Used to create Pubkey Authentication (RSA or DSA) keys (host keys and user authentication keys). ssh-agent(1) - Authentication agent. This can be used to hold RSA keys for authentication. ssh-add(1) - Used to register new keys with the agent. sftp-server(8) - SFTP server subsystem. sftp(1) - Secure file transfer program. ssh-keyscan(1) - gather ssh public keys. ssh-keysign(8) - ssh helper program for hostbased authentication.
Downloading
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.
7/23/12
OpenSSH FAQ
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.
2.0 - General Questions 2.1 - Why does ssh/scp make connections from low-numbered ports.
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. UsePrivilegedPort no Or you can specify this option on the command line, using the -o option to ssh(1) command. $ ssh -o "UsePrivilegedPort no" host.com
www.openssh.org/faq.html 3/10
7/23/12
OpenSSH FAQ
2.3 - Why does SSH 2.3 have problems interoperating with OpenSSH 2.1.1?
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. Mac hmac-md5
2.5 - Old versions of commercial SSH encrypt host keys with IDEA.
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
7/23/12
OpenSSH FAQ
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
7/23/12
OpenSSH FAQ
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.
3.0 - Portable OpenSSH Questions 3.1 - Spurious PAM authentication messages in logfiles.
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.
7/23/12
OpenSSH FAQ
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. OpenSSH releases prior to 3.8 had an moduli file with moduli that were just smaller than what sshd would look for, and as a result, sshd would end up using moduli significantly larger than requested, which resulted in a speed penalty. Replacing the moduli file will resolve this (note that in most cases this file will not be replaced during an upgrade and must be replaced manually). OpenSSH releases prior to 3.8 had a flaw in s hthat would cause it to request moduli larger than intended (which when combined with s the above resulted in significant slowdowns). Upgrading the client to 3.8 or higher will resolve this issue. If either the client or server lack a kernel-based random number device (eg Solaris < 9, AIX < 5.2, HP-UX < 11.11) and no substitute is available (eg prngd) it's possible that one of the programs called by s h r n - e p rto generate entropy is hanging. This can be s-adhle investigated by running it in debug mode: /usr/local/libexec/ssh-rand-helper -vvv Any significant delays should be investigated and rectified, or the corresponding commands should be removed from ssh_prng_cmds.
[1] The SSHv1 protocol is faster but is cryptographically weaker than SSHv2. [2] At the time of writing, gcc generates relatively slow code on HPPA for RSA and Diffie-Hellman operations (see gcc bug #7625 and discussion on openssh-unix-dev).
3.5 - Password authentication doesn't work (eg on Slackware 7.0 or Red Hat 6.x)
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. ./configure --with-md5-passwords [options] This is safe even if you have both types of encryption as sshd will select the correct algorithm for each account automatically. 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:
www.openssh.org/faq.html 7/10
7/23/12
OpenSSH FAQ
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.
7/23/12
OpenSSH FAQ
Starting with OpenSSH 3.1, the sshd x11 forwarding server listens on localhost by default; see the sshd X11UseLocalhost option to revert to prior behaviour if your older X11 clients do not function with this configuration. 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.
3.13 - I upgraded to OpenSSH 3.8 and some X11 programs stopped working.
As documented in the 3.8 release notes, s hwill now use untrusted X11 cookies by default. The previous behaviour can be restored by setting s ForwardX11Trusted yes in ssh_config. Possible symptoms include:
Bdidw(nai Wno prmtr aWno ivld idw aaee) Bdces(tep t acs piaersuc dne) aAcs atmt o ces rvt eore eid XErro fie rqet Bdtm(nai Ao prmtr ro f ald eus: aAo ivld tm aaee) Mjrocd o fie rqet 2 (_ePoet) ao poe f ald eus: 0 XGtrpry
3.14 - I copied my public key to authorized_keys but public-key authentication still doesn't work.
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.
Not applicable Uses PAM Defaults to yes Does not use PAM
[1] 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: Modules relying on module-private data (eg pam_dhkeys, pam_krb5, AFS) may fail to correctly establish credentials (bug #688) when authenticating via ChallengeResponseAuthentication. PasswordAuthentication with 3.9p1 and above should work. You can also check bugzilla for current PAM issues.
3.16 - Why doesn't "w" or "who" on AIX 5.x show users logged in via ssh?
Between AIX 4.3.3 and AIX 5.x, the format of the wtmp struct changed. This means that sshd binaries built on AIX 4.x will not correctly write wtmp entries when run on AIX 5.x. This can be fixed by simply recompiling sshd on an AIX 5.x system and using that.
www.openssh.org/faq.html 9/10
7/23/12
OpenSSH FAQ
www@openbsd.org
$OpenBSD: faq.html,v 1.113 2012/04/21 12:12:22 dtucker Exp $
www.openssh.org/faq.html
10/10