Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I work from a Mac Book Pro (called foo). I have a server where my customers scp large files to. (called bar). I frequently ssh into bar, and scp a file (called buzz) to my Mac.

bob@foo$ ssh bar  
Last login: Fri Aug 23 14:49:32 2013 from foo  
bob@bar$ scp /guest/buzz bob@foo:~
Password: 

I don't want to enter my password every time I scp a file back to my Mac because I'll eventually automate this.
I know I could setup ssh keys, but I am concerned that if someone hacks bar that they could easily access foo. (Correct me if I'm wrong)

Is there a way to copy a file from bar to foo, without a password, that wouldn't give someone full shell access to my Mac if the server was compromised?

Note: I'm thinking setting up a new user on my Mac and disabling shell access for that user might work, but I feel like there is a better way. I'd rather not add users if possible.

share|improve this question
1  
You are wrong :) Using keys is the securest approach: even if an attacker compromised bar, they would only have foo's public key. –  jasonwryan Aug 23 '13 at 21:12
1  
no, bar is scping to foo, so foo is the one with the public key. if I understand SSH keys correctly. –  strugee Aug 23 '13 at 21:26
    
Only because the OP ssh's into bar to scp back to foo... Using keys, they would just (from foo) scp bar:file . –  jasonwryan Aug 23 '13 at 21:35
    
do you check rsync for your task? –  innocent-world Aug 23 '13 at 21:35
    
I think even if you only allow SCP but no SSH. If bar gets compromised by a guy who is smart enough, he might still be able to get access to foo even without SSH. There are many ways to do this, like for example SCP-overwrite your ~/.bash_profile on bar and wait until your next login to make bashrc start a process that opens a backdoor, but I'm sure a professional hacker would have even better ideas than mine. –  mauro.stettler Aug 24 '13 at 9:24
add comment

5 Answers

up vote 1 down vote accepted

Ok, you messed things up.

From what I've understood, you just want to copy a file from bar to foo:

[file]  *bar* ------copy------> *foo*

In order to do just that, you first ssh to bar then scp file to foo:

        *bar* -------ssh------> *foo* [file]

then:

        *foo* ----scp[file]---> *bar*

If you are doing like this, you are doing it insecurely and wrong. All you have to do is scp the file back to you directly:

bob@foo$ scp bob@bar:/guest/buzz ~

in other words:

        *foo* <---scp[file]---- *bar*

Now there are a couple of problems to be solved …

How to know where the file is?

a) Use SSH in another terminal

Just open a second terminal, SSH to bar, find your file and copy/paste the path to the first one.

b) Use SFTP

SFTP (not related to FTP nor FTPS in any way!) is implemented in OpenSSH and is available by default. Just SFTP to the server and use the FTP-like commands to find you files and get them.

c) Use a GUI

Filezilla or Nautilus for instance can browse remote SFTP/SSH shares.

d) Set up certificates

When you set up certificate connection, you can do tab completion on the local side as well as on the remote side! For instance, with your buzz example, you can do:

bob@foo$ scp bob@bar:/guest/[tab][tab]

and wait a little for the list of files contained in the remote /guest/ folder.

How to set up SSH with certificates?

a) If not already done, generate your personal RSA key pair

If you've installed OpenSSH client, you can do it by typing

bob@foo$ ssh-keygen -t rsa

(look at the manual or online for all the available options). It may ask you for a password. This is not your local account password but an optional password that can be used to encrypt the private key you are about to generate.

Actually, you will generate 2 files:

  • /Users/[yourusername]/.ssh/id_rsa
  • /Users/[yourusername]/.ssh/id_rsa.pub

The first one, *id_rsa* ought to be private. By default, ssh-keygen will do everything it can to avoid making it public (using filesystem access permission). That's why it will also ask you for an (optional) password. Don't be too paranoid with that, but just remember *id_rsa* == personal key == private. This key should never ever leave your computer.

The second one is public. It requires a huge amount of computer power to get back your private key from this public certificate (I really mean HUUUUUUGE). This is perfectly safe to share it with the whole world. Even in the very unlikely event that the NSA or the likes really want to spend millions of dollars cracking your public key, your macbook will still be safe … (or not. Thinking about it, if someone wants to spend that much, you are in trouble :)

This public certificate is actually what you will put on the remote server bar.

b) How do I put my public certificate on the server?

Two options.

  1. Use ssh-copy-id if available: bob@foo$ ssh-copy-id bob@bar. Done.
  2. If it is not, copy ~/.ssh/id_rsa.pub to bar:

    bob@foo$ sftp ~/.ssh/id_rsa.pub bob@bar:pub_cert

(here, you copied your public cert id_rsa.pub from .ssh/, in your personal ~ folder to the remote computer bar in the home folder of the user bob. This is the default. Also note that id_rsa.pub has been renamed to pub_cert in the process. I used sftp just to show you that it can be used exactly as scp).

Now, we shall copy this certificate to the right location:

bob@foo$ ssh bob@bar

Now you are in bob's personal folder in bar.

bob@bar$ cat pub_cert >> .ssh/known_hosts

(here, you displayed the content of pub_cert with cat. But instead of printing it to the screen, you redirect this output to a file: .ssh/known_hosts. Note that a redirection with > would mean "replace the content of the file with this stream" while >> means "append the stream at the end of the existing file").

c) Result?

Now you can scp/sftp/ssh to bar as much as you want without having to provide a password. You can also autocomplete local and remote paths using the [tab] key.

d) What about my mac security?

With this way of doing this, you don't even need a running SSH server on your computer. Only an SSH client (the scp/sftp/ssh programs). This is safe for you even if bar is compromised.

e) What did I do exactly with these keys/certificates?

First you generated a couple of files: a private key and a public certificate. You can do a lot of things related to security and authentication with them. But in our case, with a fair bit of simplification, these are used this way:

When you try to connect to bar, you will advertise that you've got a certificate that you can use for the connection. bar will inspect various locations in the system, including ~/.ssh/known_hosts. It will find the certificate that you advertised and use it to send you encrypted data.

Actually, public certificates can encrypt stuff!

Now this is great, but how can foo understand that? Using your private key.

Private keys can decrypt stuff encrypted with the corresponding public certificate!

This is what is called asymmetric encryption.

Then, basically, the server will send a complicated password to you encrypted with your public certificate. You will receive it, decrypt it with your private key and start to use it to encrypt data with the server both ways.


Now, what if you really really want to do the things your way and SCP back to foo?

You are just asking for troubles. But to mitigate the effect of a possible compromission, you can set up a chrooted SFTP-only server. scp and ssh won't work any more, but sftp, Filezilla and stuff are gonna work.

ref: https://www.allthingsdigital.nl/2013/05/12/setting-up-an-sftp-only-account-with-openssh/

share|improve this answer
add comment

If you look at the format of the authorized_keys file, you will notice you can restrict the command allowed to be used with a specific key. This is the method that I have previously used to allow SSH action with a specified key to only a specific command, scp in this case. Look at the man page using man authorized_keys .

share|improve this answer
    
how does one look at 'man authorized_keys'? I typed it in the terminal.. just an error. –  Hermann Ingjaldsson Aug 24 '13 at 18:38
    
I have Ubuntu and it has this man page. Other Linux versions apparently do not have this man page (from your comment). I'm sure you can use your browser and look for the authorized_keys in google, can't you? –  mdpc Aug 24 '13 at 22:08
add comment

You might want to look at https://github.com/scponly/scponly/wiki/Download or you can limit your user to sftp only like so ...

# usermod -s /usr/libexec/openssh/sftp-server whoever
share|improve this answer
add comment

As others I'd suggest you directly copy from your other machine:

bob@foo$ scp bar:/guest/buzz ~

If, for whatever reason, you want to initiate the copy from bar you can create an ssh keypair on foo which allows foo to login to foo. Then you can use ssh agent to pass the key through over the same connection.

bob@foo$ ssh -A bar
password:
bob@bar$ scp /guest/buzz bar:
# no password prompt

You might also copy the public key to bar then there won't be a password prompt, or you might add a passphrase to the key, enter it when ssh'ing into bar then, due to the ssh agent, you won't need it for the connection the other way round while being secure.

share|improve this answer
add comment

As was discussed here: Bashrc disable-ing all but a given command for a given user

You can setup an rssh access which allows a user to implement only a given command and that without getting shell access.

The shortcoming is that the user can by default apply that command to folders outside his own on the system. That can apparently be solved using chroot with some work, although I havent done that yet.

Let me know if you need any help as I have just setup and tested an rssh account on my server as well and am also in the process of learning this.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.