Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...

2012-04-11 Thread Adam Mercer
On Mon, Apr 9, 2012 at 15:20, Bob Proulx b...@proulx.com wrote:

 Good.  Can you log in as the non-root user?

No, all users on this box are from NIS.

 Yes.  Stop all other lines of debugging and focus on this issue.  Why
 is there an error there?  Can you log in as that user?

  laltest@lal-squeeze:~$ su -l laltest

No, as this account is a special account without a password. We can
only log into this account using a shared ssh key.

 If not then why not?  Start debugging there.

 Also I have a cron job scheduled, via crontab, to run at 21:01
 everyday. It fails to run and the only reference to this I can find in
 the logs is the following:
 Apr  8 21:01:01 lal-squeeze CRON[14107]: Authentication failure
 So I imagine that this is a different manifestation of the same problem.

 Everything points to the same problem.  Debug it first.

 Any recommendations on how to debug this issue?

 Look in /var/log/syslog for messages.  Look in /var/log/auth.log for
 messages.

I can't see anything in the logs around the time that I try and
connect to the box.

Cheers

Adam


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+mfgz0xE-0D13gGa-Ff3mafmHJb_=rd6csbod3ohofuobz...@mail.gmail.com



Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...

2012-04-11 Thread Bob Proulx
Adam Mercer wrote:
 Bob Proulx wrote:
  Good.  Can you log in as the non-root user?
 
 No, all users on this box are from NIS.

How does having a user in NIS prevent you from logging in as that
user?  Presumably the purpose of NIS is to enable the user to log into
the account.  So I don't understand this comment.

  Yes.  Stop all other lines of debugging and focus on this issue.  Why
  is there an error there?  Can you log in as that user?
 
   laltest@lal-squeeze:~$ su -l laltest
 
 No, as this account is a special account without a password. We can
 only log into this account using a shared ssh key.

And at the moment you can't log in at all.  Right?

Did this work previously?  If so then you might try investigating what
changed between then and now.  Or is this something that hasn't ever
worked and you are trying to set it up for the first time?

  If not then why not?  Start debugging there.

I still think that is the right direction to push.  Since the account
is in NIS but isn't enabled personally I would create a temporary
local account for testing.  Don't forget to clean it up afterward.  I
would guess that there is some local configuration issue that is
preventing the account from being authorized.  Need to isolate the
problems into as simple of a case as possible and divide and conquer
to a solution.

Bob


signature.asc
Description: Digital signature


Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...

2012-04-11 Thread Adam Mercer
On Wed, Apr 11, 2012 at 16:13, Bob Proulx b...@proulx.com wrote:

 No, all users on this box are from NIS.

 How does having a user in NIS prevent you from logging in as that
 user?  Presumably the purpose of NIS is to enable the user to log into
 the account.  So I don't understand this comment.

It doesn't that was just extra information.

 And at the moment you can't log in at all.  Right?

As the individual user yes. We can log in as root.

 Did this work previously?  If so then you might try investigating what
 changed between then and now.  Or is this something that hasn't ever
 worked and you are trying to set it up for the first time?

This is a fresh VM.

 I still think that is the right direction to push.  Since the account
 is in NIS but isn't enabled personally I would create a temporary
 local account for testing.  Don't forget to clean it up afterward.  I
 would guess that there is some local configuration issue that is
 preventing the account from being authorized.  Need to isolate the
 problems into as simple of a case as possible and divide and conquer
 to a solution.

Sounds like a sane approach, I'll do that tomorrow.

Cheers

Adam


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+mfgz2e0m1xfw-3frek8tkpkama0f8aiyvsvcvwjsthh+r...@mail.gmail.com



Authentication issues trying to log onto a box as a standard user, and cron jobs...

2012-04-09 Thread Adam Mercer
Hi

I am trying to connect to a squeeze VM as a standard user using ssh
keys, whenever I try to ssh into the box the connection is closed by
the VM:

ram@g5:~$ ssh -v lal-squeeze
OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to lal-squeeze [192.168.100.11] port 22.
debug1: Connection established.
debug1: identity file /home/ram/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/ram/.ssh/id_rsa-cert type -1
debug1: identity file /home/ram/.ssh/id_dsa type -1
debug1: identity file /home/ram/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.5p1 Debian-6+squeeze1
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1
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(102410248192) 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 'lal-squeeze' is known and matches the RSA host key.
debug1: Found key in /home/ram/.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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ram/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type unknown
Enter passphrase for key '/home/ram/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
Connection closed by 192.168.100.11
ram@g5:~$

I can't find anything in the logs regarding this connect.

I can log onto the box as root.

Next when I su to a user account I receive the following:

root@lal-squeeze:~# su -l laltest
su: Authentication failure
(Ignored)
laltest@lal-squeeze:~$

so something is clearly wrong and I imagine this authentication issue
may be related to the inability to log on as a user.

Also I have a cron job scheduled, via crontab, to run at 21:01
everyday. It fails to run and the only reference to this I can find in
the logs is the following:

Apr  8 21:01:01 lal-squeeze CRON[14107]: Authentication failure

So I imagine that this is a different manifestation of the same problem.

Any recommendations on how to debug this issue?

Cheers

Adam


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+mfgz2mx5yghgtparncp2tkgfk3-ffns2-ap7oo9g2jt8m...@mail.gmail.com



Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...

2012-04-09 Thread Bob Proulx
Adam Mercer wrote:
 I am trying to connect to a squeeze VM as a standard user using ssh
 keys, whenever I try to ssh into the box the connection is closed by
 the VM:
 
 ram@g5:~$ ssh -v lal-squeeze

Unfortunately this information is rarely useful.  It is the *server*
side of the messages that are interesting not the client side.

 I can log onto the box as root.

Good.  Can you log in as the non-root user?

 Next when I su to a user account I receive the following:
 
 root@lal-squeeze:~# su -l laltest
 su: Authentication failure
 (Ignored)
 laltest@lal-squeeze:~$
 
 so something is clearly wrong and I imagine this authentication issue
 may be related to the inability to log on as a user.

Yes.  Stop all other lines of debugging and focus on this issue.  Why
is there an error there?  Can you log in as that user?

  laltest@lal-squeeze:~$ su -l laltest

If not then why not?  Start debugging there.

 Also I have a cron job scheduled, via crontab, to run at 21:01
 everyday. It fails to run and the only reference to this I can find in
 the logs is the following:
 Apr  8 21:01:01 lal-squeeze CRON[14107]: Authentication failure
 So I imagine that this is a different manifestation of the same problem.

Everything points to the same problem.  Debug it first.

 Any recommendations on how to debug this issue?

Look in /var/log/syslog for messages.  Look in /var/log/auth.log for
messages.

This reads almost like a permission problem.  One of the programs that
should be suid-root has had the suid-bit removed or something.  I am
not saying that it is.  The error messages in the logs should help.
If you can remember what has happened to the VM between when it was
working and now that it isn't may also be a good clue.

Bob


signature.asc
Description: Digital signature