Mailing List Archive

--- On Sun, 1/17/10, Yarin <yarin@warpmail.net> wrote:
>
> I'm trying to get SSH to work with a non-root user in a VPS
> Container running CentOS 5.3. But with no luck.
>
> The remote machine's /etc/ssh/sshd_config file looks like
> this: (with comment lines stripped)
>

> Protocol 2
> SyslogFacility AUTHPRIV
> PasswordAuthentication yes
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> UsePAM yes
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE
>
> Thanks for any help that you may be able to provide,
> Yarin

Try: UsePAM no

> From: "Yarin" <yarin@warpmail.net>
> To: "ssh securityfocus" <secureshell@securityfocus.com>
> Date: 01/18/2010 01:53 PM
> Subject: Can't log in as anything but root via SSH
> Sent by: listbounce@securityfocus.com
>
> Hello all,
>
> I'm trying to get SSH to work with a non-root user in a VPS
> Container running CentOS 5.3. But with no luck.
> I can log in to root with no problem, but no matter which way I try,
> I can't log in to any normal users that I make. When I try to log in
> via SSH, it always fails, and behaves exactly as if though I was
> entering the wrong password. (I am entering the right one, though,
> I've make sure of that)
>
> Here I try to log into user "fmain": (with debugging view enabled)
>
>
> # ssh 109.107.120.17 -l fmain -v
> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 109.107.120.17 [109.107.120.17] port 22.
> debug1: Connection established.
> debug1: identity file /home/yarin/.ssh/identity type -1
> debug1: identity file /home/yarin/.ssh/id_rsa type -1
> debug1: identity file /home/yarin/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.2
> 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 '109.107.120.17' is known and matches the RSA host key.
> debug1: Found key in /home/yarin/.ssh/known_hosts:1
> 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
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/yarin/.ssh/identity
> debug1: Trying private key: /home/yarin/.ssh/id_rsa
> debug1: Trying private key: /home/yarin/.ssh/id_dsa
> debug1: Next authentication method: password
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17'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).
>
>
> The debugging comments are all the same when I successfully log in
> to root, except for everything beyond "root@109.107.120.17's
> password:" of course.
>
> I checked, and all relevent /devs (on the the remote machine) have
> 666 privs minimum, so that's not the problem.
>
> The remote machine's /etc/ssh/sshd_config file looks like this:
> (with comment lines stripped)
>
>
> Protocol 2
> SyslogFacility AUTHPRIV
> PasswordAuthentication yes
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> UsePAM yes
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL
> X11Forwarding no
> Subsystem sftp /usr/libexec/openssh/sftp-server
>
>
> I even tried adding "AllowUsers root fmain" to it, and restarting
> the SSH Daemon, but was no help.
>
> From my googling, there are plenty of people with the opposite
> problem (can log in, just not through root). And I tried everything
> that the few who seemed to have this same problem had done.
> I've exhausted my searching options and don't know where to go from
> here. Anyone have any ideas?
>
> Thanks for any help that you may be able to provide,
> Yarin

Yarin,

Did you check the permissions on the users' .ssh directory? The directory
should be owned by the user and have permissions 700. The private keys and
known_hosts files should be permission 600, while the public keys and
authorized_keys should be 644.

Chris

On the remote machine, try running "login" command, or logging into a
tty (in other words, on the remote machine do alt+crtl+f1 and login
with the fmain user). Can you use login to login as this user?

Also, try:
su root
su some_other_user
su fmain

It should prompt you for the password for fmain. Does it accept it.

If so, please paste your /etc/pam.d/sshd (or /etc/pam.d/ssh) file.

Quintin Beukes



On Mon, Jan 18, 2010 at 12:43 AM, Yarin <yarin@warpmail.net> wrote:
> Hello all,
>
> I'm trying to get SSH to work with a non-root user in a VPS Container running CentOS 5.3. But with no luck.
> I can log in to root with no problem, but no matter which way I try, I can't log in to any normal users that I make. When I try to log in via SSH, it always fails, and behaves exactly as if though I was entering the wrong password. (I am entering the right one, though, I've make sure of that)
>
> Here I try to log into user "fmain": (with debugging view enabled)
>
>
> # ssh 109.107.120.17 -l fmain -v
> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 109.107.120.17 [109.107.120.17] port 22.
> debug1: Connection established.
> debug1: identity file /home/yarin/.ssh/identity type -1
> debug1: identity file /home/yarin/.ssh/id_rsa type -1
> debug1: identity file /home/yarin/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.2
> 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 '109.107.120.17' is known and matches the RSA host key.
> debug1: Found key in /home/yarin/.ssh/known_hosts:1
> 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
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/yarin/.ssh/identity
> debug1: Trying private key: /home/yarin/.ssh/id_rsa
> debug1: Trying private key: /home/yarin/.ssh/id_dsa
> debug1: Next authentication method: password
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17'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).
>
>
> The debugging comments are all the same when I successfully log in to root, except for everything beyond "root@109.107.120.17's password:" of course.
>
> I checked, and all relevent /devs (on the the remote machine) have 666 privs minimum, so that's not the problem.
>
> The remote machine's /etc/ssh/sshd_config file looks like this: (with comment lines stripped)
>
>
> Protocol 2
> SyslogFacility AUTHPRIV
> PasswordAuthentication yes
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> UsePAM yes
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL
> X11Forwarding no
> Subsystem sftp /usr/libexec/openssh/sftp-server
>
>
> I even tried adding "AllowUsers root fmain" to it, and restarting the SSH Daemon, but was no help.
>
> From my googling, there are plenty of people with the opposite problem (can log in, just not through root). And I tried everything that the few who seemed to have this same problem had done.
> I've exhausted my searching options and don't know where to go from here. Anyone have any ideas?
>
> Thanks for any help that you may be able to provide,
> Yarin
>

On or about Sun, 2010-01-17 at 16:43, give or take -0600, Yarin wrote:
> Hello all,

> Here I try to log into user "fmain": (with debugging view enabled)
>
>
> # ssh 109.107.120.17 -l fmain -v
> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 109.107.120.17 [109.107.120.17] port 22.
> debug1: Connection established.
> debug1: identity file /home/yarin/.ssh/identity type -1
> debug1: identity file /home/yarin/.ssh/id_rsa type -1
> debug1: identity file /home/yarin/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.2
snipped..
> I even tried adding "AllowUsers root fmain" to it, and restarting the SSH Daemon, but was no help.
>
> From my googling, there are plenty of people with the opposite problem (can log in, just not through root). And I tried everything that the few who seemed to have this same problem had done.
> I've exhausted my searching options and don't know where to go from here. Anyone have any ideas?
>
> Thanks for any help that you may be able to provide,
> Yarin
>


Are you sure you're connecting to the correct machine? To prove it,
sudo/su/login-as-root locally (if you can) confirm the hostname, then
touch a file in the /root directory called "this_is_the_CentOS_VPS.0"

Next, when you login "as root over SSH", run ls -ltr and look for that
file - if you don't see it, then maybe you are into the wrong machine :)

eg:
$ssh root@109.107.120.17
password:
[login banner and motd stuff here]
#hostname
centos-VPS <---presumably, if not, read on below*****
# touch this_is_the_CentOS_VPS.0
this produces the foillowing file
#ls -ltr

-rw-r--r-- 1 root root 0 2010-01-18 20:04 this_is_the_centos-vps.0

this file proves what machine you are actually SSH-ed into.


If not, read on:

***** A common SSH gotcha occurs when the machine you are trying to
login to (the CentOS VPS one) is actually behind a firewall (or host
NAT, maybe for virtualization) that serves (and answers instead) SSH on
port 22 ( it answers instead, not knowing who root is - root login
disallowed usually - or who user1@, user2@ is )

What happens is, you attempt to ssh in with

$ssh user@y.y.y.y

but the machine that replies is the firewall protecting that IP, usually
the perimiter firewall.
It may, or may not, have a user called "root", and may, or may not,
allow the user root to login via SSH.

With the firewall scenario , the easiest way around this is to do PAT,
portforward TCP port 44422 on the firewall to port 22 at the destination
(internal) IP.
then the ssh client line you require is:

$ ssh user@y.y.y.y -p44422

the f/w NATP translates 44422 to 22 and NATting it to the VPS on it's
internal IP target.

In YOUR case, maybe the virtual host machine is running
linux/BSD/OpenSolaris also? and has SSHd listening on port 22?
$ ssh root@wro.ng.mac.hine = rootlogin disallowed and authentication
bombs out

One way to quickly check this, is to first check the debug output:-

{debugsnip} debug1: Remote protocol version 2.0, remote software
version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
{/debugsnip}

This tells you that the SSH server (that's actually responding to your
connect request; not necessarily the one you want to connect to)
is running _OpenSSH4.3_. To me, this smells a little old? OpenSSH 4.3
smells very old, in fact, even my old IPCOP boxes in remote locations
are up to v4.7. everything else here is 5.1
Check the VPS machine's SSHd version, if it's not 4.3, then you're
actually connecting to something else accidentally at that IP, usually
the virtualisation host (on it's port 22) or the perimiter firewall at
that site (on port 22)

While SSH does a very, very good job at handling multiple concurrent
connections tunneled to disparate ports and onwards to many consecutive
machines, you have to ensure that your are connecting to the correct
machine to let it do that in the first place.

You see, if the virtualisation host is running SSHd on port 22, it sees
the virtualised guest as a seperate machine, usually behind NAT, not
"behind" the.ho.st.ip:22. The virtual networking (+headache) of the
virtualisation host is what determines what conects to what, maybe
NATed or bridged.

Within one machine, sure, SSH will sort out many connections and
tunnels to many places (confounding CCNAs/MCSAs that are usually taught
one service=one port. The key word here is "within" It's a "unix-y
thing" you see. sockets/pipes and stuff haha) but that assumes your
connection to the SSH server is on the correct __machine__ in the first
place.

So, things to check: is there a firewall or unix/linux/IOS router
answering instead of your intended destination? No? Well, how about the
virtual host machine's SSHd, is that it? I've been there a thousand
times, nested several times deep in it :)

I hope that's all clear :)

The main problem is, after about 20 failed attepts and frustrated edits
of sshd.conf s you get in such a mess with your known_hosts being
populated with inaccurate entries that you mistakenly, said "yes" to.
(You really need to keep careful control of fingerprints or the pretty
pictures they use nowadays).
The debugging then tends to tell you all is OK, when in fact your
known_hosts are full of certs from perimiter firewalls and in-between
routers. You could compare the fingerprints, but in fact, I find it
easier to touch a file in my home and root's home on each destination
machine, AFTER having confirmed the hostname is correct. Touching a file
also helps subsequent SSHFS/SFTP sessions too, it's easy to get lost
with 20 or 30 open across 10+ virtual desktops.

### granny-sux-eggs-mode-is-ON. I have replied in full and at length to
#help other people browsing the archives in the future. Future traffic
#offlist unless relevant to all.
###



{caution: my home ISP mail queues (F2S/UK are in total disarray, may be
a day or two before they get straightened out, if ever}

de Gord

--
$whoami;pwd
gord
/home/gord
$./morecoffee.sh

Hello,

Did you configure PAM in the container ? Try using UsePAM no !

Regards

--
Felipe Martins
Security Analyst
E-mail: martins.felipe.security@gmail.com
Skype: martins.felipe

Yarin wrote:
> Hello all,
>
> I'm trying to get SSH to work with a non-root user in a VPS Container running CentOS 5.3. But with no luck.
> I can log in to root with no problem, but no matter which way I try, I can't log in to any normal users that I make. When I try to log in via SSH, it always fails, and behaves exactly as if though I was entering the wrong password. (I am entering the right one, though, I've make sure of that)
>
> Here I try to log into user "fmain": (with debugging view enabled)
>
>
> # ssh 109.107.120.17 -l fmain -v
> OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 109.107.120.17 [109.107.120.17] port 22.
> debug1: Connection established.
> debug1: identity file /home/yarin/.ssh/identity type -1
> debug1: identity file /home/yarin/.ssh/id_rsa type -1
> debug1: identity file /home/yarin/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.2
> 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 '109.107.120.17' is known and matches the RSA host key.
> debug1: Found key in /home/yarin/.ssh/known_hosts:1
> 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
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> No credentials cache found
> debug1: Unspecified GSS failure. Minor code may provide more information
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/yarin/.ssh/identity
> debug1: Trying private key: /home/yarin/.ssh/id_rsa
> debug1: Trying private key: /home/yarin/.ssh/id_dsa
> debug1: Next authentication method: password
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17's password:
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> Permission denied, please try again.
> fmain@109.107.120.17'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).
>
>
> The debugging comments are all the same when I successfully log in to root, except for everything beyond "root@109.107.120.17's password:" of course.
>
> I checked, and all relevent /devs (on the the remote machine) have 666 privs minimum, so that's not the problem.
>
> The remote machine's /etc/ssh/sshd_config file looks like this: (with comment lines stripped)
>
>
> Protocol 2
> SyslogFacility AUTHPRIV
> PasswordAuthentication yes
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> UsePAM yes
> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> AcceptEnv LC_IDENTIFICATION LC_ALL
> X11Forwarding no
> Subsystem sftp /usr/libexec/openssh/sftp-server
>
>
> I even tried adding "AllowUsers root fmain" to it, and restarting the SSH Daemon, but was no help.
>
> From my googling, there are plenty of people with the opposite problem (can log in, just not through root). And I tried everything that the few who seemed to have this same problem had done.
> I've exhausted my searching options and don't know where to go from here. Anyone have any ideas?
>
> Thanks for any help that you may be able to provide,
> Yarin
>

Can you try these?

su fmain
ssh <hostname>

**UserID for fmain of both servers should be same.

One more option: you could place 'yarin' public key in "fmain"'s
authorized_keys file



+Raja

Felipe Martins wrote:
> Hello,
>
> Did you configure PAM in the container ? Try using UsePAM no !
>
> Regards
>