Book HomeSSH, The Secure ShellSearch this book
PreviousNext

12.2. Problems and Solutions

In this section, we cover a wide range of difficulties, organized by category. the sidebar "The Top Ten SSH Questions" lists what, in our experience, are the most frequently asked of the frequently asked questions. We focus on problems that may occur in many versions of the SSH software on diverse operating systems. We don't address the following sorts of questions that rapidly become obsolete:

These types of problems are best solved by the SSH FAQ [Section 12.3.1, "Web Sites"] or through discussion with other SSH users.

In all questions, we will assume you have already used debug or verbose mode (e.g., ssh -v) to isolate the problem. (If you haven't, you should!)

12.2.1. General Problems

The commands ssh, scp, ssh-agent, ssh-keygen, etc., aren't doing what I expect. Even the help messages look weird.
Maybe they are SSH2 programs when you are expecting SSH1, or vice versa. Locate the executables and do an ls -l. If they are plain files, they are most likely from SSH1 or OpenSSH. If they are symbolic links, check whether they point to SSH1 or SSH2 files. (SSH2 files have names ending in "2".)
When I try to connect to an SSH server, I get the error "Connection refused."
No SSH server is running where you tried to connect. Double-check the hostname and TCP port number: perhaps the server is running on a port different from the default?
When I log in, the message of the day (/etc/motd) prints twice.
Both sshd and the login program are printing it. Disable sshd 's printing by setting the serverwide configuration keyword PrintMotd to no.
When I log in, I see two messages about email, such as "No mail" or "You have mail."
Both sshd and the login program are checking for mail. Prevent sshd from checking by setting the serverwide configuration keyword CheckMail to no.

12.2.2. Authentication Problems

12.2.2.1. General authentication problems
The SSH1 server says "Permission denied" and exits.
This occurs if all authentication techniques have failed. Run your client in debug mode and read the diagnostic messages, looking for clues. Also read our solutions to specific authentication problems in the rest of this section.

How do I authenticate without typing a password or passphrase?
The four available authentication methods for this are:

  • Public-key with ssh-agent

  • Public-key with an unencrypted key on disk (empty passphrase)

  • Trusted-host

  • Kerberos (SSH1 and OpenSSH/1 only)

Automatic authentication has a number of important issues you should carefully consider before selecting from the preceding list. [Section 11.1, "Unattended SSH: Batch or cron Jobs"]

I get prompted for my password or passphrase, but before I have time to respond, the SSH server closes the connection.
Your server's idle timeout value may be too short. If you are a system administrator of the server machine, set IdleTimeout to a larger value in the serverwide configuration file. [Section 5.4.3.3, "Idle connections"] If you are an end user of SSH1 or OpenSSH, set an idle-timeout value in authorized_keys. [Section 8.2.7, "Setting Idle Timeout "]

RequiredAuthentications doesn't work.
This feature was broken in SSH2 2.0.13, causing authentication always to fail. This problem was fixed in 2.1.0.
SilentDeny doesn't seem to work for any authentication method.
SilentDeny has nothing to do with authentication. It applies only to access control using AllowHosts and DenyHosts. If a connection is denied access by an AllowHosts or DenyHosts value, SilentDeny controls whether the client sees an informative failure message or not.

12.2.2.2. Password authentication

Password authentication isn't working.
Use ssh -v. If the connection is being refused altogether, the SSH server is probably not running, or you are connecting to the wrong port. Port 22 is the default, but the remote system administrator might have changed it. If you see "permission denied," password authentication might be disabled in the server.

Make sure the server permits password authentication in the serverwide configuration file ("PasswordAuthentication yes" for SSH1 and OpenSSH, "AllowedAuthentications password" for SSH2). Also check your client configuration file to make sure you don't have "PasswordAuthentication no".

If you are prompted for your password, but it is rejected, you might accidentally be connecting to the wrong account. Does your local username differ from the remote username? Then you must specify the remote username when connecting:

$ ssh -l my_remote_username server.example.com
$ scp myfile [email protected]:
If this still doesn't work, check your local client configuration file (~/.ssh/config or ~/.ssh2/ssh2_config) to make sure you haven't accidentally set the wrong value for the User keyword. In particular, if your configuration file contains Host values with wildcards, check that your current command line (the one that isn't working) isn't matching the wrong section in the file. [Section 7.1.3.4, "Multiple matches"]

One common problem on the server side involves OpenSSH and Pluggable Authentication Modules configuration. PAM is a general system for performing authentication, authorization, and accounting in an application-independent fashion. If your operating system supports PAM (as Linux and HPUX do, for example), OpenSSH will probably have been automatically compiled to use it. Unless you take the extra step of configuring PAM to support SSH, all password authentication will mysteriously fail. This is usually just a matter of copying the appropriate sshd.pam file from the contrib directory in the OpenSSH distribution, naming the copy "sshd" and placing it in the PAM configuration directory (usually /etc/pam.d ). The contrib directory contains several example files for different flavors of Unix. For example, on a RedHat Linux system:

# cp contrib/redhat/sshd.pam /etc/pam.d/sshd
# chown root.root /etc/pam.d/sshd
# chmod 644 /etc/pam.d/sshd
If OpenSSH isn't using PAM, and password authentication still isn't working, the compilation switches -- with-md5-passwords or -- without-shadow might be relevant. These make no difference if PAM support is enabled in OpenSSH, because they deal with how OpenSSH reads the Unix passwd map. When using PAM, the OpenSSH code doesn't read the passwd map directly; the PAM libraries do it instead. Without PAM, though, if your system is using MD5-hashed passwords instead of the more traditional crypt (DES) hash, you must use -- with-md5-passwords. You can tell which hash your system is using by inspecting the /etc/passwd and /etc/shadow files. The hashed password is the second field in each entry; if the password field in /etc/passwd is just "x", then the real entry is in /etc/shadow instead. MD5 hashes are much longer and contain a wider range of characters:

# /etc/shadow, MD5 hash
test:$1$tEMXcnZB$rDEZbQXJzUz4g2J4qYkRh.:...

# /etc/shadow, crypt hash
test:JGQfZ8DeroV22:...
Finally, you can try -- without-shadow if you suspect OpenSSH is trying to use the shadow password file, but your system doesn't use it.

The server won't let me use an empty password.
Empty passwords are insecure and should be avoided. Nevertheless, you can set "PermitEmptyPasswords yes" in the serverwide configuration file. [Section 5.6.3, "Empty Passwords"]

12.2.2.3. Trusted-host authentication
Trusted-host authentication isn't working (SSH1 RhostsRSA, SSH2 hostbased).
Use ssh -v. If everything looks right, check the following. Suppose the client user is orpheus@earth, and the target account is orpheus@hades -- that is, on host earth, user orpheus invokes ssh hades.

For SSH1 and OpenSSH/1:

  • The SSH client program must be setuid root.

  • "RhostsRSAAuthentication yes" belongs in the server and client configurations.

  • The client's public host key must be in the server's known hosts list. In this case, hades:/etc/ssh_known_hosts must contain an entry associating the name "earth" with earth's public host key, like this:

    earth 1024 37 71641647885140363140390131934...
  • The entry may be in the target account's known hosts file instead, i.e., in hades:~orpheus/.ssh/known_hosts. Take care that "earth" is the canonical name of the client host from the server's point of view. That is, if the SSH connection is coming from the address 192.168.10.1, then gethostbyname(192.168.10.1) on hades must return "earth", and not a nickname or alias for the host (e.g., if the hostname is river.earth.net, the lookup must not return just "river"). Note that this can involve multiple naming services, since gethostbyname can be configured to consult multiple sources to determine a translation (e.g., DNS, NIS, /etc/hosts). See /etc/nsswitch.conf. If your systems don't agree on canonical hostnames, you'll have no end of trouble with RhostsRSA. You can work around such problems to an extent by manually adding extra host nicknames to the known hosts file, like this:

    earth,gaia,terra 1024 37 71641647885140363140390131934...
  • Edit hades:/etc/shosts.equiv or hades:~orpheus/.shosts to allow the login. Adding earth to shosts.equiv allows any nonroot user on earth to access the account by the same name on hades. Adding earth to .shosts allows orpheus@earth to access orpheus@hades.

  • Some firewalls reject outbound connections from privileged ports. This prevents RhostsRSA authentication from working, since it relies on privileged source ports. You can use ssh -P to get a connection to the SSH server via a nonprivileged port, but you will have to use a different kind of authentication.

For SSH2:

 For OpenSSH/2:

12.2.2.4. Public-key authentication
How do I install my public key file on the remote host the first time?
Here's the general method:

  1. Generate a key pair.

  2. Copy the text of the public key into your computer's clipboard or other cut/paste buffer.

  3. Log into the remote host via SSH with password authentication, which doesn't require any special files in your remote account.

  4. Edit the appropriate authorization and key files on the remote host:

    • For SSH1 and OpenSSH/1, append the public key to ~/.ssh/authorized_keys.

    • For OpenSSH/2, append the public key to ~/.ssh/authorized_keys2.

    • For SSH2, paste the public key into a new .pub file in ~/.ssh2 (say, newkey.pub), and append the line "Key newkey.pub" to ~/.ssh2/authorization.

  5. Log out from the remote host.

  6. Log back into the remote host using public-key authentication.

When editing the remote authorization file, make sure your text editor doesn't insert line breaks into the middle of a public key. SSH1 and OpenSSH public keys are very long and must be kept on a single line.

I put my SSH public key file mykey.pub into my remote SSH directory, but public-key authentication doesn't work.
Placing a valid public key file (e.g., mykey.pub) in your SSH directory isn't sufficient. For SSH1 and OpenSSH/1, you must append the key (i.e., the contents of mykey.pub) to ~/.ssh/authorized_keys. For OpenSSH/2, append the key to ~/.ssh/authorized_keys2. For SSH2, you must add a line of text to ~/.ssh2/authorization, Key mykey.pub.

Public-key authentication isn't working.
Invoke the client in debug mode (ssh -v). Make sure:

I'm being prompted for my login password instead of my public key passphrase. Or, my connection is rejected with the error message "No further authentication methods available." (SSH2)
There are several possible causes for both of these problems:

  • Public-key authentication must be enabled in both the client and server (SSH1/OpenSSH "RSAAuthentication yes", SSH2 "AllowedAuthentications publickey").

  • Specify your remote username with -l (lowercase L) if it differs from your local username, or else the SSH server will examine the wrong remote account:

    $ ssh -l jones server.example.com
  • Check the file permissions in your server account. If certain files or directories have the wrong owner or careless access permissions, the SSH server refuses to perform public-key authentication. This is a security feature. Run ssh in verbose mode to reveal the problem:

    $ ssh -v server.example.com
...
server.example.com: Remote: Bad file modes for /u/smith/.ssh
    In your server account, make sure that the following files and directories are owned by you and aren't world writable: ~, ~/.ssh, ~/.ssh/authorized_keys, ~/.ssh2, ~/.rhosts, and ~/.shosts.

  • For SSH2, if you use the -i option to specify an identification file:

    $ ssh2 -i my-identity server.example.com
    check that my-identity is an identification file, not a private key file. (In contrast, ssh -i for SSH1 and OpenSSH expects a private key file.) Remember that SSH2 identification files are text files containing the names of private keys.

I'm being prompted for the passphrase of the wrong key.
Make sure your desired public key is in your authorization file on the SSH server machine.

Check for SSH agent problems. Are you running an agent and trying to specify another key with ssh -i or the IdentityFile keyword? The presence of an agent prevents -i and IdentityFile from working. Terminate your agent and try again.

For SSH1 and OpenSSH, if any options are specified in ~/.ssh/authorized_keys, check for typographical errors. A mistyped option causes the associated key line to be skipped silently. Remember that options are separated by commas, not whitespace.

12.2.2.5. PGP key authentication

After the PGP passphrase prompt, I am being prompted for my login password.
If you get prompted for your PGP key, and then your password:

Passphrase for pgp key "mykey": ********
  smith's password:
and you know you're typing your passphrase correctly, then first make sure you're typing your PGP passphrase correctly. (For instance, encrypt a file with that public key and decrypt it.) If so, then there might be an incompatibility between the PGP implementations on your client and server machines. We've seen this behavior when the PGP key (generated on the client machine) doesn't have sufficient bits for the PGP implementation on the server machine. Generate a new key on the server machine.

I get "Invalid pgp key id number `0276C297'"
You probably forgot the leading "0x" on the key ID, and SSH is trying to interpret a hexadecimal number as a decimal. Use PgpKeyId 0x0276C297 instead.

12.2.3. Key and Agent Problems

12.2.3.1. General key/agent problems
I generated a key with SSH1 and tried using it with another SSH1 client, such as NiftyTelnet SSH, F-Secure SSH Client, or SecureCRT, but the client complains that the key is in an invalid format.
First, make sure you generated the key using ssh-keygen1, not ssh-keygen2. SSH1 and SSH2 keys aren't compatible.

Next, make sure you transferred the key file using an appropriate file-transfer program. If you used FTP, confirm that the private key file was transferred in binary mode, or else the copy will contain garbage. The public key file should be transferred in ASCII mode.

I generated an SSH1 key and tried using it with SSH2, but it didn't work. (Or vice versa.)
This is normal. SSH1 and SSH2 keys aren't compatible.

I specified a key manually, using -i or IdentityFile, but it never gets used!
Are you running an agent? Then -i and IdentityFile don't have any effect. The first applicable key in the agent takes precedence.

12.2.3.2. ssh-keygen

Each time I run ssh-keygen, it overwrites my default identity file.
Tell ssh-keygen to write its output to a different file. For ssh-keygen in SSH1 and OpenSSH, use the -f option. For ssh-keygen2, specify the filename as the last argument on the command line; no option is needed.

Can I change the passphrase for a key without regenerating the key?
Yes. For ssh-keygen in SSH1 and OpenSSH, use the -N option, and for ssh-keygen2, use the -p option.

How do I generate a host key?
Generate a key with an empty passphrase and install it in the correct location:

# SSH1, OpenSSH  
$ ssh-keygen -N '' -b 1024 -f /etc/ssh_host_key

# SSH2 only
$ ssh-keygen2 -P -b 1024 /etc/ssh2/hostkey
Generating a key takes a long time.
Yes it may, depending on the speed of your CPU and the number of bits you have requested. DSA keys tend to take longer than RSA keys.

How many bits should I make my keys?
We recommend at least 1024 bits for strong security.

What does oOo.oOo.oOo.oOo mean, as printed by ssh-keygen2?
The manpage calls it a "progress indicator." We think it's an ASCII representation of a sine wave. Or the sound of a chattering gorilla. You can hide it with the -q flag.

12.2.3.3. ssh-agent and ssh-add
My ssh-agent isn't terminating after I log out.
If you use the single-shell method to start an agent, this is normal. You must terminate the agent yourself, either manually (bleah) or by including appropriate lines in your shell configuration files. [Section 6.3.2.1, "Single-shell method"] If you use the subshell method, the agent automatically terminates when you log out (actually, when you exit the subshell). [Section 6.3.2.2, "Subshell method"]

When I invoke ssh-add and type my passphrase, I get the error message "Could not open a connection to your authentication agent."
Follow this debugging process:

  1. Make sure you are running an ssh-agent process:

    $ /usr/bin/ps -ef | grep ssh-agent
smith 22719     1  0 23:34:44 ?        0:00 ssh-agent
    If not, you need to run an agent before ssh-add will work.

  2. Check that the agent's environment variables are set:

    $ env | grep SSH
SSH_AUTH_SOCK=/tmp/ssh-barrett/ssh-22719-agent
SSH_AGENT_PID=22720
    If not, then you probably ran ssh-agent incorrectly, like this:

    # Wrong!
$ ssh-agent
    For the single-shell method, you must use eval with backquotes:

    $ eval `ssh-agent`
    Or for the subshell method, you must instruct ssh-agent to invoke a shell:

    $ ssh-agent $SHELL
  3. Make sure the agent points to a valid socket:

     
    $ ls -lF $SSH_AUTH_SOCK
prwx --  --  --    1 smith   0 May 14 23:37 /tmp/ssh-smith/ssh-22719-agent|
    If not, your SSH_AUTH_SOCK variable might be pointing to an old socket from a previous invocation of ssh-agent, due to user error. Terminate and restart the agent properly.

12.2.3.4. Per-account authorization files

My per-account server configuration isn't taking effect.
Check the following:

  • You might be confused about which versions of SSH use which files:

    • SSH1, OpenSSH/1: ~/.ssh/authorized_keys

    • SSH2: ~/.ssh2/authorization

    • OpenSSH/2: ~/.ssh/authorized_keys2 (note this isn't in ~/.ssh2)

  • Remember that the authorized_keys and authorized_keys2 files contains keys, whereas the SSH2 authorization file contains directives referring to other key files.

  • You might have a typographical error in one of these files. Check the spelling of options, and remember to separate SSH1 authorized_keys options with commas, not whitespace. For example:

    # correct
no-x11-forwarding,no-pty 1024 35 8697511247987525784866526224505...
# INCORRECT (will silently fail)
no-x11-forwarding no-pty 1024 35 8697511247987525784866526224505...
# ALSO INCORRECT (note the extra space after "no-x11-forwarding,")
no-x11-forwarding, no-pty 1024 35 8697511247987525784866526224505...

12.2.4. Server Problems

12.2.4.1. sshd_config, sshd2_config
How do I get sshd to recognize a new configuration file?
You can terminate and restart sshd, but there's quicker way: send the "hangup" signal (SIGHUP) to sshd with kill -HUP.

I changed the sshd config file and sent SIGHUP to the server. But it didn't seem to make any difference.
sshd may have been invoked with a command-line option that overrides that keyword. Command line options remain in force and take precedence over configuration file keywords. Try terminating and restarting sshd.

12.2.5. Client Problems

12.2.5.1. General client problems

A feature of ssh or scp isn't working, but I'm sure I'm using it correctly.
The feature might have been disabled by a system administrator, either when the SSH software was compiled (Chapter 4, "Installation and Compile-Time Configuration") or during serverwide configuration (Chapter 5, "Serverwide Configuration"). Compile-time flags cannot be checked easily, but serverwide configurations are found in the files /etc/sshd_config (SSH1, OpenSSH) or /etc/ssh2/sshd2_config (SSH2). Ask your system administrator for assistance.

12.2.5.2. Client configuration file

ssh or scp is behaving unexpectedly, using features I didn't request.
The program might be responding to keywords specified in your client configuration file. [Section 7.1.3, "Client Configuration Files"] Remember that multiple sections of the config file apply if multiple Host lines match the remote machine name you specified on the command line.

My SSH1 .ssh/config file doesn't seem to work right.
Remember that after the first use of a "Host" directive in the config file, all statements are inside some Host block, because a Host block is only terminated by the start of another Host block. The ssh1 manpage suggests that you put defaults at the end of the config file, which is correct; when looking up a directive in the config file, ssh1 uses the first match it finds, so defaults should go after any Host blocks. But don't let your own indentation or whitespace fool you. The end of your file might look like:

# last Host block
Host server.example.com
 User linda

# defaults
User smith
You intend that the username for logging into server.example.com is "linda", and the default username for hosts not explicitly listed earlier is "smith". However, the line "User smith" is still inside the "Host server.example.com" block. And since there's an earlier User statement for server.example.com, "User smith" doesn't ever match anything, and ssh appears to ignore it. The right thing to do is this:

# last Host block
Host server.example.com
 User linda

# defaults
Host *
 User smith
My .ssh2/ssh2_config file doesn't seem to work right.
See our answer to the previous question for SSH1. However, SSH2 has the opposite precedence rule: if multiple configurations match your target, then the last, not the first, prevails. Therefore your defaults go at the beginning of the file.

12.2.5.3. ssh
I want to suspend ssh with the escape sequence but I am running more than two levels of ssh (machine to machine to machine). How do I suspend an intermediate ssh?
One method is to start each ssh with a different escape character; otherwise, the earliest ssh client in the chain interprets the escape character and suspends.

Or you can be clever. Remember that if you type the escape character twice, that's the meta-escape: it allows you to send the escape character itself, circumventing its usual special function. So, if you have several chained ssh sessions all using the default escape character ~, you can suspend the n th one by pressing the Return key, then n tildes, then Control-Z.

I ran an ssh command in the background on the command line, and it suspended itself, not running unless I "fg" it.
Use the -n command-line option, which instructs ssh not to read from stdin (actually, it reopens stdin on /dev/null instead of your terminal). Otherwise, the shell's job-control facility suspends the program if it reads from stdin while in the background.

ssh prints "Compression level must be from 1 (fast) to 9 (slow, best)" and exits.
Your CompressionLevel is set to an illegal value for this host, probably in your ~/.ssh/config file. It must be an integer between 1 and 9, inclusive. [Section 7.4.11, "Data Compression"]

ssh prints "rsh not available" and exits.
Your SSH connection attempt failed, and your client was configured to fall back to an rsh connection. [Section 7.4.5.8, "RSH issues"] However, the server was compiled without rsh fallback support or with an invalid path to the rsh executable. [Section 4.1.5.12, "R-commands (rsh) compatibility"]

If you didn't expect your SSH connection to fail, run the client in debug mode and look for the reason. Otherwise, the SSH server is just not set up to receive rsh connections.

ssh1 prints "Too many identity files specified (max 100)" and exits.
SSH1 has a hardcoded limit of 100 identity files (private key files) per session. Either you ran an ssh1 command line with over 100 -i options, or your configuration file ~/.ssh/config has an entry with over 100 IdentityFile keywords. You should never see this message unless your SSH command lines and/or config files are being generated automatically by another application, and something in that application has run amok. (Or else you're doing something really funky.)

ssh1 prints "Cannot fork into background without a command to execute" and exits.
You used the -f flag of ssh1, didn't you? This tells the client to put itself into the background as soon as authentication completes, and then execute whatever remote command you requested. But, you didn't provide a remote command. You typed something like:

# This is wrong
$ ssh1 -f server.example.com
The -f flag makes sense only when you give ssh1 a command to run after it goes into the background:

$ ssh1 -f server.example.com /bin/who
If you just want the SSH session for port-forwarding purposes, you may not want to give a command. You have to give one anyway; the SSH1 protocol requires it. Use sleep 100000. Don't use an infinite loop like the shell command while true; do false; done. This gives you the same effect, but your remote shell will eat all the spare CPU time on the remote machine, annoying the sysadmin and shortening your account's life expectancy.

ssh1 prints "Hostname or username is longer than 255 characters" and exits.
ssh1 has a static limit of 255 characters for the name of a remote host or a remote account (username). You instructed ssh1, either on the command line or in your configuration file, to use a hostname or username that's longer than this limit.

ssh1 prints "No host key is known for <server name> and you have requested strict checking (or `cannot confirm operation when running in batch mode')," and exits.
The client can't find the server's host key in its known-hosts list, and it is configured not to add it automatically (or is running in batch mode and so can't prompt you about adding it). You must add it manually to your per-account or systemwide known-hosts files.

ssh1 prints "Selected cipher type ... not supported by server" and exits.
You requested that ssh1 use a particular encryption cipher, but the SSH1 server doesn't support it. Normally, the SSH1 client and server negotiate to determine which cipher to use, so you probably forced a particular cipher by providing the -c flag on the ssh1 command line or by using the Cipher keyword in the configuration file. Either don't specify a cipher and let the client and server work it out, or select a different cipher.

ssh1 prints "channel_request_remote_forwarding: too many forwards" and exits.
ssh1 has a static limit of 100 forwardings per session, and you've requested more.

12.2.5.4. scp

scp printed an error message: "Write failed flushing stdout buffer. write stdout: Broken pipe." or "packet too long".
Your shell startup file (e.g., ~/.cshrc, ~/.bashrc), which is run when scp connects, might be writing a message on standard output. These interfere with the communication between the two scp1 programs (or scp2 and sftp-server). If you don't see any obvious output commands, look for stty or tset commands that might be printing something.

Either remove the offending statement from the startup file or suppress it for noninteractive sessions:

if ($?prompt) then
  echo 'Here is the message that screws up scp.'
endif
The latest versions of SSH2 have a new server configuration statement, AllowCshrcSourcingWithSubsystems, which should be set to no to prevent this problem.

scp printed an error message, "Not a regular file."
Are you trying to copy a directory? Use the -r option for a recursive copy. Otherwise, you may be trying to copy a special file that it doesn't make sense to copy, such as a device node, socket, or named pipe. If you do an ls -l of the file in question and the first character in the file description is something other than "-" (for a regular file) or "d" (for a directory), this is probably what's happening. You didn't really want to copy that file, did you?

Why don't wildcards or shell variables work on the scp command line?
Remember that wildcards and variables are expanded by the local shell first, not on the remote machine. This happens even before scp runs. So if you type:

$ scp server.example.com:a* .
the local shell attempts to find local files matching the pattern server.example.com:a*. This is probably not what you intended. You probably wanted files matching a* on server.example.com to be copied to the local machine.

Some shells, notably C shell and its derivatives, simply report "No match" and exit. Bourne shell and its derivatives (sh, ksh, bash), finding no match, will actually pass the string server.example.com:a* to the server as you'd hoped.

Similarly, if you want to copy your remote mail file to the local machine, the command:

$ scp server.example.com:$MAIL .
might not do what you intend. $MAIL is expanded locally before scp executes. Unless (by coincidence) $MAIL is the same on the local and remote machines, the command won't behave as expected.

Don't rely on shell quirks and coincidences to get your work done. Instead, escape your wildcards and variables so the local shell won't attempt to expand them:

$ scp server.example.com:a\* .
$ scp 'server.example.com:$MAIL' .
See also Appendix A, "SSH2 Manpage for sshregex" for specifics on scp2 's regular expressions.

I used scp to copy a file from the local machine to a remote machine. It ran without errors. But when I logged into the remote machine, the file wasn't there!
By any chance, did you omit a colon? Suppose you want to copy the file myfile from the local machine to server.example.com. A correct command is:

$ scp myfile server.example.com:
but if you forget the final colon:

# This is wrong!
  $ scp myfile server.example.com
myfile gets copied locally to a file called "server.example.com". Check for such a file on the local machine.

How can I give somebody access to my account by scp to copy files but not give full login permissions?
Bad idea. Even if you can limit the access to scp, this doesn't protect your account. Your friend could run:

$ scp evil_authorized_keys [email protected]:.ssh/authorized_keys
Oops, your friend has just replaced your authorized_keys file, giving himself full login permissions. Maybe you can accomplish what you want with a clever forced command, limiting the set of programs your friend may run in your account. [Section 8.2.4.3, "Displaying a command menu "]

scp -p preserves file timestamps and modes. Can it preserve file ownership?
No. Ownership of remote files is determined by SSH authentication. Suppose user smith has accounts on local computer L and remote computer R. If the local smith copies a file by scp to the remote smith account, authenticating by SSH, then the remote file is owned by the remote smith. If you want the file to be owned by a different remote user, scp must authenticate as that different user. scp has no other knowledge of users and uids, and besides, only root can change file ownership (on most modern Unix variants, anyway).

OK, scp -p doesn't preserve file ownership information. But I am the superuser, and I'm trying to copy a directory hierarchy between machines (scp -r) and the files have a variety of owners. How can I preserve the ownership information in the copies?
Don't use scp for this purpose. Use tar and pipe it through ssh. From the local machine, type:

# tar cpf - local_dir | (ssh remote_machine "cd remote_dir; tar xpf -")

12.2.5.5. sftp2

sftp2 reports "Cipher <name> is not supported. Connection lost."
Internally, sftp2 invokes an ssh2 command to contact sftp-server. [Section 3.8.2, " scp2/sftp Details"] It searches the user's PATH to locate the ssh2 executable rather than a hardcoded location. If you have more than one version of SSH2 installed on your system, sftp2 might invoke the wrong ssh2 program. This can produce the error message shown.

For example, suppose you have both SSH2 and F-Secure SSH2 installed. SSH2 is installed in the usual place, under /usr/local, whereas F-Secure is installed under /usr/local/f-secure. You ordinarily use SSH2, so /usr/local/bin is in your PATH, but /usr/local/f-secure isn't. You decide to use the F-Secure version of scp2 because you want the CAST-128 cipher, which SSH2 doesn't include. First, you confirm that the SSH server in question supports CAST-128:

$ /usr/local/f-secure/bin/ssh2 -v -c cast server
  ...
debug: c_to_s: cipher cast128-cbc, mac hmac-sha1, compression none
debug: s_to_c: cipher cast128-cbc, mac hmac-sha1, compression none
Satisfied, you try scp2 and get this:

$ /usr/local/f-secure/bin/scp2 -c cast foo server:bar
FATAL: ssh2: Cipher cast is not supported.
Connection lost.
scp2 is running the wrong copy of ssh2 from /usr/local/bin/ssh2, rather than /usr/local/f-secure/bin/ssh2. To fix this, simply put /usr/local/f-secure/bin earlier in your PATH than /usr/local/bin, or specify the alternative location of ssh2 with scp2 -S.

The same problem can occur in other situations where SSH programs run other ones. We have run afoul of it using hostbased authentication with both 2.1.0 and 2.2.0 installed. The later ssh2 ran the earlier ssh-signer2 program, and the client/signer protocol had changed, causing it to hang.

sftp2 reports "ssh_packet_wrapper_input: invalid packet received."
Although this error appears mysterious, its cause is mundane. A command in the remote account's shell startup file is printing something to standard output, even though stdout isn't a terminal in this case, and sftp2 is trying to interpret this unexpected output as part of the SFTP packet protocol. It fails and dies.

You see, sshd uses the shell to start the sftp-server subsystem. The user's shell startup file prints something, which the SFTP client tries to interpret as an SFTP protocol packet. This fails, and the client exits with the error message; the first field in a packet is the length field, which is why it's always that message.

To fix this problem, be sure your shell startup file doesn't print anything unless it's running interactively. tcsh, for example, sets the variable "$interactive" if stdin is a terminal. This problem has been addressed in SSH-2.2.0 with the AllowCshrcSourcingWithSubsystems flag, which defaults to no, instructing the shell not to run the user's startup file. [Section 5.7.1, "Disabling the Shell Startup File"]

12.2.5.6. Port forwarding

I'm trying to do port forwarding, but ssh complains: "bind: Address already in use."
The port you're trying to forward is already being used by another program on the listening side (the local host if it's a -L forwarding or the remote host if it's a -R ). Try using the netstat -a command, available on most Unix implementations and some Windows platforms. If you see an entry for your port in the LISTEN state, you know that something else is using that port. Check to see whether you've inadvertently left another ssh command running that's forwarding the same port. Otherwise, just choose another, unused port to forward.

This problem can occur when there doesn't appear to be any other program using your port, especially if you've been experimenting with the forwarding feature and have repeatedly used the same ssh to forward the same port. If the last one of these died unexpectedly (you interrupted it, or it crashed, or the connection was forcibly closed from the other side, etc.), the local TCP socket may have been left in the TIME_WAIT state (you may see this if you used the netstat program as described earlier). When this happens, you have to wait a few minutes for the socket to time out of this state and become free for use again. Of course, you can just choose another port number if you're impatient.

How do I secure FTP with port forwarding?
This is a complex topic. [Section 11.2, "FTP Forwarding"] FTP has two types of TCP connections, control and data. The control connection carries your login name, password, and FTP commands; it is on TCP port 21 and can be forwarded by the standard method. In two windows, run:

$ ssh -L2001:name.of.server.com:21 name.of.server.com
$ ftp localhost 2001
Your FTP client probably needs to run in passive mode (execute the passive command). FTP data connections carry the files being transferred. These connections occur on randomly selected TCP ports and can't be forwarded in general, unless you enjoy pain. If firewalls or NAT (network address translation) are involved, you may need additional steps (or it may not be possible).

X forwarding isn't working.
Use ssh -v, and see if the output points out an obvious problem. If not, check the following:

PreviousHomeNext
12. Troubleshooting and FAQBook Index12.3. Other SSH Resources
Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.