SSH server & client help

[kwu...@comcast.net]

Hello everyone,

I'm having a problem with one of my fc15 machines. First it started with a file system error which I fixed with fsck . Once it came back up, the ssh server wouldn't at boot. Then I realized the client wasn't working either. I get the following errors:

------------------------------------------------------------------------------------------------------------------------------------------
# service sshd start
Starting sshd (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                           [FAILED]

# systemctl status sshd.service
sshd.service - LSB: Start up the OpenSSH server daemon
      Loaded: loaded (/etc/rc.d/init.d/sshd)
      Active: failed since Sun, 29 Jan 2012 21:53:56 -0600; 4min 23s ago
     Process: 3985 ExecStart=/etc/rc.d/init.d/sshd start (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/sshd.service

$ ssh kedo9
Auto configuration failed
3078813332:error:0E079065:configuration file routines:DEF_LOAD_BIO:missing equal sign:conf_def.c:362:line 1

# cat /var/log/messages-20120129 | grep ssh
Jan 28 09:56:15 kedo15 systemd[1]: Unit sshd.service entered failed state.
Jan 28 09:56:19 kedo15 systemd[1]: sshd.service: control process exited, code=exited status=1
(There are multiple entries like this)

------------------------------------------------------------------------------------------------------------------------------------------

I've done the usual googling, and haven't found much. I have also un- and re-installed. The sshd_config is now the default and still I have the same issues. I'm not sure what file it means is missing a "missing equal sign".

I will be grateful for any ideas you might have. I really don't want to format this box.



Thanks in advance,


Kevin

[Chris McQuistion]

Have you tried a "yum erase" on the various ssh packages and then deleted the config files (in case yum didn't remove them) and then reinstalled them?

Chris 

--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com
To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

[kwu...@comcast.net]

I've done yum remove. Is there a difference?

---

From: "Chris McQuistion" <cmcqu...@watkins.edu>
To: nlug...@googlegroups.com
Sent: Monday, January 30, 2012 9:51:42 AM
Subject: Re: [nlug] SSH server & client help

[Chris McQuistion]

I'm not sure.  Remove may do the same as erase or it might just remove it from the yum database, without actually uninstalling it.

Chris 

[Tilghman Lesher]

On Mon, Jan 30, 2012 at 11:49 AM, Chris McQuistion
<cmcqu...@watkins.edu> wrote:
> I'm not sure.  Remove may do the same as erase or it might just remove it
> from the yum database, without actually uninstalling it.

A quick google reveals that they are synonymous commands:

http://linux.die.net/man/8/yum

It also revealed what yum stands for: Yellowdog Updater Modified.

-Tilghman

[Drew from Zhrodague]

Also make sure to make sure SSH starts at boot time:

chkconfig --level 2345 sshd on

yum remove will do the same thing as rpm --erase. I prefer rpm --erase,
as you can force it to not remove deps.

--

Drew from Zhrodague
Internet Swashbuckler
dr...@zhrodague.net

[kwu...@comcast.net]

Thanks all. I will try all of those options. I'm also going to check what runlevel it's set to. I'll inform on results.

---

From: "David R. Wilson" <da...@wwns.com>
To: kwu...@comcast.net
Sent: Monday, January 30, 2012 12:55:15 PM

Subject: Re: [nlug] SSH server & client help

Yes, I suspect it would.  Without the keys being valid it would not be
able to initiate either end of the connection.

The remove and reinstall plan is probably a good one, however be sure to
look around for the .ssh file and the keys in the /etc/ directory and
make sure they are deleted before reinstalling the package.  I suspect
any part of SSH not being in place will keep it from working.

My thoughts, probably not work .02 :-)

Dave



On Mon, 2012-01-30 at 17:48 +0000, kwu...@comcast.net wrote:
> No, I haven't regenerated the keys. Would that stop the whole service
> from starting and the client from working?
>
>
> ______________________________________________________________________
> From: "David R. Wilson" <da...@wwns.com>
> To: kwu...@comcast.net
> Sent: Monday, January 30, 2012 9:57:41 AM

> Subject: Re: [nlug] SSH server & client help
>

> Hello Kevin,
>
> It looks like keys were corrupted.  Have you tried regenerating
> the keys yet?
>
> Dave

> > +unsub...@googlegroups.com

[Steven S. Critchfield]

a quick google search of conf_def.c makes me think this is openSSL related. Noting there is a bug in openSSL being patched within the last few days, maybe you need to target that as well.

> -- You received this message because you are subscribed to the Google
> Groups "NLUG" group.
> To post to this group, send email to nlug...@googlegroups.com
> To unsubscribe from this group, send email to

> nlug-talk+...@googlegroups.com For more options, visit this
> group at http://groups.google.com/group/nlug-talk?hl=en

--
Steven Critchfield cri...@basesys.com

[Drew from Zhrodague]

On 1/30/12 2:49 PM, Steven S. Critchfield wrote:
> a quick google search of conf_def.c makes me think this is openSSL
> related. Noting there is a bug in openSSL being patched within the
> last few days, maybe you need to target that as well.

Another fun thing to try, would be to validate the files in the binary
packages, then reinstall the busted ones:

rpm -Va > /tmp/rpmverified.txt

This will spit out a list of files changed since installation.
Sometimes you can detect rootkits this way. You can ignore the config
files that show up. If there are binaries that have changed after a disk
crash, you should probably reinstall those packages. yum has a reinstall
function, I believe.

[Curt Lundgren]

Thanks for that, Drew.  There's always more to learn on any subject, and I just learned something quite valuable.  I'm nominating this thread for Top Ten in 2012.

Curt

--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com

To unsubscribe from this group, send email to nlug-talk+unsubscribe@googlegroups.com

[kwu...@comcast.net]

Steven,

You might have something there.

I ran a Google search of sshd conf_def.c and came across this:

-------------------------------------------------------------------------------------------------------------------------------------------
http://southbrain.com/south/2011/04/centosredhat-56-sshd-problem-8.html

-------------------------------------------------------------------------------------------------------------------------------------------

Looks very similar.

---

From: "Steven S. Critchfield" <cri...@basesys.com>
To: nlug...@googlegroups.com
Sent: Monday, January 30, 2012 2:49:06 PM

Subject: Re: [nlug] SSH server & client help

[kwu...@comcast.net]

Thanks to everyone who responded to my request. I fixed it. For those of you that might be curious as to the final solution, it was the openssl.cfg file. It was definitely corrupted. So David was looking in the right direction and Steven was very close.

I tried the erase and reinstall of openssh which had no effect. I tried the same with openssl and received a large amount of dependencies to be removed (including yum) which I didn't want to do. I started to compare openssl config files with a known good system. It was completely different. I found a close to valid copy of it and replaced it. After that, it was a matter of getting the values correct. Each time I ran openssl, it gave me a different line error for me to correct until it started working. Openssh-client & server also started working there after.



Thanks again for all of your replies,


Kevin

---

From: kwu...@comcast.net
To: nlug...@googlegroups.com
Sent: Monday, January 30, 2012 4:50:29 PM

[Jose Luis Mantilla]

Hello everyone!

 

Problem:
auto configuration failed configuration file routines:def_load_bio:missing equal sign:conf_def.c

Solutions:
#rpm -qV openssl (verify packages) and later... remove the last file (this file was modified) /etc/pki/tls/openssl.conf and finally #rpm -U --force openssl-1.0.....rpm !!

Try and solve

[Prasoon Sharma]

Try looking into /etc/pki/tls/openssl.cnf file. Might be you made some changes or you mistyped something into it. I faced similar issues today and found I mistakenly typed something into that file. I removed it and restarted sshd, my ftps and ssh again starting working fine.

[Paul Boniol]

As everyone I'm sure is aware, #1 (if not 1, close to it) thing is to secure any SSH server as best you can before it goes on the Internet, because most distributions default config leaves them in the equivalent of something like a locked storm door approach.  (Wiggle the knob enough and it might just pop open.)

1.  If possible disallow password authentication, use a secure shared key.  Preferably transferring just the public key from the SSH box to your desktop(s), preferably by thumbdrive or similar.

2.  I always disallow direct SSH root login.  (I'm pretty sure this also means "they" have to guess a username, provided something doesn't do an end-run, e.g. buffer overflow, to allow access.)

3.  A bit of belt-and-suspenders approach, but if you already have a VPN to allow access to your network, you can run SSH over the VPN.  This can drastically cut the number of IP addresses you must allow to connect to SSH.  Connections from a different IP range can simply be dropped.

4.  Apply security updates regularly.

From a quick glance #1 would eliminate this particular botnet attack from adding your machine to their network(s).

I go further, but I known I'm paranoid. :)  I have enough to do without a security admin breathing down my neck and/or having to rebuild boxes cause I didn't do what I should.  I do all that is possible to stop a breach before it happens, even if that means a bit of inconvenience on my part.  (Others on the listserv I'm sure are infinitely more qualified than I am in this arena.  Just some quick thoughts to prevent it before it happens.)

Paul

--

--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com
To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

---

You received this message because you are subscribed to the Google Groups "NLUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Smith (K4RNT)]

Use something like NoMachine so you can disable password authentication?

" 'With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and warning... The first time any man's freedom is trodden on, we’re all damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG episode "The Drumhead"
- Alex Smith

- Kent, Washington (metropolitan Seattle area)

[Paul Boniol]

Not sure what NoMachine is, but I'd suspect far easier to change your sshd config file to change SSH server behavior.  

Some recommendations for the config file:

AllowUsers user1 user2 user3    (assuming your list of authorized users is short, there's also a group option, but I've had a very small SSH user base)

PermitRootLogin no

PasswordAuthentication no

ChallengeResponseAuthenticaiton no  (if you can use key authentication for all users, ~/.ssh/authorized_keys)

Of course what you can and can't do to secure SSH it is dependent upon your environment / work policies / users.

Paul

[JMJ]

I'm not suggesting that it really matters, but am I the only one who
noticed that the original
question was asked ALMOST FOUR years ago? LOL

>>>> On Monday, January 30, 2012 at 10:50:08 AM UTC+5:30, Kevin Wurm#1 wrote:

>>>>> I'm having a problem with one of my fc15 machines.

I suspect that current solutions might not apply to FC15, but that's
just a guess. :-)

And now we return you to your regularly scheduled programming, already
in progress.

JMJ

[Paul Boniol]

Oops.  I replied to the wrong thread.  :)  I had meant my email to be in response to Jack Coats Linux Botnet thread, (Tue, 29 Sep 2015 23:08:36 -0500).  I guess I saw another recent email re SSH and thought it was the same thread.

Paul