Difference between pages "Updating Ebuilds" and "SFTP Only Access"

From Funtoo
(Difference between pages)
Jump to: navigation, search
 
(Quick start)
 
Line 1: Line 1:
=== Updating Ebuilds ===
+
== Context ==
  
Updating ebuilds is important. Our forked ebuilds in Funtoo Linux will go stale if they are not updated periodically, so we want to periodically bump them to new versions. Exceptions are gcc, glibc, binutils, linux-headers, python, perl and ruby and possibly a few other "core" ebuilds that we bump a few times a year in a coordinated fashion. But all other ebuilds in our tree need regular updates.
+
In some cases, it can be useful to set up an access on your Funtoo box such as a user:
 +
* does not see the whole contents of the machine but, instead, remains "jailed" in a home directory
 +
* is able to transfer files back and forth on the box via SFTP
 +
* does not have access to a shell
  
==== Overview ====
+
Such a SFTP only access is easy to setup:
  
The basic process is as follows:
+
# Assign a group (e.g. ''sftponly'') to users that must be restricted to a SFTP-only account
 +
# Change a bit the configuration of OpenSSH so that users belonging to your sftp-only group are given a chrooted access
 +
# Make OpenSSH ignore any other command than running sftp-server on the server side for users belonging to your sftp-only group (this is where the trick lies !)
  
# Create new ebuild
+
== Quick start ==
# Add ebuild masked for testing using <tt>profiles/package.mask/funtoo-staging</tt>
+
# Request testing on the funtoo-dev mailing list
+
# Move to Funtoo Linux current
+
# Move to Funtoo Linux stable
+
  
Be sure to check the history of the ebuild in funtoo by typing "<tt>git log .</tt>" and "<tt>git log -p .</tt>" in the ebuild's directory, to get an idea of why we forked it. If you have any questions, check with Daniel on IRC or via email (staff or funtoo-dev ML).
+
First, a dedicated group must be created. For the sake of the example we use sftponly here, use whatever name fits your preferences:
 +
<console>
 +
###i## groupadd sftponly
 +
</console>
  
{{fancyimportant|There is no problem pulling in the current ebuild from Gentoo ''as long as'' any existing funtoo changes are applied to the new ebuild.}}
+
Next in the configuration of OpenSSH (located in <code>/etc/sshd/sshd_config</code>) locate:
 +
<pre>
 +
Subsystem      sftp    /usr/lib64/misc/sftp-server
 +
</pre>
 +
and change it to:
 +
<pre>
 +
Subsystem      sftp    internal-sftp
 +
</pre>
  
==== Steps to determine Funtoo changes ====
+
Now the $100 question: ''"how can OpenSSH can be told to restrict a user access to a simple sftp session?"'' Simple! Assuming that ''sftponly'' is the group you use for for your restricted users, just add to the file <code>/etc/sshd/sshd_config</code> the following statement:
  
# <tt>diff -uRN <i>matching-gentoo-version</i> <i>funtoo-version</i></tt>
+
<console>
# Note any differences on the Funtoo side; these should be preserved.
+
###i## nano /etc/sshd/sshd_config
# Create new funtoo version based on new gentoo version, with Funtoo changes/patches applied.
+
# Restricted users, no TCP connexions bouncing, no X tunneling.
 +
Match group sftponly
 +
        ChrootDirectory /home/%u
 +
        X11Forwarding no
 +
        AllowTcpForwarding no
 +
        ForceCommand internal-sftp
 +
</console>
  
Note that often times, there are no significant changes on the Gentoo side, so the best course of action is to:
+
To understand how it works, you must be aware that, when you open an SSH session, the SSHD process launch a process on the server side which could be:
 +
* a shell => ssh <code>login@host</code>
 +
* a kind of dedicated ftp daemon (sftp-server) => sftp <code>user@host</code>
  
# <tt>cp <i>funtoo-version</i> <i>new-funtoo-version</i></tt>
+
{{Note}}TBC
# tweak <i>new-funtoo-version</i> as necessary.
+
  
The general principle for lightly-Funtoo-modified ebuilds is that we want to apply any necessary or recommended upstream Gentoo changes, within reason, while preserving the Funtoo modifications that have been made.
+
[[Category:HOWTO]]
 
+
The general principle for heavily-Funtoo-modified ebuilds is to understand the scope of the Funtoo changes and what Daniel is trying to do with the ebuild. Often times I am removing cruft from overly-complicated ebuilds to make them more maintainable. A lot of times, I have completely rewritten or redesigned ebuilds. In these cases, we want to look at the Gentoo ebuild more for ideas and for new patches that we might want to consider, but not be so hasty to apply them. We want to apply them only if they make sense for our plans for the ebuild.
+
 
+
==== Steps After Ebuilds Are Updated ====
+
 
+
If you have updated the ebuild to Funtoo standards, and are comfortable that it is ready for inclusion in Funtoo Linux, then follow these steps. If the ebuild is not ready yet, be sure to follow-through and either hand off the ebuild to someone else or check with Daniel to get your questions answered so it can be completed.
+
 
+
General steps to follow once the ebuild is ready for inclusion in Funtoo:
+
 
+
# Masking - Mask the ebuild in <tt>profiles/package.mask/funtoo-staging</tt> - put your masks at the top of the file (reverse chronological order.)
+
# Communicate - Post to the funtoo-dev mailing list and forums announcing the new masked ebuilds, noting that they are available for testing.
+
# Monitor - Monitor community resources for success or failure reports for testing.
+
# If we have sufficient positive replies, and no outstanding issues, move to Funtoo Linux current.
+
# After a period of 2-3 days, move to Funtoo Linux stable.
+
 
+
==== The List ====
+
 
+
{{fancyimportant|If you are going to do one of these things, put your name after it so others know :)}}
+
 
+
Here's a list of ebuilds that need updating:
+
 
+
* dhcpcd-5.2.11 (or later?) [golodhrim] {already in portage and stable newer versions will follow}
+
* gdisk-0.6.14 [angry_vincent] {already in portage for testing} / [404_Error] {Functional on sparc64, not to be used with system disks due to OpenBoot incompatibilities}
+
* bash [angry-vincent] {already in portage for testing}
+
* tar-1.25+ [angry_vincent] (tar-1.24 had problems with device nodes creation, this is fixed in >=tar-1.25, testing with metro builds) / [404_Error] {Remains to be tested on sparc64}
+
* sandbox-2.5 (needs some testing in metro) [angry-vincent/golodhrim] {testing running/golodhrim testing done, working perfect in metro} / [404_Error] {Remains to be tested on sparc64}
+
* klibc-1.5.20 (test with uvesafb)
+
* dev-lang/perl-5.12.2-r6 [404_error] {already in portage for testing, no issues on sparc64 and amd64 at deployment, perl-cleaner passes, remains to be tested in the long term especially with day to day usage}, -r2 suffers of a parallelism issue
+
 
+
Stuff I (drobbins) can handle:
+
 
+
* feedparser-5.0.1
+
* openvz-sources
+
* genkernel {QSG written, some parts to be completed}
+
 
+
__NOTITLE__
+

Revision as of 21:13, 14 January 2014

Context

In some cases, it can be useful to set up an access on your Funtoo box such as a user:

  • does not see the whole contents of the machine but, instead, remains "jailed" in a home directory
  • is able to transfer files back and forth on the box via SFTP
  • does not have access to a shell

Such a SFTP only access is easy to setup:

  1. Assign a group (e.g. sftponly) to users that must be restricted to a SFTP-only account
  2. Change a bit the configuration of OpenSSH so that users belonging to your sftp-only group are given a chrooted access
  3. Make OpenSSH ignore any other command than running sftp-server on the server side for users belonging to your sftp-only group (this is where the trick lies !)

Quick start

First, a dedicated group must be created. For the sake of the example we use sftponly here, use whatever name fits your preferences:

# groupadd sftponly

Next in the configuration of OpenSSH (located in /etc/sshd/sshd_config) locate:

Subsystem      sftp    /usr/lib64/misc/sftp-server

and change it to:

Subsystem      sftp    internal-sftp

Now the $100 question: "how can OpenSSH can be told to restrict a user access to a simple sftp session?" Simple! Assuming that sftponly is the group you use for for your restricted users, just add to the file /etc/sshd/sshd_config the following statement:

# nano /etc/sshd/sshd_config
# Restricted users, no TCP connexions bouncing, no X tunneling.
Match group sftponly
        ChrootDirectory /home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

To understand how it works, you must be aware that, when you open an SSH session, the SSHD process launch a process on the server side which could be:

  • a shell => ssh login@host
  • a kind of dedicated ftp daemon (sftp-server) => sftp user@host

Note Note: TBC