Can't log in as anything but root via SSH

[Yarin]

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
***@109.107.120.17's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
***@109.107.120.17's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
***@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 "***@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

[Joseph Spenner]

Post by Yarin
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

[W***@tatravelcenters.com]

Date: 01/18/2010 01:53 PM
Subject: Can't log in as anything but root via SSH
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

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

publickey,gssapi-with-mic,password

Permission denied, please try again.

publickey,gssapi-with-mic,password

Permission denied, please try again.

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
password:" of course.
I checked, and all relevent /devs (on the the remote machine) have
666 privs minimum, so that's not the problem.
(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

[Quintin Beukes]

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

Post by Yarin
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
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).
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

[gordon b slater]

Post by Yarin
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..

Post by Yarin
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 ***@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 ***@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 ***@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 ***@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

[Felipe Martins]

Hello,

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

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

Post by Yarin
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
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).
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