rssh-discuss Mailing List for rssh (Page 6)
Brought to you by:
xystrus
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(15) |
Aug
(33) |
Sep
(5) |
Oct
(15) |
Nov
(8) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
(4) |
May
(4) |
Jun
(15) |
Jul
(9) |
Aug
(11) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(6) |
2005 |
Jan
(8) |
Feb
(6) |
Mar
(43) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
(12) |
Aug
(22) |
Sep
(5) |
Oct
(7) |
Nov
(15) |
Dec
(5) |
2006 |
Jan
(60) |
Feb
(7) |
Mar
(12) |
Apr
(7) |
May
(5) |
Jun
(14) |
Jul
(19) |
Aug
(21) |
Sep
(16) |
Oct
(2) |
Nov
(15) |
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
|
Jun
(26) |
Jul
(12) |
Aug
(1) |
Sep
(7) |
Oct
(2) |
Nov
|
Dec
(1) |
2008 |
Jan
(4) |
Feb
(6) |
Mar
(4) |
Apr
(4) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(27) |
Mar
(20) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(4) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(20) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
|
Dec
(7) |
2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
|
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
(8) |
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Nico Kadel-G. <nk...@gm...> - 2012-01-04 06:44:42
|
2012/1/4 Sandeep Dudam संदीप दुडम <san...@gm...>: > Hello All, > > After goggling a lot, I finally thought to post this. > ----------------------------------------------------- > > setup: sftp & rssh > > As soon as a ldap user login, it says "Connection Closed". > See the DEBUG-3 level ouput of sftp command attached. > > When following line of /etc/rssh.conf file is commented (commenting > chrootpath) then login works but I lost jailing. > This is working fine in RHEL 4. Details are mentioned below. > > chrootpath = /opt/mycomp/ds/xfer/public/ > > =============================================================================================== > > RHEL - 5.5 has following openssh & rssh package - Hold it *right* there. RHEL 5.5 is obsolete with missing security patches and a very old codebase. You should *at least* update to RHEL 5.7, with all the OpenLDAP and OpenSSH minor patches and the major rsync update. Burning time debugging 5.5 is a waste, because many such bugs have *already been fixed*. That said, if you can, jump to RHEL 6 with all those updates as well, especially the major upgrade to OpenSSH with proper GSSAPI support to play well with a Kerberized LDAP. > Linux pudslx134 2.6.18-274.3.1.el5PAE #1 SMP Fri Aug 26 18:52:57 EDT 2011 > i686 athlon i386 GNU/Linux > > Red Hat Enterprise Linux Server release 5.5 (Tikanga) > > > OpenSSH & rssh packages > ----------------------- > openssh-4.3p2-41.el5_5.1 > openssh-server-4.3p2-41.el5_5.1 > openssh-clients-4.3p2-41.el5_5.1 > rssh-2.3.2-1 (Also tried upgarding rssh to rssh-2.3.3-1.i386.rpm but > no sucess) > > /etc/rssh.conf > -------------- > logfacility = LOG_USER > allowsftp > umask = 022 > chrootpath = /opt/mycomp/ds/xfer/public/ > > > /etc/sshd/sshd_config > --------------------- > Protocol 2 > SyslogFacility AUTHPRIV > PermitRootLogin no > UsePAM yes > PasswordAuthentication no > X11Forwarding yes > ClientAliveInterval 30 > Banner /etc/banner > Subsystem sftp /usr/libexec/openssh/sftp-server > > > /etc/pam.d/system-auth > ---------------------- > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_ldap.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_ldap.so > account required pam_permit.so > > #password requisite pam_cracklib.so try_first_pass retry=3 type= > password requisite pam_passwdqc.so enforce=users retry=3 > min=disabled,disabled,disabled,8,8 > #password sufficient pam_unix.so md5 shadow nullok try_first_pass > use_authtok > password sufficient pam_ldap.so use_authtok > password sufficient pam_unix.so md5 shadow nullok try_first_pass > use_authtok remember=7 > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_ldap.so > > > Persmissions on the chroot folder - > ----------------------------------- > pudslx134@/opt/mycomp/ds/xfer > #root# ls -l > > dr-xr-xr-x 12 root other 4096 Dec 21 03:40 public > > > pudslx134@/opt/mycomp/ds/xfer/public [494] #root# ls -l -R > .: > total 40 > drwxrwxr-x 2 root root 4096 Dec 21 03:40 bin > drwxrwxr-x 2 root root 4096 Dec 21 03:40 dev > drwxrwxr-x 3 root root 4096 Dec 29 05:00 etc > drwxrwxr-x 3 root root 4096 Dec 21 03:40 home > drwxrwxr-x 2 ftp other 4096 Jun 19 2011 letter > drwxrwxr-x 2 root root 4096 Dec 21 03:40 lib > drwxrwsr-x 2 ftp other 4096 Dec 28 04:00 pcanal > drwxrwxr-x 2 ftp other 4096 Dec 29 01:45 public > drwxrwxr-x 3 admin ds_system 4096 Dec 21 03:23 update_data > drwxrwxr-x 5 root root 4096 Dec 21 03:40 usr > > ./bin: > total 0 > > ./dev: > total 0 > crw-rw-rw- 1 root root 1, 3 Dec 21 03:40 null > > ./etc: > total 52 > -rw-r--r-- 1 root root 914 Dec 21 03:40 group > -rw-r--r-- 1 root root 68 Dec 21 03:40 hosts > -rw-r--r-- 1 root root 25437 Dec 21 03:40 ld.so.cache > -rw-r--r-- 1 root root 28 Dec 21 03:40 ld.so.conf > drwxr-xr-x 2 root root 4096 Dec 14 2010 ld.so.conf.d > -rw-r--r-- 1 root root 1786 Dec 29 04:55 nsswitch.conf > -rw-r--r-- 1 root root 2535 Dec 21 03:40 passwd > > ./etc/ld.so.conf.d: > total 0 > > ./home: > total 4 > drwxrwxr-x 2 root other 4096 Dec 21 03:40 ftpusers > > ./home/ftpusers: > total 0 > > ./letter: > total 0 > > ./lib: > total 4048 > -rwxr-xr-x 1 root root 128624 Dec 21 03:41 ld-linux.so.2 > -rwxr-xr-x 1 root root 1702624 Dec 21 03:41 libc.so.6 > -rwxr-xr-x 1 root root 6300 Dec 21 03:40 libcom_err.so.2 > -rwxr-xr-x 1 root root 47712 Dec 21 03:40 libcrypt.so.1 > -rwxr-xr-x 1 root root 1315616 Dec 21 03:40 libcrypto.so.6 > -rwxr-xr-x 1 root root 18812 Dec 21 03:41 libdl.so.2 > -rwxr-xr-x 1 root root 6596 Dec 21 03:41 libkeyutils.so.1 > -rwxr-xr-x 1 root root 107924 Dec 21 03:40 libnsl.so.1 > -rwxr-xr-x 1 root root 36416 Dec 21 03:40 libnss_compat-2.5.so > -rwxr-xr-x 1 root root 36416 Dec 21 03:40 libnss_compat.so.2 > -rwxr-xr-x 1 root root 50848 Dec 21 03:40 libnss_files-2.5.so > -rwxr-xr-x 1 root root 50848 Dec 21 03:40 libnss_files.so.2 > -rwxr-xr-x 1 root root 131508 Dec 21 03:41 libpthread.so.0 > -rwxr-xr-x 1 root root 78824 Dec 21 03:40 libresolv.so.2 > -rwxr-xr-x 1 root root 91892 Dec 21 03:41 libselinux.so.1 > -rwxr-xr-x 1 root root 243928 Dec 21 03:41 libsepol.so.1 > -rwxr-xr-x 1 root root 13492 Dec 21 03:40 libutil.so.1 > > ./pcanal: > total 56 > -rw-rw-r-- 1 ftp other 6328 Jun 19 2011 op.cfg > -rw-rw-r-- 1 ftp other 417 Jun 19 2011 stat.cfg > > ./public: > total 92 > -rw-r--r-- 1 rsync ds_system 397 Dec 21 03:42 id_rsa.pub > -rw-rw-r-- 1 admin ds_system 80160 Dec 27 03:07 rcvfile1.raw.old > -rw-rw-r-- 1 admin ds_system 80 Jun 19 2011 xmtfile1.xfr > > ./update_data: > total 4 > drwxrwxr-x 2 admin ds_system 4096 Jun 19 2011 updated > > ./update_data/updated: > total 0 > > ./usr: > total 12 > drwxrwxr-x 2 root root 4096 Dec 21 03:40 bin > drwxrwxr-x 2 root root 4096 Dec 21 03:40 lib > drwxrwxr-x 3 root root 4096 Dec 21 03:40 libexec > > ./usr/bin: > total 108 > -rwxr-xr-x 1 root root 18988 Dec 21 03:40 rssh > -rwxr-xr-x 1 root root 84620 Dec 21 03:40 sftp > > ./usr/lib: > total 2600 > -rwxr-xr-x 1 root root 184812 Dec 21 03:40 libgssapi_krb5.so.2 > -rwxr-xr-x 1 root root 155640 Dec 21 03:40 libk5crypto.so.3 > -rwxr-xr-x 1 root root 611692 Dec 21 03:40 libkrb5.so.3 > -rwxr-xr-x 1 root root 32056 Dec 21 03:41 libkrb5support.so.0 > -rwxr-xr-x 1 root root 226544 Dec 21 03:41 libnspr4.so > -rwxr-xr-x 1 root root 1203764 Dec 21 03:40 libnss3.so > -rwxr-xr-x 1 root root 101180 Dec 21 03:41 libnssutil3.so > -rwxr-xr-x 1 root root 14008 Dec 21 03:41 libplc4.so > -rwxr-xr-x 1 root root 9944 Dec 21 03:41 libplds4.so > -rwxr-xr-x 1 root root 73836 Dec 21 03:40 libz.so.1 > > ./usr/libexec: > total 52 > drwxrwxr-x 2 root root 4096 Dec 21 03:40 openssh > -rwsr-xr-x 1 root root 47783 Dec 21 03:40 rssh_chroot_helper > > ./usr/libexec/openssh: > total 56 > -rwxr-xr-x 1 root root 50432 Dec 21 03:40 sftp-server > > ------------------------------------------------------------------ > > Details of LDAP user trying to login - ftpuser1 > ----------------------------------------------- > #root# ldapsearch uid=ftpuser1 > > # extended LDIF > # > # LDAPv3 > # base <dc=mycomp,dc=com> (default) with scope subtree > # filter: uid=ftpuser1 # requesting: ALL # > > # ftpuser1, People, mycomp.com > dn: uid=ftpuser1,ou=People,dc=mycomp,dc=com > uid: ftpuser1 > cn: ftpuser1 > objectClass: account > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > userPassword:: UEA1NXcwcmQ= > loginShell: /usr/bin/rssh > uidNumber: 2018 > gidNumber: 502 > homeDirectory: /opt/mycomp/ds/xfer/public/public > shadowLastChange: 15332 > shadowWarning: 7 > shadowMin: 0 > shadowMax: 99999 > gecos: ftpuser1 user > description: ftpuser1 user > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > ============================================================================================== > > RHEL - 4 has following openssh & rssh package - Rest of the setup is same. > > This is working perfectly fine here. > > Linux pudslx107 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:17:32 EST 2011 i686 > athlon i386 GNU/Linux Red Hat Enterprise Linux ES release 4 (Nahant Update > 8) > > > openssh-server-3.9p1-11.el4_7 > openssh-clients-3.9p1-11.el4_7 > openssh-3.9p1-11.el4_7 > rssh-2.3.2-1 > > > Debug logs are attached here. > > Thanks in advance. > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss > |
From: Nico Kadel-G. <nk...@gm...> - 2011-12-30 22:10:55
|
On Fri, Dec 30, 2011 at 2:47 PM, Werner Flamme <wer...@uf...> wrote: > [25.12.2011 17:03] [Nico Kadel-Garcia]: >> On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote: >>> Am 25.12.2011 04:37, schrieb Aurelin: >>> >>>>> I have this even without using rssh, so it may not be related. This >>>>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>>>> when the shell profiles have wrong owner/rights, or whenever sshd >>>>> thinks something is wrong. At least the latter is my guess... >>>> This is a possibility. You may not have some of the files with 777 >>>> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >>>> Can't tell it by heart now. It's also true that a wrong owner will make >>>> ssh go failing. >>> >>> There is no file with 777 permissions in .ssh. I am not mad, you know? >>> ;-) The rights of the directory itself, and most of its content, must be >>> 0600. Only the public keys should be world readable. And everything must >>> belong to the right owner. >> >> This is incorrect. flatly incorrect. >> >> The typical permissions are: >> >> $HOME/. 0700 (or possibly 0775, tastes vary and other settings can >> work, write permission is *optional*) >> $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other >> settings in between can work, write permission is *optional*) >> "others" should not have access to this > > I wrote the last answer from a Loosedos sation an could not look > properly) seems suicidal to me. > >> $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) >> *No one else*, either group members or "other", should have access >> to this file. >> >> Private keys can be stored however the heck you want them. SSH clients >> *do not care*, and they can be anywhere you want with whatever >> permissions you want, including $HOME/.ssh/privatekey with permissions >> 7777 if you feel like it. > > >From my man page: > ---snip--- > ssh will simply ignore a private key file if it is accessible by others. > ---pins--- > > So, you obviously have another version of ssh in use than me. I use SLES > 11 SP1 and openSUSE 12.1 with their respective openssh versions at the > office. None of them permits access by other users than me. I'd like to point you to CygWin. Windows file access gets..... *fascinating* when you have to re-interpret it inside CygWin. Also, Pageant has to deal with Windows permissions and could not care less about file ownership. So yes, it's a different client on a different filesystem, and I overshot. This is not the protocol that cares: this is intelligent default behavior written into the client. And there are some *HORRIBLE* clients out there. Ownership and permissions of the ".ssh" directory" are auto-built as 0700 when running SSH commands, but can be reset in quite open fashion. This includes 0777, allowing others to modify and replace your private keys or known_hosts file. It's the *daemon* that then gets picky about what it accepts for authorized_keys access. >>> There is no problem with that. But why doesn't sshd tell me in its log >>> the reason for closing the connection? Why do I have to resort to "ssh >>> -vvv" to discover it? >> >> Because some sone of a !@#$ can overwhelm your SSH log files with >> failed connections if it's too verbose, and the balance between useful >> information and log spew is a tricky one. > > Hm. Yes, it is. However, I do not speak of setting a high debug level on > a server that is accessible from the internet. I speak of the ssh > daemon of a server that is inside a special, isolated subrange inside my > comapny's network range. There are about 20 boxes in this range, and > there is nearly no chance to blow a log. And in that environment, you can crank up logging. >> Sorry if I seem a bit cranky about this, I've been dealing with SSH >> for a long time, and I get a bit touchy when errors get posted as "it >> has to be this way". > > Better watch this for your own post :-P - see the note about private > keys above. Fair enough. Note my followup. The permission checking is part of the particular client, not part of the protocol itself, and should be denoted accordingly. > > Have a nice 2012! > Werner > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss |
From: Werner F. <wer...@uf...> - 2011-12-30 19:47:56
|
[25.12.2011 17:03] [Nico Kadel-Garcia]: > On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote: >> Am 25.12.2011 04:37, schrieb Aurelin: >> >>>> I have this even without using rssh, so it may not be related. This >>>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>>> when the shell profiles have wrong owner/rights, or whenever sshd >>>> thinks something is wrong. At least the latter is my guess... >>> This is a possibility. You may not have some of the files with 777 >>> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >>> Can't tell it by heart now. It's also true that a wrong owner will make >>> ssh go failing. >> >> There is no file with 777 permissions in .ssh. I am not mad, you know? >> ;-) The rights of the directory itself, and most of its content, must be >> 0600. Only the public keys should be world readable. And everything must >> belong to the right owner. > > This is incorrect. flatly incorrect. > > The typical permissions are: > > $HOME/. 0700 (or possibly 0775, tastes vary and other settings can > work, write permission is *optional*) > $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other > settings in between can work, write permission is *optional*) > "others" should not have access to this I wrote the last answer from a Loosedos sation an could not look properly) seems suicidal to me. > $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) > *No one else*, either group members or "other", should have access > to this file. > > Private keys can be stored however the heck you want them. SSH clients > *do not care*, and they can be anywhere you want with whatever > permissions you want, including $HOME/.ssh/privatekey with permissions > 7777 if you feel like it. >From my man page: ---snip--- ssh will simply ignore a private key file if it is accessible by others. ---pins--- So, you obviously have another version of ssh in use than me. I use SLES 11 SP1 and openSUSE 12.1 with their respective openssh versions at the office. None of them permits access by other users than me. > >> There is no problem with that. But why doesn't sshd tell me in its log >> the reason for closing the connection? Why do I have to resort to "ssh >> -vvv" to discover it? > > Because some sone of a !@#$ can overwhelm your SSH log files with > failed connections if it's too verbose, and the balance between useful > information and log spew is a tricky one. Hm. Yes, it is. However, I do not speak of setting a high debug level on a server that is accessible from the internet. I speak of the ssh daemon of a server that is inside a special, isolated subrange inside my comapny's network range. There are about 20 boxes in this range, and there is nearly no chance to blow a log. The speciality with the problem is, that there are 22 virtual servers with one user each that are allowed to log in via ssh key. This works fine for 21, but does not work for the 22nd. As far as I can see, all parameters (files, rights, ...) are identical. Where can I start to search? Even "ssh -vvv" at the client side only tells me that the server closes the connection. But why it does so is not given (that's OK, since I might use the given reason for creating an exploit). But why isn't this reason in the server's log? > Sorry if I seem a bit cranky about this, I've been dealing with SSH > for a long time, and I get a bit touchy when errors get posted as "it > has to be this way". Better watch this for your own post :-P - see the note about private keys above. Have a nice 2012! Werner |
From: Derek M. <co...@pi...> - 2011-12-30 01:11:53
|
On Sun, Dec 25, 2011 at 11:03:24AM -0500, Nico Kadel-Garcia wrote: > Private keys can be stored however the heck you want them. SSH clients > *do not care*, and they can be anywhere you want with whatever > permissions you want, including $HOME/.ssh/privatekey with permissions > 7777 if you feel like it. Since we're being so flamboyantly and aggressively pedantic, I guess I'll point out that this is utterly false. $ chmod 777 ident $ ssh-add ident @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for 'ident' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. IIRC it's possible to force ssh to ignore this problem with an option, however doing so is fairly asinine in most instances. Having writable private keys is not a good idea, to put it mildly. Though, very rarely, it might be useful/necessary. > > There is no problem with that. But why doesn't sshd tell me in its log > > the reason for closing the connection? Why do I have to resort to "ssh > > -vvv" to discover it? > > Because some sone of a !@#$ can overwhelm your SSH log files with > failed connections if it's too verbose, and the balance between useful > information and log spew is a tricky one. Also false, though there be a kernel of truth there. First, just to be clear, ssh -vvv has no impact whatsoever on the log files. It only controls how much information *the client* reports to the user. More to the point, the reason why you need to see it in the client, in this case, is because only the client knows that it was ignoring particular files, and why it did that. The server doesn't and can't know that. All the server knows is that no key was presented that matches anything in authorized_keys. It could reasonably log that, but that information alone is only marginally useful, at best. You still need to see what the client is doing to figure out *why*. However, when debugging a tricky issue, you can run a stand-alone sshd on a separate port and enable copious debugging when you run it, also having it send the output to stderr instead of the system logs, so as not to clutter them up (you can still capture stderr to a file). When you connect to that port, sshd will log detailed info, which may or may not help, depending on what the problem actually is. Often enough, you really do need both the server side debugging AND the client side debugging turned on in order to figure out what went wrong. And that's just the way it is. For what it's worth, I have no guesses as to what's wrong with the OP's setup (Zachary Burnham). Well actually I do have one: he's using a chroot jail, and didn't rebuild the jail after updating his system. The fact that rssh didn't log *anything* is curious, and would seem to suggest that something else is wrong. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2011-12-25 16:03:31
|
On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote: > Am 25.12.2011 04:37, schrieb Aurelin: > >>> I have this even without using rssh, so it may not be related. This >>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>> when the shell profiles have wrong owner/rights, or whenever sshd >>> thinks something is wrong. At least the latter is my guess... >> This is a possibility. You may not have some of the files with 777 >> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >> Can't tell it by heart now. It's also true that a wrong owner will make >> ssh go failing. > > There is no file with 777 permissions in .ssh. I am not mad, you know? > ;-) The rights of the directory itself, and most of its content, must be > 0600. Only the public keys should be world readable. And everything must > belong to the right owner. This is incorrect. flatly incorrect. The typical permissions are: $HOME/. 0700 (or possibly 0775, tastes vary and other settings can work, write permission is *optional*) $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other settings in between can work, write permission is *optional*) "others" should not have access to this $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) *No one else*, either group members or "other", should have access to this file. Private keys can be stored however the heck you want them. SSH clients *do not care*, and they can be anywhere you want with whatever permissions you want, including $HOME/.ssh/privatekey with permissions 7777 if you feel like it. > There is no problem with that. But why doesn't sshd tell me in its log > the reason for closing the connection? Why do I have to resort to "ssh > -vvv" to discover it? Because some sone of a !@#$ can overwhelm your SSH log files with failed connections if it's too verbose, and the balance between useful information and log spew is a tricky one. Sorry if I seem a bit cranky about this, I've been dealing with SSH for a long time, and I get a bit touchy when errors get posted as "it has to be this way". >>> For me, when I try to authenticate via key, there is no chance to >>> enter a password if the key is wrong ("Server refused public key"). I >>> tried to debug with "ssh -vvv ...", and found the wrong owner of >>> ~/.bash_profile, but still have a problem with another user. >>> >> When you've got the wrong key, ssh will fail. It could be that, if you >> have 4 keys in your file and only the 4th is ok, ssh will fail to. There >> is a setting in sshd_conf (I suppose it's there) that tells the server >> how any times he shall try. If it's told to try 3 times, it will fail >> after figuring out that the first 3 keys used by the client are wrong, >> _even though the user had a password that would match_! >> Check this setting and change it or rearrange the order of the keys or >> unload them, if this thing is the case. > > I give one key. And I allow logon via password. I know from older > versions of ssh, that the password was asked after thze key failed. At > least with the RH 6 servers, this is not the case any more. > >> >> I had this problem when I had a user a wanting to log in as user b on a >> server. When user a connected to the server as b, the server said "Wrong >> public key" because the first 3 keys didn't match (since they were for >> different connections..). > > In my user a's ~./.ssh/config, there is exactly one key per server. And > this key is used. > >> It is the same with ESX where I had the problem that ESX found out I was >> using Private/Public-Key login in general. >> It then failed when I tried to log in via ILO, because I had 3 keys >> loaded and none of them was ok (obviously.. I never have a root-key for >> ILO-login..) >> Solution was to unload all keys (which made it possible to login with a >> password). > > Another possibility is to use a ~./.ssh/config with correct definitions ;-) And this is a very useful approach indeed, especially if you have multiple SSH access to one server. (One key for backups, one key for shell access is useful.) > And please don't PM me as a response to a list posting. Thank you. > > Best Regards, > Werner You too, and have a good holiday. |
From: Werner F. <wer...@uf...> - 2011-12-25 08:44:37
|
Am 25.12.2011 04:37, schrieb Aurelin: >> I have this even without using rssh, so it may not be related. This >> occurs when ~/.ssh and its contents have wrong owners or rights, or >> when the shell profiles have wrong owner/rights, or whenever sshd >> thinks something is wrong. At least the latter is my guess... > This is a possibility. You may not have some of the files with 777 > permissions in ~/.ssh/, and I _think_ it's the same for the directory. > Can't tell it by heart now. It's also true that a wrong owner will make > ssh go failing. There is no file with 777 permissions in .ssh. I am not mad, you know? ;-) The rights of the directory itself, and most of its content, must be 0600. Only the public keys should be world readable. And everything must belong to the right owner. There is no problem with that. But why doesn't sshd tell me in its log the reason for closing the connection? Why do I have to resort to "ssh -vvv" to discover it? >> >> For me, when I try to authenticate via key, there is no chance to >> enter a password if the key is wrong ("Server refused public key"). I >> tried to debug with "ssh -vvv ...", and found the wrong owner of >> ~/.bash_profile, but still have a problem with another user. >> > When you've got the wrong key, ssh will fail. It could be that, if you > have 4 keys in your file and only the 4th is ok, ssh will fail to. There > is a setting in sshd_conf (I suppose it's there) that tells the server > how any times he shall try. If it's told to try 3 times, it will fail > after figuring out that the first 3 keys used by the client are wrong, > _even though the user had a password that would match_! > Check this setting and change it or rearrange the order of the keys or > unload them, if this thing is the case. I give one key. And I allow logon via password. I know from older versions of ssh, that the password was asked after thze key failed. At least with the RH 6 servers, this is not the case any more. > > I had this problem when I had a user a wanting to log in as user b on a > server. When user a connected to the server as b, the server said "Wrong > public key" because the first 3 keys didn't match (since they were for > different connections..). In my user a's ~./.ssh/config, there is exactly one key per server. And this key is used. > It is the same with ESX where I had the problem that ESX found out I was > using Private/Public-Key login in general. > It then failed when I tried to log in via ILO, because I had 3 keys > loaded and none of them was ok (obviously.. I never have a root-key for > ILO-login..) > Solution was to unload all keys (which made it possible to login with a > password). Another possibility is to use a ~./.ssh/config with correct definitions ;-) And please don't PM me as a response to a list posting. Thank you. Best Regards, Werner |
From: Werner F. <wer...@uf...> - 2011-12-23 15:50:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zachary Burnham [05.12.2011 17:57]: > RHEL just updated its rssh package on last Wednesday (at least > that's when Rackspace upgraded our server) and it appears to have > broken something. > > When attempting to connect via FileZilla, I get the following > (logging turned up to Debug): [...] > > And in the server - side secure log I only have the following: > > Dec 5 11:33:08 webhost sshd[5551]: Accepted password for user > from xxx.xxx.xxx.xxx port 62567 ssh2 Dec 5 11:33:08 webhost > sshd[5551]: pam_unix(sshd:session): session opened for user lansing > by (uid=0) Dec 5 11:33:08 webhost sshd[5555]: subsystem request > for sftp Dec 5 11:33:08 webhost sshd[5551]: > pam_unix(sshd:session): session closed for user lansing > > No further information and nothing in the syslog from rssh. What > else can I check? This is rssh 2.3.3 . I have this even without using rssh, so it may not be related. This occurs when ~/.ssh and its contents have wrong owners or rights, or when the shell profiles have wrong owner/rights, or whenever sshd thinks something is wrong. At least the latter is my guess... For me, when I try to authenticate via key, there is no chance to enter a password if the key is wrong ("Server refused public key"). I tried to debug with "ssh -vvv ...", and found the wrong owner of ~/.bash_profile, but still have a problem with another user. Cheers, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk70mw4ACgkQk33Krq8b42OSxACfQ+6ccA1DhJINvU/gwMijGQAX 0qQAn0SROyixNP/rwmOdML2TfpfASUEA =VCLw -----END PGP SIGNATURE----- |
From: Zachary B. <zbu...@gm...> - 2011-12-05 16:57:38
|
RHEL just updated its rssh package on last Wednesday (at least that's when Rackspace upgraded our server) and it appears to have broken something. When attempting to connect via FileZilla, I get the following (logging turned up to Debug): Command: open "us...@ho..." 22 Trace: Server version: SSH-2.0-OpenSSH_4.3 Trace: Using SSH protocol version 2 Trace: We claim version: SSH-2.0-PuTTY_Local:_Nov__8_2011_21:41:54 Trace: Doing Diffie-Hellman group exchange Trace: Doing Diffie-Hellman key exchange with hash SHA-1 Trace: Host key fingerprint is: Trace: ssh-rsa 2048 e4:0b:2b:90:84:55:b4:07:5a:f4:99:e9:a9:b3:75:c4 Trace: Initialised AES-256 SDCTR client->server encryption Trace: Initialised HMAC-SHA1 client->server MAC algorithm Trace: Initialised AES-256 SDCTR server->client encryption Trace: Initialised HMAC-SHA1 server->client MAC algorithm Trace: Pageant is running. Requesting keys. Trace: Pageant has 1 SSH-2 keys Trace: Successfully loaded 1 key pair from file Trace: Trying Pageant key #0 Trace: Server refused public key Trace: Offered public key from "/Users/user/id_rsa.ppk" Trace: Server refused public key Command: Pass: *********** Trace: Sent password Trace: Access granted Trace: Opened channel for session Trace: Started a shell/command Trace: Server sent command exit status 1 Status: Connected to host.com Error: Connection closed by server with exitcode 1 Trace: CControlSocket::DoClose(64) Trace: CSftpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66) And in the server - side secure log I only have the following: Dec 5 11:33:08 webhost sshd[5551]: Accepted password for user from xxx.xxx.xxx.xxx port 62567 ssh2 Dec 5 11:33:08 webhost sshd[5551]: pam_unix(sshd:session): session opened for user lansing by (uid=0) Dec 5 11:33:08 webhost sshd[5555]: subsystem request for sftp Dec 5 11:33:08 webhost sshd[5551]: pam_unix(sshd:session): session closed for user lansing No further information and nothing in the syslog from rssh. What else can I check? This is rssh 2.3.3 . |
From: Guy M. <Guy...@ma...> - 2011-09-29 21:44:24
|
Hi! Rssh.conf entry looks like this: user="footest:011:00001:/home/footest/foo" passwd entry looks like: footest:x:32035:32035::/home/footest:/usr/bin/rssh scp look like this: [gmatz@infadmp1 ~]$ scp users.tx footest@fooprodwwwp1:/home/footest/foo lost connection That's All! :( Any advice out there? Muuuuuuch appreciated! Thanks a lot, Guy Matz ________________________________ MARKITSERV DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. MarkitSERV accepts no liability for any damage caused by any virus transmitted by this email, makes no warranty as to the accuracy or completeness of this email and hereby disclaims any liability of any kind for the information contained herein. For full details about MarkitSERV, its offerings and legal terms and conditions, please see MarkitSERV's website at http://www.markitserv.com. |
From: Derek M. <co...@pi...> - 2011-09-16 21:23:20
|
Try running rssh -v... On Fri, Sep 16, 2011 at 11:50:22AM +0200, Frederik Klama wrote: > Hi, > > I am having problems setting up rssh. > I have created a chroot Environment for the user, containing all the > commands > and libraries needed as described in the 'CHROOT' file. > However there seems to be a problem in identifying the 'sftp-server' command > as allowed. > > <begin /etc/rssh.conf> > logfacility = LOG_USER > umask = 022 > user=BSG-1668:022:00011:/chroot/BSG-1668 > <end /etc/rssh.conf> > > This is what I get in syslog when trying to connect using sftp with this > user: > <begin /var/log/messeges snippet> > Sep 14 15:40:49 iGor rssh[953]: setting log facility to LOG_USER > Sep 14 15:40:49 iGor rssh[953]: setting umask to 022 > Sep 14 15:40:49 iGor rssh[953]: user bsg-1668 attempted to execute > forbidden commands > Sep 14 15:40:49 iGor rssh[953]: command: /usr/libexec/openssh/sftp-server > <end /var/log/messages snippet> > > Any ideas as to why this command is 'forbidden' would be appreciated. > > Here some extra information: > It is a Gentoo Linux Server. > Kernel v2.6.34-xen (64bit) > rssh v2.3.3 > openssh v5.6_p1-r2 > Every bit of software was compiled on the machine itself. > > Kind regards > Frederik Klama > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Frederik K. <rs...@fk...> - 2011-09-16 10:17:33
|
Hi, I am having problems setting up rssh. I have created a chroot Environment for the user, containing all the commands and libraries needed as described in the 'CHROOT' file. However there seems to be a problem in identifying the 'sftp-server' command as allowed. <begin /etc/rssh.conf> logfacility = LOG_USER umask = 022 user=BSG-1668:022:00011:/chroot/BSG-1668 <end /etc/rssh.conf> This is what I get in syslog when trying to connect using sftp with this user: <begin /var/log/messeges snippet> Sep 14 15:40:49 iGor rssh[953]: setting log facility to LOG_USER Sep 14 15:40:49 iGor rssh[953]: setting umask to 022 Sep 14 15:40:49 iGor rssh[953]: user bsg-1668 attempted to execute forbidden commands Sep 14 15:40:49 iGor rssh[953]: command: /usr/libexec/openssh/sftp-server <end /var/log/messages snippet> Any ideas as to why this command is 'forbidden' would be appreciated. Here some extra information: It is a Gentoo Linux Server. Kernel v2.6.34-xen (64bit) rssh v2.3.3 openssh v5.6_p1-r2 Every bit of software was compiled on the machine itself. Kind regards Frederik Klama |
From: Carl T. <wo...@su...> - 2011-09-02 01:57:51
|
Hi All, I have noticed that the documentation (the CHROOT file), explicitly states that you must place a copy of the chroot_helper binary within the jail. In my testing I have found that things *appear* to work fine without it. So is the requirement a peculiarity of certain implementations or is there a security risk created by its absence? Thanks, Carl. |
From: R. D. <rap...@gm...> - 2011-08-31 15:19:02
|
Hi David, I've been running into similar situation. My OS is Centos 5.6 64bit. I managed to run rssh correctly. I've just copied the files from /lib64 to the /path/chroot/lib64 directory (without the subdirectories). I've created the chroot directory with the mkchroot.sh script, but it seems to miss some files from lib64 Maybe this can help. PS: sorry if I broke the thread, I cannot find how to answer a pre registration post. -- Raphael |
From: R. D. <rap...@gm...> - 2011-08-31 14:53:03
|
On 31/08/2011 16:31, Derek Martin wrote: > There's no possible way this is happening unless root's shell is set > to be rssh, or you've somehow overwritten root's shell in the > filesystem with rssh. Check root's entry in /etc/passwd, e.g.: > > $ grep root /etc/passwd > root:x:0:0:root:/root:/bin/bash > > If you see what you expect to see, then run root's shell with > --version or -V or whatever option that shell uses to report its > version, and make sure it really is the shell you think it is. > Well, my /etc/passwd is correctly set. the root current shell is bash according to ps -s $$ and bash --version tells me that it's really bash. but, you gave me an idea. I've run a ssh -v command and the ssh binary is replaced by rssh via a symlink. And in fact, this is entirely my mistake. I've followed a tutorial where it makes a symlink from rssh to ssh, but for another purpose... Well, thanks for the help and quick response :) -- Raphael |
From: Derek M. <co...@pi...> - 2011-08-31 14:32:10
|
On Wed, Aug 31, 2011 at 04:00:19PM +0200, Raphaël Davaillaud wrote: > I can connect to the server with root user (ssh root@server). > But then, I can't ssh other servers from here. > It says: > > > This account is restricted by rssh. > > Allowed commands: sftp > > > > If you believe this is in error, please contact your system administrator. > > Why root is restricted by rssh inside the server, while I did not > configure that? There's no possible way this is happening unless root's shell is set to be rssh, or you've somehow overwritten root's shell in the filesystem with rssh. Check root's entry in /etc/passwd, e.g.: $ grep root /etc/passwd root:x:0:0:root:/root:/bin/bash If you see what you expect to see, then run root's shell with --version or -V or whatever option that shell uses to report its version, and make sure it really is the shell you think it is. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: R. D. <rap...@gm...> - 2011-08-31 14:00:39
|
Hi, I've set up a per user configuration to restrict one of my user with rssh. I've set rssh shell to this user and only this one. I've set the correct options in rssh.conf This work like a charm. I can connect to the server with root user (ssh root@server). But then, I can't ssh other servers from here. It says: > This account is restricted by rssh. > Allowed commands: sftp > > If you believe this is in error, please contact your system administrator. Why root is restricted by rssh inside the server, while I did not configure that? Centos 5.6, openSSH 4.3p2 rssh 2.3.3 Thank you |
From: Derek M. <co...@pi...> - 2011-08-30 19:11:42
|
On Fri, Aug 26, 2011 at 03:36:53PM +0200, richard -rw- weinberger wrote: > On Fri, Aug 26, 2011 at 1:39 PM, Matthias Witte <wi...@ne...> wrote: > > Hi, > > > > Richard Weinberger has written feature patch, to include git in rssh: > > > > Website: http://www.nod.at/~richard/ > > Patch: http://www.nod.at/~richard/alltag/rssh-git.patch > > It's always nice to meet old and crappy code. ;-) I'm not sure I would call it crappy... though there are a couple of points. One is that in general, patching RSSH involves inherent badness due to the design of the config file. It wasn't really meant to be patched... Existing patches typically just update existing cases using the same numbers/bit fields, so they conflict. To be more extensible, it really needs a configuration language to replace the existing config file format. But I didn't want that... it was really meant to strictly limit the cases of access to keep the security implications manageable. Past failures have convinced me that this was the right decision; if I ever do release another version it will very probably remove support for everything other than scp/sftp, as was originally intended. This, however, is unlikely. There does seem to be a demand for such a beast though; if I ever get it in my head to experiment with a more flexible configuration parser, I may split rssh into rssh and some other thing that's more extensible. Or, I may just steal code from sudo. But at least for the moment, I have no interest in doing any of that. The other badness that immediately makes itself evident is the hard- coding of the paths of the GIT binaries. Nothing else does this, and the git support shouldn't either. Lastly, validate_access() already takes too many args; the access types should be converted to either a bit mask or a struct, probably the latter. But this again is more a "flaw" in RSSH that was somewhat included by design, than it is a weakness of the patch. Other than that -- codewise -- it basically looks fine to me. I nevertheless discourage its use without taking the time to carefully consider the security implications of using git in this fashion, which I have no intention of doing. =8^) If you aren't an expert git user/developer with 100% familiarity with its user interfaces, and understand every possible way that it might invoke some other program, then you're probably not qualified to make that judgement. My largely uneducated (with respect to git) guess is that this patch will foil casual "unlocked door" exploits, but won't keep out someone determined to get a shell on your machine. It's typical for RCS software to have hooks that can be controlled by the user which can run arbitrary programs, which tends to beat any sort of restricted shell program. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: richard -r. w. <ric...@gm...> - 2011-08-26 13:37:00
|
On Fri, Aug 26, 2011 at 1:39 PM, Matthias Witte <wi...@ne...> wrote: > Hi, > > Richard Weinberger has written feature patch, to include git in rssh: > > Website: http://www.nod.at/~richard/ > Patch: http://www.nod.at/~richard/alltag/rssh-git.patch It's always nice to meet old and crappy code. ;-) > The patch is analogue to svn patch used by debian. > > I modified that patch to allow git exports. > > The caveat is, that I am not a exactly a proficient C Programmer and > wouldn't dare to decide about the code quality of the modification. > > Is anyone interested in that patch? Post it, we'll see. :-) -- Thanks, //richard |
From: Matthias W. <wi...@ne...> - 2011-08-26 12:06:38
|
Hi, Richard Weinberger has written feature patch, to include git in rssh: Website: http://www.nod.at/~richard/ Patch: http://www.nod.at/~richard/alltag/rssh-git.patch The patch is analogue to svn patch used by debian. I modified that patch to allow git exports. The caveat is, that I am not a exactly a proficient C Programmer and wouldn't dare to decide about the code quality of the modification. Is anyone interested in that patch? Mit freundlichem Gruß, -- Matthias Witte - wi...@ne... Telefon: +49 (0)211-30 20 33-18 Telefax: +49 (0)211-30 20 33-22 [netzquadrat] GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 36121 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5719/1836, Umsatzsteuer-ID: DE246863050 |
From: Fernando F. M M. <fr...@ce...> - 2011-08-10 03:37:47
|
Q: In a Fedora system, when I connect to an account NOT configured to use a chroot jail, I just get a "Connection closed" message. Why? A: Fedora creates a group called rsshusers: rsshusers:x:488: and install rssh as /usr/bin/rsshd with permission 0750 and owher root.rsshusers: -rwxr-x--- 1 root rsshusers 24128 Mai 18 18:12 /usr/bin/rssh So, users should be included at group rsshusers to run rssh. Command used to test the connection: [frota@crux ~]$ sftp hel...@rs...domain.ex hel...@rs...domain.ex's password: Connection closed [frota@crux ~]$ scp hel...@rs...domain.ex:ap7131/* . hel...@rs...domain.ex's password: /usr/bin/rssh: Permission denied [frota@crux ~]$ scp hel...@rs...domain.ex:ap7131/* . hel...@rs...domain.ex's password: scp: ap7131/*: No such file or directory -- Fernando Frota Machado de Morais IR Team - Divisao de Redes de Comunicacao Centro de Computacao Universidade Federal de Minas Gerais Brasil Tel. +55(31)3409.4007 Fax. +55(31)3409.4004 |
From: Ben W. <bw...@ar...> - 2011-08-03 16:36:18
|
Excerpts from David White's message of Wed Aug 03 12:29:38 -0400 2011: Hi David, > I've found tons of blog posts and forum topics of people complaining > about this issue. However, I still haven't come up with a solution > that works for me. I set this up on RHEL5 recently so my experience should be similar. I used the chroot setup script (with the patch I sent to the list) to create my environment though instead of doing yum inside the chroot. You'll need to have ld-linux.so in the chroot in addition to libraries listed by ldd. Feel free to ping me off list for further assistance if you need it. (On list is fine too if the info will be useful to others.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 |
From: David W. <dw...@gm...> - 2011-08-03 16:29:45
|
I posted the following message on Serverfault a few days ago, but as I've had no response, I thought I'd post here. I'm running a CentOS 5.x server. I am trying to configure a chroot environment with rssh. I have added the user with "useradd" specifying its home directory as the chroot environment (/var/www/sage). I have also configured rssh to allow scp and sftp logins, and have configured the specific user's chroot shell: [root@elmer sage]# cat /etc/rssh.conf # This is the default rssh config file {snip} allowscp allowsftp {snip} user="sage:002:00011:/var/www/sage" I then ran rpm --root /var/www/sage --initdb to let me use yum inside it, and added the CentOS-release repository as well as the epel and ius repositories. Then I ran the equivalent of: Yum install --installroot=/var/www/sage openssh-server sftp-server rssh I then try to login as sage via SFTP, and I'm unable (the connection closes immediately). Here's what /var/log/messages says: Jul 27 21:01:28 elmer rssh[18143]: setting log facility to LOG_USER Jul 27 21:01:28 elmer rssh[18143]: allowing scp to all users Jul 27 21:01:28 elmer rssh[18143]: allowing sftp to all users Jul 27 21:01:28 elmer rssh[18143]: setting umask to 022 Jul 27 21:01:28 elmer rssh[18143]: line 52: configuring user sage Jul 27 21:01:28 elmer rssh[18143]: setting sage's umask to 02 Jul 27 21:01:28 elmer rssh[18143]: allowing scp to user sage Jul 27 21:01:28 elmer rssh[18143]: allowing sftp to user sage Jul 27 21:01:28 elmer rssh[18143]: chrooting sage to /var/www/sage Jul 27 21:01:28 elmer rssh[18143]: chroot cmd line: /usr/libexec/rssh_chroot_helper 2 "/usr/libexec/openssh/sftp-server" Here's what /var/log/secure says: Jul 27 20:57:57 elmer sshd[18094]: Accepted password for sage from 68.169.154.132 port 57766 ssh2 Jul 27 20:57:57 elmer sshd[18094]: pam_unix(sshd:session): session opened for user sage by (uid=0) Jul 27 20:57:57 elmer sshd[18096]: subsystem request for sftp I've verified that sftp-server and rssh_chroot_helper exist within the chroot under /usr/libexec/. I've also verified with ldd that all of the libraries for rssh_chroot_helper and sftp-server exist under the chroot in the appropriate places. Finally, I've tried various tricks such as running a chmod -R 777 on the whole chroot to make sure this isn't a permissions issue. I ran an strace on the ssh process. Here's how: 1) Opened up a 2nd window, and ran sftp sage@localhost 2) In my first terminal window, ran ps aux | grep sage, and find the PID 3) Ran strace -p 29188 -ff -o sage.trace 4) In the 2nd window, I then logged in. Below are the contents of sage.trace: [root@elmer ~]# cat sage.trace.29188 read(4, "t", 1) = 1 read(4, "r", 1) = 1 read(4, "E", 1) = 1 read(4, "k", 1) = 1 read(4, "u", 1) = 1 read(4, "7", 1) = 1 read(4, "R", 1) = 1 read(4, "a", 1) = 1 read(4, "\n", 1) = 1 write(4, "\n", 1) = 1 ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGINT, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 close(4) = 0 write(3, "\316\347\350\3R\224\337\375H\243a*]Fu\205pX\304%\27\272\244\3\300\337\210\344\7\233Q6"..., 144) = 144 select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "\303\273SJ\215\316\262\35\333\262\2762\r\3717\33\2\305\335\373\326\20\261\261\370\207\342\231\212\266\240\24", 8192) = 32 dup(0) = 4 dup(1) = 5 dup(2) = 6 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66fe0) = -1 ENOTTY (Inappropriate ioctl for device) fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66fe0) = -1 ENOTTY (Inappropriate ioctl for device) fcntl(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66f60) = -1 ENOTTY (Inappropriate ioctl for device) gettimeofday({1311890179, 310651}, NULL) = 0 brk(0x7f314c27c000) = 0x7f314c27c000 rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGHUP, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGHUP, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGHUP, {0x7f314b8d55c0, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGINT, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGQUIT, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGQUIT, {0x7f314b8d55c0, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGTERM, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGTERM, {0x7f314b8d55c0, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 rt_sigaction(SIGWINCH, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGWINCH, {0x7f314b8d5a50, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 select(7, [3], [3], NULL, NULL) = 1 (out [3]) write(3, "T(8\352\\\230\305\203R\237\302\245\270\216\257\241\327cg\25\327\"\4\16\23\231|\3075\316\370\223"..., 64) = 64 select(7, [3], [], NULL, NULL) = 1 (in [3]) read(3, "\3\f6\357g[\253\344\350\221\21\330\302\255%X\203\320\303\262Y\320\351\232n'\213\31\343\260\356j"..., 8192) = 48 getsockname(3, {sa_family=AF_INET, sin_port=htons(45213), sin_addr=inet_addr("127.0.0.1")}, [11362581868445696016]) = 0 setsockopt(3, SOL_IP, IP_TOS, [8], 4) = 0 select(7, [3], [3], NULL, NULL) = 1 (out [3]) write(3, "*\341\212csS_Z\0222x\f\312\306\v\226\273\177*>\337%\274\255\220\200H]\311\20\320\234"..., 128) = 128 select(7, [3], [], NULL, NULL) = 1 (in [3]) read(3, "\312|\345r\30\373_\1\346\326\3502\330`f\35xf\332~\2\233\373\352\331\214g1\23h\361+"..., 8192) = 80 select(7, [3 4], [], NULL, NULL) = 1 (in [4]) read(4, "\0\0\0\5\1\0\0\0\3", 16384) = 9 select(7, [3 4], [3], NULL, NULL) = 1 (out [3]) write(3, "\361o\215\0050f\30U\275\334E\30\0\235\251~\325\300r\301\31q\200\227G\344\252up86\263"..., 48) = 48 select(7, [3 4], [], NULL, NULL) = 1 (in [3]) read(3, "\324\1JRtRy,\200I>\211\3039\225\261\317\270\273\324\302\276`\326\221\211\364\3539{\335\277", 8192) = 32 close(5) = 0 select(7, [3 4], [], NULL, NULL) = 1 (in [3]) read(3, "\216E\300\326]\0\t\231A\277\237\203\310\221\204\206\n\332u|\350J\371=\277v_\240\303n\324f"..., 8192) = 96 close(4) = 0 close(6) = 0 select(7, [3], [3], NULL, NULL) = 1 (out [3]) write(3, "4uj\304\342\241\\\372\1\220\301\200b^\356\177\222\276\10\253I\222\374\221\316\262\240\344CJ?,", 32) = 32 rt_sigaction(SIGWINCH, NULL, {0x7f314b8d5a50, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee64e60) = -1 ENOTTY (Inappropriate ioctl for device) fcntl(0, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl(0, F_SETFL, O_RDWR) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee64e60) = -1 ENOTTY (Inappropriate ioctl for device) fcntl(1, F_GETFL) = 0x2 (flags O_RDWR) ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 brk(0x7f314c276000) = 0x7f314c276000 gettimeofday({1311890179, 788197}, NULL) = 0 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 exit_group(1) = ? I've found tons of blog posts and forum topics of people complaining about this issue. However, I still haven't come up with a solution that works for me. Thanks for any input., David -- - David White - Smooth Stone Services Computer Technical Support, IT Services, & Web Hosting Solutions http://www.smoothstoneservices.com |
From: Werner F. <wer...@uf...> - 2011-07-20 13:15:05
|
Hi everyone, just joined the list... I tried to build the package for openSUSE 11.4 x86_64, but configure complained that sftp-server was not found. This is due to the directory naming convention on openSUSE systems. The 64-bit libraries are in /lib64, /usr/lib64, and so on. The configure script searches them in /lib and /usr/lib only. So I attach a diff file that might be applied as a a patch to configure.ac. BTW, thanks for this package - simple to use and very effective! Regards, Werner |
From: Ben W. <bw...@ar...> - 2011-07-13 13:26:43
|
Use -pR when copying /etc/ld.* into the jail. Modern linux boxes may have /etc/ld.so.conf.d/ with files in that directory. We likely don't need them, but having them won't hurt. This makes the command run without error when the directory exists. Signed-off-by: Ben Walton <bw...@ar...> --- mkchroot.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mkchroot.sh b/mkchroot.sh index 5b91b51..e765e2f 100755 --- a/mkchroot.sh +++ b/mkchroot.sh @@ -148,7 +148,7 @@ echo "Setting up /etc in the chroot jail" mkdir -p "$jail_dir/etc" cp /etc/nsswitch.conf "$jail_dir/etc/" cp /etc/passwd "$jail_dir/etc/" -cp /etc/ld.* "$jail_dir/etc/" +cp -pR /etc/ld.* "$jail_dir/etc/" echo -e "Chroot jail configuration completed." echo -e "\nNOTE: if you are not using the passwd file for authentication," -- 1.7.4.1 |
From: Ben W. <bw...@ar...> - 2011-07-13 13:26:40
|
libnss1_files* seems to be a legacy thing. The files don't exist on modern Linux (RHEL5) boxes. Make the import of these files generic so that on older boxes libnss1 will still be imported but no errors will be spit out on newer ones. Signed-off-by: Ben Walton <bw...@ar...> --- mkchroot.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mkchroot.sh b/mkchroot.sh index ee98ed8..d2abae5 100755 --- a/mkchroot.sh +++ b/mkchroot.sh @@ -137,7 +137,7 @@ for prog in $scp_path $sftp_server_path $rssh_path $chroot_helper_path; do done echo "copying name service resolution libraries..." -tar -cf - /lib/libnss_files* /lib/libnss1_files* | tar -C "$jail_dir" -xvf - |sed 's/^/\t/' +tar -cf - /lib/libnss*_files* | tar -C "$jail_dir" -xvf - |sed 's/^/\t/' ##################################################################### # -- 1.7.4.1 |