Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

As per security best practices one should not allow root login over SSH with password or keys. Instead, sudo should be used.

However, if one wants to use SSH (SFTP) for remote editing of server configuration files, like ones living in /etc (Apache, Cron, you name it), how this should be done?

  • Can root-accesible file remote editing over SFTP be compatible with the security best practices

  • How one should set file permissions, user groups and such that the security best practices are followed

Currently I use passphrase protected public key authentication to login as root, but I am not sure if there is something more secure I could do, so that root facing SSH logins could be disabled altogether.

The server is Ubuntu 12.04.

share|improve this question
    
So what is your client OS? Please be more specific in your question! –  SPRBRN Apr 11 '13 at 9:49
    
I fail to see why direct key-based root login should be less secure than sudo. –  jpc Jun 25 '13 at 7:59

4 Answers 4

If the remote editing is really wanted, one simple solution could be to keep a copy of /etc (or parts of it) on another local user and setup the system to copy changes from there to the real /etc. Even better would be to use a git -- or svn, or any other version control system of your choice -- and you would have additional log of changes, too.

It's also possible to setup chroot on SFTP and disable normal login for a specific account -- or limiting the login to that user only from specified IP addresses -- with the same feature of OpenSSH (Match Group etc). About that, check http://www.thegeekstuff.com/2012/03/chroot-sftp-setup/

However please remember that most configuration files on /etc make it possible to get root access just by editing them. I've seen systems configured with svn/git to check the validation of configuration files before accepting changes of the files -- that could be used for accepting only secure configuration formats.

Anyway, there's a lot of different solutions for the problem. This was only one approach.

share|improve this answer

I don't see why it wouldn't be ok to sudo edit those files through SSH. I do it all the time, e.g.

sudo nano /etc/apache2/sites-available/default

If you want to use a GUI editor, you can use X tunnelling. You have to allow it in your ssh conf file and then use the -X option on your ssh command line.

ssh -X server.example.com

Then you can edit the file file a GUI editor:

sudo gedit /etc/apache2/sites-available/default
share|improve this answer
    
This is remote editing as sense I was referring; You are running gedit on the server, not a local text editor which edits files over SSH/SFTP –  Mikko Ohtamaa Apr 11 '13 at 13:01

See this SO answer for an example of how to do this via an SSH tunnel in Sublime Text.

share|improve this answer

You can try WinSCP. It supports remote editing and can do sudo after login. With some limitations though. In particular you need to configure sudo not to ask for password.

For details refer to: http://winscp.net/eng/docs/faq_su

share|improve this answer
    
sudo without password seems very unsecure to me, especially since the topic is concerned with best practives of security. –  superuser0 Apr 11 '13 at 9:49
    
I am downvoting this answer, because, it in fact, makes system less secure and I am looking for more secure options –  Mikko Ohtamaa Apr 11 '13 at 13:02
    
I do not think it's fair. It's still safer than what you are doing at the moment. Currently you connect with full root access. While with my solution you can configure sudo to allow root access to sftp only (and e.g. forbid shell access) and if your sftp server is smart enough, you can restrict the access even more. –  Martin Prikryl Apr 11 '13 at 20:53

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.