LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat
User Name
Password
Red Hat This forum is for the discussion of Red Hat Linux.

Notices


Reply
  Search this Thread
Old 07-12-2010, 12:27 PM   #1
c0pe
LQ Newbie
 
Registered: Jul 2010
Posts: 22

Rep: Reputation: 0
my version of ssh doesn't support 'Match' and 'ForceCommand'?


Hello,
I am trying to implement a chroot directory for a group of sftp users who all manage a shared directory. The relevant portion of my sshd_config file is below:

Subsystem sftp internal-sftp

Match Group mygroup
ChrootDirectory /foo/bar
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

when I restart sshd I get these errors:
Stopping sshd: [FAILED]
Starting sshd: /etc/ssh/sshd_config: line 122: Bad configuration option: Match
/etc/ssh/sshd_config: line 126: Bad configuration option: ForceCommand
/etc/ssh/sshd_config: terminating, 2 bad configuration options
[FAILED]
my version of SSH is:
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

this is the latest yum reports as available.

according to the error is would seem both 'Match' and 'ForceCommand' statements are not supported in this version of ssh? Do I have any options aside from installing from tarball from openssh.org? If I do that would that mean I could not use yum to maintain ssh on my system anymore? Not sure what to do, I have to chroot this group of users, I can't just chroot at the global config level because I need to still be able to ssh as my admin user to this box to administer it. I need the chroot'ing only for sftp purposes.

any input would be appreciated, thanks.
 
Old 07-12-2010, 05:12 PM   #2
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora
Posts: 3,935
Blog Entries: 5

Rep: Reputation: Disabled
Remember, Red Hat generally backports security fixes rather than bumping to newer versions of applications. Depending on where you are in the RHEL support cycle (and depending on the specific app), you may not get any more major or minor version bumps. Believe it or not, this is a good thing when it comes to overall stability.

That said, you're right - RHEL5's latest openssh package (as of this writing) does not support the Match directive. Are you willing to run a second ssh daemon (on a separate tcp port) for your chrooted sftp server? If so, I can explain how I recently solved this problem. If not, I don't have a good solution for you.
 
Old 07-13-2010, 05:39 AM   #3
c0pe
LQ Newbie
 
Registered: Jul 2010
Posts: 22

Original Poster
Rep: Reputation: 0
thanks for the reply Anomie. Yes, I would be interested in hearing about what you did. I'm also considering just updating manually to latest version of openssh... if I did that, how would it effect my ongoing maintenance and could it potentially make my system unstable?
 
Old 07-13-2010, 12:08 PM   #4
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora
Posts: 3,935
Blog Entries: 5

Rep: Reputation: Disabled
If you update openssh outside of the usual method (i.e. yum), be sure to share your experiences. I personally advise against it. Things may get messy, and inexplicably stop working.

-------

Here's a quick recipe for your chrooted sftp daemon:

1. Create the sftp init script - /etc/init.d/sftpfoo
Code:
#!/bin/bash
#
# chkconfig: 35 60 25
# description: OpenSSH chrooted sftp only daemon
#
# Note that /usr/sbin/sftpfoo is simply a symlink to /usr/sbin/sshd
#

pidfile='/var/run/sftpfoo.pid'

case "${1}" in

start  ) exec -a /usr/sbin/sftpfoo /usr/sbin/sshd -f /etc/ssh/sftpfoo_config
         ;;
stop   ) kill -9 $(cat ${pidfile})
         ;;
restart) stop
         sleep 3
         start
         ;;
*      ) echo "Usage: ${0} (start|stop|restart)"
         ;;

esac

exit 0
2. Add it to chkconfig(8) consciousness and set up a symlink you'll need later.
Code:
# chkconfig --add sftpfoo
# ln -s /usr/sbin/sshd /usr/sbin/sftpfoo
3. Create your sftp config file - /etc/ssh/sftpfoo_config
Code:
Port 8822
Protocol 2
AddressFamily inet

SyslogFacility AUTHPRIV
LogLevel INFO

PermitRootLogin no

RSAAuthentication no
PubkeyAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

UsePAM no

PidFile /var/run/sftpfoo.pid

ChrootDirectory /home/chrooted
Subsystem sftp internal-sftp
4. Create your first sftp-only user
Code:
# useradd -d /nowhere -M -s /sbin/nologin baruser
5. Create the chroot directory
Code:
# mkdir -p /home/chrooted && chmod 755 /home/chrooted
6. Start the sftp service
Code:
# service sftpfoo start
-------

Now, log in remotely as baruser, specifying port 8822. (Remember to poke a hole in your firewall.)
 
1 members found this post helpful.
Old 07-13-2010, 01:43 PM   #5
c0pe
LQ Newbie
 
Registered: Jul 2010
Posts: 22

Original Poster
Rep: Reputation: 0
Many thanks Anomie, I appreciate the info!
 
Old 09-21-2011, 12:38 PM   #6
lefty.crupps
Member
 
Registered: Apr 2005
Location: Minneap USA
Distribution: Debian, Mepis, Sidux
Posts: 470

Rep: Reputation: 32
> That said, you're right - RHEL5's latest openssh package (as of this writing) does not support the Match directive
Still the case, on RHEL 5.6

Name : openssh
Arch : x86_64
Version : 4.3p2
Release : 72.el5_6.3

So lame.
 
Old 12-20-2012, 04:36 AM   #7
kinia213
LQ Newbie
 
Registered: Dec 2012
Posts: 1

Rep: Reputation: Disabled
hi anomie,

I have followed your method to create the sftpfoo running on 8822. However, I encounterd "Permission denied" when login while there is no problem with the original sshd (port 22). I tried to turn on the debug mode and found PAM authentication failed. Here are the errors. Do you have any idea how to fix it? Thanks a lot.

[root@hgcres01 ~]# ssh -v -p 28822 localhost
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 28822.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 62:3c:ab:4f:f2:c0:32:9d:99:e9:e5:c5:89:01:1b:a9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@localhost's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
root@localhost's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
root@localhost's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).
[root@hgcres01 ~]# ssh -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@localhost's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Thu Dec 20 17:40:36 2012 from 10.2.5.55
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Installed GCC version doesn't match the version the kernel was compiled with AlucardZero Linux - Software 2 02-07-2008 10:24 AM
rpmdb: Program version 4.2 doesn't match environment version jhibbets Red Hat 2 05-29-2007 09:57 PM
I need Policy Match Support for iptables cccc Debian 2 03-18-2006 02:19 PM
redhat fedora gcc version (compiled for 2.4.20) doesn't match kernel version 2.4.22 start1000 Linux - Software 0 03-16-2004 08:17 PM
ELF file version does not not match current one kakultech Linux - Software 1 10-06-2003 07:24 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat

All times are GMT -5. The time now is 09:46 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration