Redirect ssh output to file changes line endings

Question

First of all, if I do a simple ssh [email protected] "cat backup.tar" > backup.tar this is not happening! So, there is something else converting it which I don't know.

I have the requirement to provide a backup of the current state of the system without giving access to the server. What I have done is the following:

1. Create a new user. Let's call him username
2. Allow only access via ssh-key
3. Put the keys into the authorized-keys
4. Change the command / shell in /etc/passwd to a custom script for username
5. Custom script gets the data by doing a database dump and copy some files and eventually creates a tar archive to the stdout
6. Make sure that there is no additional output to stdout.

To get the data you need to do: ssh [email protected] > backup.tar.

Now, nearly everything is working fine except that the line ending is changed. The tar gets bigger and I can see that every line has the dos line ending with a ^M symbol. If I force dos2unix on the binary tar file the file matches the file on the server.

Why is this happening and what is changing the line ending? I even simplified it to the following: The script on the server for username linked in /etc/passwd just make a cat .viminfo and the line endings are still transferred wrong when using the above ssh command to login as username and redirect the output to a file on my local machine.

Answer 1

What is likely happening: when ssh is invoked with no command argument (and no RemoteCommand option specified), a pseudo-terminal is by default allocated on the remote system for the session. That happens regardless of the command the remote system is configured to run. A pseudo-terminal is usually configured to translate line feed characters into carriage return + line feed sequences (LF → CRLF, see this answer for a thorough explanation). Hence, the output of your script is written to a pseudo-terminal device, which alters it, and then sent to the client side.

The allocation of a pseudo-terminal can be prevented in several ways, including:

• invoking ssh with the -T option on the client side (or using RequestTTY no in ssh's configuration file (likely ~/.ssh/config));

• prepending no-pty (note the white space) to the user's key in authorized_keys on the remote system;

• using PermitTTY no in the configuration of the SSH server on the remote system (possibly /etc/ssh/sshd_config), likely using a Match conditional block to make it only affect a specific user); for instance:

  Match User="username"
    ForceCommand /path/to/your/script
    DisableForwarding yes
    PermitTTY no
  

  (which assumes a working command interpreter is set for the user in /etc/passwd; you may then want to lock the user's password and make sure they have no other means of logging in);

• (in your case, invoking ssh with a command argument should work too (e.g. ssh user@host :); though I would consider this no more than a workaround).

Of course, the most suitable option depends on your use case and, in particular, on whether the user is supposed to be allowed to choose.

See also:

• Creating a UNIX account which only executes one command — for a partially alternative approach, noting that, as pointed out in a comment to your question, a script used as a user's default interpreter does (may) prevent the user from getting a shell, but may also add exploitable elements of its own.

Answer 2

I am using ssh to create a tunnel for my python script. The ssh command line doesn't do anything, it has no arguments, so it tries to open a shell and a pseudo-tty.

After ssh is launched using subprocess.Popen, the newline characters of my python script get broken into just linefeed, no carriage return, so the output of the python script goes to hell. On top of that, the python script will not run under pytest for reasons I don't understand that are related to the pseudo-tty. I could get it to run under pytest with -tt supplied to the ssh, but still the normal python stdout gets corrupted. -T does not work with pytest.

I solved the problem by putting in a very long sleep command in the ssh command line; i.e. the equivalent of ssh -L 1234:remote:1234 user@remote sleep 1000000. Then no pseudo-tty funny business happens and the ssh tunnel will self close after 11 days. I only need the tunnel open for testing purposes, so the timeout is not a problem.