ssh installation broken upgrading to 13.1

RBEmerson · January 29, 2014, 6:27am

A fully functional ssh installation that works reliably under 12.1 has stopped working after upgrading to 13.1. (The good news is I still have the HDD with 12.1 on it)

Using netstat, sshd is listening on 22 and 23 and sshd shows up in ps auxwww | grep sshd. The config file is the same one from 12.1. In short, there should be some degree of function. When I try to establish a connection either by local, same-net IP address or via a dynamic URL (verified with ping), the result is “connection timed out”. There’s no hint of attempting to authenticate the connection. Something changed but I don’t know what.

Right now, what I’d like (barring the answer to the whole mess) is a pointer to how to diagnose where the problem occurs. The material I turn up with Google is about authentication; I’m not even to the point of seeing a “nobody I know - bye!” message.

nrickert · January 29, 2014, 6:35am

Timeout suggests a firewall rule. Can you connect to 127.0.0.1?

RBEmerson · January 29, 2014, 7:32am

At the moment, the firewall is down, but I now doubt that’s the problem. Trying ssh localhost or the dynamic URL from the server, I’m getting ssh_config errors.
Bad configuration option: UsePAM
" " X11Forwarding
" " Subsystem
" " AcceptEnv
" " AcceptEnv
" " AcceptEnv

My immediate reaction was to look for mis-matched quotes, etc. I don’t see any. Almost everything is commented out except the Port 6666 command. If I comment that, the UsePAM line is still flagged, along with everything after it. I tried AuthenticationMethods PAM instead - no change. The error is marked as happening on line 92, 93, or 94 depending on what I’ve put in before UsePAM.

I’m using the same file that worked under 12.1. The current (from 13.1) version is OpenSSH_6.2p2, OpenSSL 1.0.12 11 Feb 2013

RBEmerson · January 29, 2014, 8:09am

I deleted all of the commented and blank lines. No change except for the line numbers. I moved the Port option below the line with the first error (is the line Port 6666 the offender?), the first line is still in error and now so is the port option line.
/etc/ssh/ssh_config: line 41: Bad configuration option: PermitRootLogin
(It’s set to
PermitRootLogin no)

After editing ssh_config, I kill sshd by job number, start it with sshd -D (to restart the daemon) and then try to connect to the port with ssh. That’s when the error messages show up.

I’m out of ideas.

nrickert · January 29, 2014, 5:13pm

Some of those options belong in “sshd_config” rather than “ssh_config”. Perhaps that’s what the error message is complaining about.

RBEmerson · January 29, 2014, 6:03pm

samwise /etc/ssh# ps auxwww|grep sshd
root      4947  0.0  0.0  46832  2764 ?        Ss   02:13   0:00 /usr/sbin/sshd -D
root      7348  0.0  0.0   9268   924 pts/3    S+   11:39   0:00 grep sshd
samwise /etc/ssh# ssh 192.168.1.152 ls -l
/etc/ssh/ssh_config: line 41: Bad configuration option: PermitRootLogin
/etc/ssh/ssh_config: line 93: Bad configuration option: UsePAM
/etc/ssh/ssh_config: line 99: Bad configuration option: X11Forwarding
/etc/ssh/ssh_config: line 121: Bad configuration option: Subsystem
/etc/ssh/ssh_config: line 124: Bad configuration option: AcceptEnv
/etc/ssh/ssh_config: line 125: Bad configuration option: AcceptEnv
/etc/ssh/ssh_config: line 126: Bad configuration option: AcceptEnv
/etc/ssh/ssh_config: terminating, 7 bad configuration options

ssh_config and sshd_config are identical. This situation worked under openSuSE 12.1. Have the rules changed under 13.1?

BTW, to check changes to ssh_config, I restart the daemon. To do that I have to find the daemon’s current job number with ps auxwww|grep sshd, kill nnn, /usr/sbin/sshd -D. Is there a simpler way to do this? Do I need to do this? FWIW I don’t see sshd with YaST’s xinetd tool.

nrickert · January 29, 2014, 7:36pm

No, they should not be identical.

I’m surprised that worked in 12.1.

“sshd_config” is for the server (inbound connections).

“ssh_config” sets defaults for the client (outbound connections), though users can override most of these on the command line or via “$HOME/.ssh/config”.

robin_listas · January 29, 2014, 8:43pm

On 2014-01-29 18:06, RBEmerson wrote:

> ssh_config and sshd_config are identical. This situation worked under
> openSuSE 12.1. Have the rules changed under 13.1?

They can not be identical. I suggest you reinstall ssh (deleting or
rename the entire “/etc/ssh/” directory first).

> BTW, to check changes to ssh_config, I restart the daemon. To do that I
> have to find the daemon’s current job number with ps auxwww|grep sshd),
> kill nnn, /usr/sbin/sshd -D. Is there a simpler way to do this? Do I
> need to do this? FWIW I don’t see sshd with YaST’s xinetd tool.

Because it is a system service, not a xinet service. In 13.1, you use
this syntax:


systemctl status sshd.service

to see the status. To start it, you use “start”, and “stop” to stop it.
And “restart” to… well, you can guess what

In 12.1 you would use “rcsshd status”, which also works in any other
openSUSE release. There is no reason I know that you should use those
strange methods.

More.

I guess that you are attempting to connect via internet and your router.
Don’t. The first step is to connect via local network, from another
computer.

Rather, in this case, the first step is:


ssh localhost

to find that the toolchain in the computer is correct.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

RBEmerson · January 29, 2014, 9:30pm

Progress!

I scraped /etc/ssh clean, reloaded ssh with Software Manager, tweaked the conf’s for the right port number (no earthly idea why the 12.1 installation worked), and was able to connect (full terminal function) with localhost.

192.168.1.152 failed do to strict checking (how do I suspend that?).

No joy with the URL for the dynamic IP. I can ping the router via the URL. Since the URL worked in the past, I’ll guess it’s OK (comments about xxx_conf not withstanding) through the router. I guess I’m missing a setting to accept outside contacts. Firewall is down.

whonea · January 29, 2014, 9:58pm

RBEmerson wrote:

>
> Progress!
>
> I scraped /etc/ssh clean, reloaded ssh with Software Manager, tweaked
> the conf’s for the right port number (no earthly idea why the 12.1
> installation worked), and was able to connect (full terminal function)
> with localhost.
>
> 192.168.1.152 failed do to strict checking (how do I suspend that?).
>
> No joy with the URL for the dynamic IP. I can ping the router via the
> URL. Since the URL worked in the past, I’ll guess it’s OK (comments
> about xxx_conf not withstanding) through the router. I guess I’m missing
> a setting to accept outside contacts. Firewall is down.
>

If you are behind a router, the router usually has to be configured to
forward specific ports otherwise things get a bit sticky. The default
firewall in my router specifically blocks the ssh protocol and port 22 by
default. That’s fine, since I want port 22 blocked and have sshd listening
on a high port. Each box in the house listens on a different port so that I
can reach each via a specific port with the router configured to forward
their individual ports to the right internal address.

–
Will Honea

RBEmerson · January 29, 2014, 11:40pm

Doh! It wasn’t the router. It was eth0’s setup. In converting from 12.1 to 13.1, I missed setting up the gateway. Everything’s working now.

NTL, how do I control strictness? I was flagged for coming into the ssh server via localhost, and then coming in via 192.168.1.152. I see why the complaint exists (to control man in the middle attacks), but I may have to tickle this particular dragon later.

RBEmerson · January 30, 2014, 12:15am

To clarify: 192.168.1.152 is the server’s local IP. I was on the server, using ssh 192.168.1.152 to access the server.

nrickert · January 30, 2014, 12:34am

I think that’s a complaint about a mismatch between the hostname found via an IP lookup, and the hostname use in the host-keys, or something of the kind.

It’s hard to avoid that in a typical home setup with NAT ip masquerading. On the public internet, it is a matter of making sure that DNS is properly setup so that everything has the right name, no matter how you look it up.

RBEmerson · January 30, 2014, 1:21am

Gotit. I’ll live with the nag screen. After all, the message has real value.

robin_listas · January 30, 2014, 2:53am

On 2014-01-30 01:26, RBEmerson wrote:
>
> Gotit. I’ll live with the nag screen. After all, the message has real
> value.

Also, on the client machine, on the ssh client configuration, there is a
file “~/.ssh/known_hosts”, that stores a hash of each server machine you
connect to.

If you previously connected to the 12.1 machine, which is now replaced
by the 13.1 machine, the signatures can be different, and the ssh client
detects this situation. By default it should refuse to connect.

The idea is that the client can also detect if the server machine changes.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

RBEmerson · January 30, 2014, 3:29am

The only machine that caused a problem is the machine at the other end of the ssh tunnel from the remote machines. The remote machines are tunneling away just fine. Other than for testing, it’s not very likely I’ll tunnel from the same machine I’m tunneling to. No worries.