[sf-lug] request for help re ssh -- sshd login failure
Asheesh Laroia
asheesh at asheesh.org
Sun Feb 7 12:20:40 PST 2016
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> 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>
>>> 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
>>> 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
> 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/20160207/45b32946/attachment.html>
More information about the sf-lug
mailing list