ssh, unable to connect to a machine, with any account, other than root

WetFroggy · 01-28-2012, 02:42 AM

The machine in question, has a clean install of slackware 13.37, as far as it goes, its "stock" - brand new home directory, the machine had its partitions wiped out, so no weird artifacts or pointers pointing to files that don't exist.
I was going to push applications onto it, when I found out, I was unable to use any account, aside from root, to ssh in. With further testing - trying to ssh into itself, using its IP (not localhost - and just now, tested with localhost, same response) - Permission denied, please try again.
The password for the user account has been reset, same response.
/etc/ssh/sshd_config has not been touched (its very much like a copy on my main machine - and it works fine).
At one point I tried to use the method where one has a public key, copied to one machine, and doesn't need to supply the password, as it has a related file on the other machine (sorry, can't recall what this method is called) and while it worked fine, the minute I used an application such as konquorer, dolphin or ftp, the application presented me with a password dialog, and again, permission denied.

So I am baffled now. Where's a good place to start looking? When I compare files from main machine (A) to this one (B), there's no differences, when related to ssh, sshd and I've deleted .ssh in the user's home folder, to no resolution.

Just to be clear, aside from turning on the ssh file in setup, this is a stock install, right from the slackware dvd. Any config file I touched, I made sure to backup & restore when something didn't pan out.

Has something changed in ssh since 13.1? Have I actually missed something glaringly obvious?

Any help would be much appreciated.
-----
EDIT # 1 :
Forgot to mention, if the Xserver is never used (so, log on, stay at command prompt) the same problem happens.

EDIT # 2 :
I was being purposely vague, and I see now, that won't help anyone, nor myself
Machine A - Main, working fine. Running 13.37
Machine B - Laptop, clean install (repartitioned, etc, literally clean). Running 13.37.

EDIT #3 :
Seems this might be actually crucial, Laptop can use either a wireless IP or a wired IP. I hadn't mentioned this, as when I used ubuntu on laptop, things seemed to work just fine, when changing IPs without restarting the machine. I Now wonder if ubuntu "does something" to ensure ssh would work correctly afterwards?

Richard Cranium · 01-28-2012, 02:52 AM

On what type of machine are you running the ssh command in order to log into the Slackware 13.37 machine?

Can you log in directly as a non-root user on the Slackware 13.37 machine?

Cedrik · 01-28-2012, 04:59 AM

For X applications, you need to add the machine A's IP to xhost to access machine B applications

In machine B, say A's IP is: 10.0.0.12:

Code:

xhost +10.0.0.12

Also, what are the permissions of the user Xauthority file ?

Code:

ls -l ~/.Xauthority

tronayne · 01-28-2012, 08:39 AM

Some stuff that might help (or, you know, might not, but here goes anyway).

Are you using fixed-IP on these machines? If so, do you have entries in /etc/host of the form

Code:

# For loopbacking.
127.0.0.1               localhost
192.168.1.10            fubar.com fubar        < this is "this" server >
192.168.1.15            InkJet                 < this is a network printer >
192.168.1.20            snafu.com snafu        < this is another server >
192.168.1.30            pita.com pita          < this is yet another server >

Those go in every server's /etc/hosts file (and then you can connect with, say)

Code:

ssh pita

Have you generated keys in the account(s) on the new machine (not copied from any other platform)?

Code:

log in
password
ssh-keygen
<hit the enter key when prompted for a passphrase>

Those will get written into ~/.ssh as id_rsa and id_rsa.pub (RSA is the default encryption, you could choose another method, see the manual page).

For password-less connections you copy the id_rsa.pub to the other machine(s) you wish to allow to connect to this machine without a password, account by account, and copy the id_rsa.pub files to this machine from the other machine(s) so this machine can go that way without a password. I find it easier to, on a local machine, to copy ~/.ssh/id_rsa.pub to a file named the machine name; e.g., on server fubar

Code:

cd .ssh
cp id_rsa.pub fubar

If you're doing this for a bunch of servers, it's easier to copy that file to the ~/.ssh directory then append it to authorized_keys file (and you won't overwrite the id_rsa.pub file on the machine). See below.

You can create a config file in ~/.ssh of the form (this is the conf file that resides on server fubar for connecting to pita and snafu):

Code:

Host pita
ForwardAgent yes
ForwardX11 yes
Compression yes
Protocol 2,1
User trona

Host pita
ForwardX11 yes
Compression yes
Protocol 2,1
User root

Host snafu
ForwardAgent yes
ForwardX11 yes
Compression yes
Protocol 2,1
User trona

Host snafu
ForwardX11 yes
Compression yes
Protocol 2,1
User root

Host *
ForwardX11 no

Note that the above allows user trona to connect with ssh pita or allows user trona to connect to pita as root with ssh -l root pita. The id_rsa.pub files for all user account names on all servers are entered in ~/.ssh/authorized_keys.

When you first connect to a server (and give the appropriate password for that server) its information will be entered in ~/.ssh/known_hosts. As above, you do not copy this from server to server, it's generated when you successfully connect the first time. You do copy the public key file, ~/.ssh/id_rsa.pub or ~/.ssh/fubar if you made a copy, to the other servers' ~/.ssh/authorized_keys files but you never copy the private key, ~/.ssh/id_rsa, anywhere.

Doing the above, you don't need to fiddle with /etc/ssh/ssh_config; in fact, a standard Slackware installation sets up the system keys for you and you don't need to fiddle with them (and you really do not want to copy any of those to any other box, do it on a user-by-user basis).

Hope this helps some.

Richard Cranium · 01-29-2012, 02:25 AM

Quote:

Originally Posted by tronayne

For password-less connections you copy the id_rsa.pub to the other machine(s) you wish to allow to connect to this machine without a password, account by account, and copy the id_rsa.pub files to this machine from the other machine(s) so this machine can go that way without a password. I find it easier to, on a local machine, to copy ~/.ssh/id_rsa.pub to a file named the machine name; e.g., on server fubar

Code:

cd .ssh
cp id_rsa.pub fubar

If you're doing this for a bunch of servers, it's easier to copy that file to the ~/.ssh directory then append it to authorized_keys file (and you won't overwrite the id_rsa.pub file on the machine). See below.

Actually, the ssh-copy-id command is the easiest way to do it. My hat is off to the person who pointed this out to me in one of the other forum threads! (I don't remember who, unfortunately.)

tronayne · 01-29-2012, 07:56 AM

Quote:

Originally Posted by Richard Cranium

Actually, the ssh-copy-id command is the easiest way to do it. My hat is off to the person who pointed this out to me in one of the other forum threads! (I don't remember who, unfortunately.)

Well, hot dang, never did come across that one -- probably ought to read all the man pages, eh? Makes life easier.

Thanks for that.

WetFroggy · 01-29-2012, 02:33 PM

@Richard Cranium

Quote:

On what type of machine are you running the ssh command in order to log into the Slackware 13.37 machine?

Can you log in directly as a non-root user on the Slackware 13.37 machine?

Machine B (henceforth, laptop) seems unable to ssh into itself. This is my typical test, means everything else on the network can be turned off - if it doesn't work for itself, something is amiss. If "directly" means can I log in locally by the log-in command (not ssh) yes, if it means "can you ssh into laptop from the laptop", then no.

@Cedrik

Quote:

For X applications, you need to add the machine A's IP to xhost to access machine B applications

Sorry, forgot to mention a critical part, Xserver doesn't need to be even running for the same problem to occur. (ls -l ~/.Xauthority results in -rw-------). [I'll correct my original post].

@tronayne

Quote:

Are you using fixed-IP on these machines? If so, do you have entries in /etc/host of the form

Yes and no, Fixed IPs are handled by the dhcp server, but as a test, I did add the fixed IPs to laptop's hosts file, and lo, I could finally ssh into the main machine with laptop's user account, yet I can't go from main back to laptop, nor can laptop ssh into itself (unless of course, I use root)*. The IPs were always in the main's hosts file, and again, no change.

Quote:

Have you generated keys in the account(s) on the new machine (not copied from any other platform)?

Tried this, no change.

Quote:

For password-less connections you copy the id_rsa.pub to the other machine(s) you wish to allow to connect to this machine without a password, account by account, and copy the id_rsa.pub files to this machine from the other machine(s) so this machine can go that way without a password.

Tried this (before adjusting the hosts file - I will assume it might work - but as this is laptop, getting the password-forced connections part working, is currently more critical), and this does work, but only if I use a command prompt, x-based applications, such as konquoror, gftp, etc, result in the initial trouble.

For everything I've tried, I attempt first with wired IP, then wireless IP (just occurred to me I didn't mention this, sorry, will adjust OP) after adding the main's ip/name to laptops hosts file, user could finally get in. Main on the otherhand, even with the ip/name already present can't ssh in, unless I use ... is not working? :/

*I think I'm adding an unintentional complexity. It was working earlier (after I adjusted hosts file), seems to be when laptop changes from a wired to a wireless IP something breaks both coming and going? Hmm.

Richard Cranium · 01-29-2012, 04:42 PM

Ah. Can you ping machine B from machine A when machine B is using wireless? How about vice versa?

Rather useless questions, as Ramurd points out in a very nice way.

Ramurd · 01-29-2012, 05:01 PM

You can connect with root remotely, so it's not likely a TCP/IP problem;
Since you mention repartition, I have to ask: you actually can login locally? :-)

What's your Hostkey?
HostKey /etc/ssh/ssh_host_rsa_key

Just to make sure there's not something weird in your sshd config; can you just take a look there for some settings that may actually not be that logical?

By default sshd should losten on all devices; should not matter if they become available afterwards or not, but you can take a check: after the system is up and running to perform a /etc/rc.d/rc.sshd restart ; might be the bindings go awray, which they should not.

just a few pennies I thought I'd toss about.

Might be there's something showing up in your log files: /var/log/messages ; /var/log/syslog or maybe even /var/log/secure
it might point you to something that's going on.

Good luck!

Richard Cranium · 01-29-2012, 07:53 PM

Quote:

Originally Posted by Ramurd

You can connect with root remotely, so it's not likely a TCP/IP problem;

Very good point. Kinda nukes my questions.

WetFroggy · 02-01-2012, 01:59 PM

Oh my, I feel very silly now. Its so very clear.

@Ramurd

Quote:

Might be there's something showing up in your log files: /var/log/messages ; /var/log/syslog or maybe even /var/log/secure
it might point you to something that's going on.

/var/log/messages :
... User ... from [laptop1] not allowed because not listed in AllowedUsers
.. Failed password for invalid user...

Seems I didn't revert back to the stock config file.

While I was stabbing away blindly, I in "/etc/hosts" adjusted what the machine name for the wireless IP was `Laptop1`, because I thought that that was what was breaking things - yet, AllowedUsers was indeed set, thereby breaking every single supposed new test after that. Reverting to the stock config, and readjusting the hosts file to what it should have been, the tests all worked.

Now, when I'm calm enough so I don't do dumb things again, I'll get to securing laptop.

Thank you all, for your patience & help.

Although, the blind stab into hosts, helped me see what I had forgotten to do .. so perhaps that helped .. sort of?

Ramurd · 02-02-2012, 01:55 AM

Well, good that it is fixed then! Good luck securing the 'puter.