[sf-lug] request for help re ssh -- sshd login failure
jim
jim at well.com
Sun Feb 7 16:11:46 PST 2016
Thanks,Asheesh. We looked at /var/log/auth.log
several times, including before I wide-opened the
permissions on /home and /home/lerner
Neither the error message seen on 109 nor the
messages written to /var/log/auth.log were different
On 02/07/2016 08:20 PM, Asheesh Laroia wrote:
> ls -lrt /var/log
>
> This lists all log files sorted by recency.
>
> You'll probably find /var/log/auth.log informative.
>
> Probably the 'chmod 777 /home/lerner' is causing sshd to refuse to let
> the user log in. You'll see that in /var/log/auth.log
>
> You can also try
>
> ssh lerner at localhost
>
> to make sure sshd complains independent of the source IP address
>
>
> In general, ls -lrt /var/log is your friend.
>
> On Sun, Feb 7, 2016 at 11:09 AM, jim <jim at well.com
> <mailto:jim at well.com>> wrote:
>
>
> Many, many thanks, Michael.
> My comments interspersed below.
>
>
> On 02/07/2016 05:23 PM, Michael Paoli wrote:
>
> Divide & conquer troubleshooting,
> E.g. (I won't do or outline a whole flow chart or the like,
> I'll leave that
> bit of logic flow as an exercise) ...
> JS: per wikipedia links at the bottom of your reply.
>
> If one does the test where the client is also on the same
> server host, does it
> work?
> JS: great idea. I suppose I should try to login both to local host
> as well as the IP address.
> And likewise if the server is 127.0.0.1 or other localhost
> address?
> JS: I'm reading this meaning to use ifconfig to verify that lo is
> 127.0.0.1
> Does password authentication on the server work, e.g. can user
> use su from
> their login ID to their same login ID?
> JS: BEAUTIFUL! Thanks
> Can other (non-root) accounts be ssh(1)ed into?
> JS: We've already changed the /etc/ssh/sshd_config file to
> disallow
> root login via sshd. I guess we can make another user account
> and try that. I'm pessimistic. We've changed permissions
> 109 # chmod 777 /home ; chmod 777 /home/lerner
> with no good affect.
> What about options to ssh, notably -v, and using that option up to
> thrice as options on the ssh(1) command line?
> JS: never thought about learning ssh command options. I'll read
> and try.
> What about logs on the server, what do they say/suggest about
> the attempts and failures?
> JS: 119 $ ls -lt /var/log | head
> shows that kernel.log, syslog, and auth.log are most immediately
> updated. Using the tail command on each presents the most
> recent ten log lines, none of which is useful to me.
> If other accounts also work there, what does the log show on
> those, and how do they differ?
> JS: The auth.log file shows sudo command changes with no
> errors or warnings. (Oh, the sshd_config file sets logging to
> INFO)
> Is one using or attempting to use password authentication, or
> is one
> attempting to authenticate using ssh keys?
> JS: We cleared out 109:~/.ssh/known_hosts and then tried to
> use ssh to log in to 119; 109 sshd presented the default
> message about untrusted host stuff and did we want to trust,
> to which we typed in yes (and presto, we got a new known_hosts
> file) and then we got a passwd: prompt at which we typed in the
> correct password and saw a permission denied return.
> If keys, do the public and private key properly correspond? (I'll
> leave how to check that as an exercise - hint - read the man page
> for ssh-keygen(1)).
> JS: thanks for the reminder. We'll have to learn about using keys
> rather than passwords.
> What about the permissions on the public and private key
> files, and the
> permissions of all ancestor directories up the physical path
> to those
> files (sshd in particular is quite persnickety about those - and
> rightfully so).
> JS: All I know of is the ~/.ssh/known_hosts file. I'm
> guessing that
> the man page for ssh-keygen will provide clues.
> If ssh-agent is being use, what key(s) does it show as
> available to the client?
> JS: this is brand new turf for me. I'll read and try.
> Changed default sshd settings? Uhm, did one verify any
> working access
> and authentication via sshd first, or has one just added more
> variables to
> the situation?
> JS: In addition to the two directives I reported, we changed the
> permitrootlogin directive from yes to no
> And if one boots server from "live" CD/DVD or the like, sets up
> account to log into on that server, does that then work?
> JS: an obvious test that we did not try. Thanks.
> And what do
> the logs from that look like and how do they compare/differ?
> etc., etc.
> JS: we'll look.
> What information has one found regarding troubleshooting ssh
> access
> by, oh, gee, using The Internet, and, uhm, like a search engine?
> JS: We spent close to four hours just trying to solve the
> login problem,
> and we're now starting to reach for info. My original request
> was my
> attempt to define the problem and report context.
> JS: My experiences looking up problems using a search engine
> suggest
> that I should use error message text and log file text in the
> query (along
> with "Linux" and "Ubuntu" and release information. The ten
> thousand
> found web pages are often opaque to me or offer clear
> solutions that
> do not work when I try them on my systems. I have not found a few
> sites that give me useful answers to my problem. I suppose
> that means
> my search queries are not sufficiently specific, but I'm still
> in the dark.
> What results have been found from such research and investigation?
> https://en.wikipedia.org/wiki/Troubleshooting#Half-splitting
> https://en.wikipedia.org/wiki/Divide_and_conquer_algorithms
> JS: will read and try.
>
> JS: more thanks.
>
>
> From: jim <jim at well.com <mailto:jim at well.com>>
> Subject: [sf-lug] request for help re ssh -- sshd login
> failure
> Date: Sat, 6 Feb 2016 20:27:35 +0000
>
>
> Problem : we cannot use ssh to log in on a newly installed
> Ubuntu host.
>
>
> * We have a linux machine on local network 192.168.1.119
> See specifics for this host ( 119 ) below.
>
> * We installed openssh-server.
>
> * Using an ssh client on a Ubuntu 12.04 host on the local
> network 192.168.1.109 we cannot log in to 119
>
> * After many attempts using the default ( yes ) settings, we
> changed the following directive values in
> /etc/ssh/sshd_config
> but with no difference in behavior or log messages.
>
> X11Forwarding no ## changed from yes to no 20160205
> UsePAM no ## changed from yes to no 20160206
>
>
> 109 $ ssh lerner at 192.168.1.119 <mailto:lerner at 192.168.1.119>
> rsa ~/.ssh/known_hosts negotiation successful
> passwd:
> Permission denied, please try again.
> ...
> 109 $
> ## see output of
> 119 $ tail -2 /var/log/auth.log
> ## at bottom of this file :
>
> ## server listening on 0.0.0.0 port 22
> ## server listening on :: port 22
> ## ?? does :: mean 192.168.1.119 ??
> ## ?? i.e. is sshd listing both on lo and eth0 ??
>
>
>
> -------stats for host on 192.168.1.119-------------
>
> ##------
> 119 $ uname -a
> Linux mailin 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri
> Jan 25 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux
>
>
> ##------
> 119 $ cat /etc/issue
> Ubuntu 12.04.2 LTS \n \l
>
>
> ##------
> 119 $ free
> total used free shared
> buffers cached
> Mem: 4013004 1503756 2509248 0
> 226992 821120
> -/+ buffers/cache: 455644 3557360
> Swap: 2928628 0 2928628
>
>
> ##------
> 119 $ df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 19G 4.6G 13G 26% /
> udev 2.0G 4.0K 2.0G 1% /dev
> tmpfs 784M 892K 783M 1% /run
> none 5.0M 0 5.0M 0% /run/lock
> none 2.0G 76K 2.0G 1% /run/shm
> /dev/sda6 37G 176M 35G 1% /var/mail
> /dev/sda5 9.2G 163M 8.6G 2% /home
> /dev/sdb1 3.8G 1.6G 2.2G 42% /media/KINGSTON
>
>
> ##------
> 119 $ sudo iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
>
> ##------
> 119 $ tail -2 /var/log/auth.log
> Feb 6 11:29:59 mailin sshd[8549]: Server listening on
> 0.0.0.0 port 22.
> Feb 6 11:29:59 mailin sshd[8549]: Server listening on ::
> port 22.
>
>
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com <mailto:sf-lug at linuxmafia.com>
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20160208/c963e2f4/attachment.html>
More information about the sf-lug
mailing list