problem with sftp after adding user to group
 

Rhel 6.10

I am having an issue that is quite odd. I am adding a user, and that works fine. User can ssh/sftp to server.
Now, I have sshd_config set up with a group so that members of this group sftp directly to a certain directory. As soon as I add this user to that group, this user looses all ssh/sftp access.

I would try ssh user@localhost and the errors I got were:
/etc/ssh/ssh_config: line 63: Bad configuration option: Subsystem
/etc/ssh/ssh_config: line 65: Bad configuration option: Match
/etc/ssh/ssh_config: line 66: Bad configuration option: ChrootDirectory
/etc/ssh/ssh_config: line 67: Bad configuration option: AllowTcpForwarding
/etc/ssh/ssh_config: line 68: Bad configuration option: ForceCommand
/etc/ssh/ssh_config: line 69: Bad configuration option: X11Forwarding
/etc/ssh/ssh_config: terminating, 6 bad configuration options

So I renamed the ssh_config and created a new one.

That helped, sorta. Now when I attempt, I just get a straight out "Write failed: Broken pipe".

Now, I am sshed to this server as myself and running ssh user@localhost

So, I need to know what the deal is. This used to work fine with adding users into the group and the server was a-ok with it. Not sure what has changed.

Only thing I have done is try to set up nslcd for ldap authentication. Which is working. Is it possible that may have something to do with this?
The user I added is a local user, not an ldap user, so I didn't think it would affect anything.

BTW, if I remove the user from the group, ssh/sftp work again.

What do (did) you have on those lines in sshd_config? What was on line 62?

Line 62 on the old ssh_config was:
#Subsystem sftp /usr/libexec/openssh/sftp-server

The new ssh_config doesn't go to line 62.

Line 62 has nothing in sshd_config

ssh_config is for configuring the client on the local machine. ssh_config on the remote machine won't have any effect on users logging into that machine.

sshd_config for configuring the sshd server on the remote machine.

I'm now confused about what your problem actually is. I thought you were talking about the sshd configuration on the remote machine.

What does the new user look like? Any special characters in the username?

Username 10 lowercase characters, no special characters. Password does have @, but it works when SSHing to the server.
This is a remote server I am set this username up on. Then trying to connect from another machine using either sftp or scp or ssh. So, my rhel vm, to a remote server that the user/pass was set up on.

To remove the possibility of it being my rhel vm, I am trying to do ssh username@localhost

Ahh. Sorry. I got confused.
Have you tried ssh from your Windows box using PuTTY? That would take your VM out of the loop too.

Interestingly, I can't ssh user@localhost on any of my Linux machines. I get "Connection Refused". I'm sure that's a configuration issue in the local ssh_config, but it's not something I want to fix.

I'd go back to your VM, set -v (or -vv or -vvv) on your ssh/sftp attempt and review the resulting debugging messages.
I'd also restore your ssh_config, as it shows the default settings.

Have you opened a ticket with Red Hat?

Not putty but winscp. However, the errors from that are vague at best. I will try -v and see if that nets me anything useful.
Thanks!

Well, not a whole lot of useful info.
Trying to ssh with the user out/in a group netted The same info except for the last 2 lines.
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [***.***.***.***] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<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 'server' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
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-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

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: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
username@server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Write failed: Broken pipe
This is with the user added to a group.

user@server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
This is with the user NOT added to a group.
The last couple lines are the only difference, so I didn't post all the rest of the output.

I have not done a ticket yet. Redhat isn't always the speediest.

Well, so far, a ticket with redhat has been useless. This issue is only affecting 1 group in /etc/group. I have tried pulling a sshd_config file from a working server set up the same way, and that did not help. /etc/gshadow didn't even show any users in the group in question. grpconv took care of that, but it didn't help the standing issue.

So, I took all the users from the group in question, added them to a different group. They had sftp access. Went into sshd_config and changed the:

Match Group remlogin
ChrootDirectory /var/www
AllowTcpForwarding no
ForceCommand internal-sftp
X11Forwarding no
from remlogin to the new group. BAM, no access again.

So, it seems something related to sshd_config?

Edit:

so I renamed the sshd_config and reinstalled opennssh. Still the same problem.