[sf-lug] request for help re ssh -- sshd login failure
jim
jim at well.com
Sun Feb 7 11:09:36 PST 2016
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.
>
>
More information about the sf-lug
mailing list