McAfee and CygWin SSH
Nico Kadel-Garcia
or so ago, then changed my anti-virus to a current version of McAfee.
Suddenly, I can't get it working, and the error messages are less than
informative.Attempts to ssh to localhost, even with the firewall turned off,
are failing.
It's not clear to me that it's McAfee biting me, sinice lots of references
to such problems exist but they vary wildly in their reported problem and
fix. Has anyone been through this lately, and gotten it actually working?
Nico Kadel-Garcia
Well, I got a McAfee technicion in a chat window: he walked me through
shutting down all McAfee services, and I'm still seeing the problem. It's
frustrating: this was working last week.
Todd H.
Does netstat -an | grep LISTEN show anything listening on port 22 (or
whatever)?
Are you running McAfee AV only, or their whole security suite and
firewall?
--
Todd H.
http://www.toddh.net/
Nico Kadel-Garcia
Yeah, netstat says:
$ netstat -an | grep LISTEN
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
etc. I see something like this when connecting:
$ ssh -v -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/Nico/.ssh/identity type -1
debug1: identity file /home/Nico/.ssh/id_rsa type -1
debug1: identity file /home/Nico/.ssh/id_dsa type -1
ssh_exchange_identification: read: Software caused connection abort
I'm not seeing anything useful in /var/log/sshd.log, either.
Richard E. Silverman
Try it with sshd -d and see what it says -- perhaps something (McAfee?) is
directly or indirectly killing sshd.
--
Richard Silverman
r...@qoxp.net
Nico Kadel-Garcia
"Richard E. Silverman" <r...@qoxp.net> wrote in message
news:m2u04c0...@darwin.oankali.net...
Unfortunately for me, this is Windows XP Home. The result is that when I try
that, I get the following:
$ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
Could not load host key: /etc/ssh_host_key
Could not load host key: /etc/ssh_host_rsa_key
Could not load host key: /etc/ssh_host_dsa_key
Disabling protocol version 1. Could not load host key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
OK, Windows XP Home does not seem to suppor the normal "Administrator" user
for manipulating ownership unless you log into "safe" mode. There's a set-up
tool called "ssh-host-config", that sets the ownerships as follows:
-rwxr-x--- 1 Nico None 1354 Aug 17 06:50 /etc/ssh_config
-rw------- 1 SYSTEM None 668 Aug 17 06:47 /etc/ssh_host_dsa_key
-rw-r--r-- 1 SYSTEM None 600 Aug 17 06:47 /etc/ssh_host_dsa_key.pub
-rw------- 1 SYSTEM None 973 Aug 17 06:47 /etc/ssh_host_key
-rw-r--r-- 1 SYSTEM None 637 Aug 17 06:47 /etc/ssh_host_key.pub
-rw------- 1 SYSTEM None 1679 Aug 17 06:47 /etc/ssh_host_rsa_key
-rw-r--r-- 1 SYSTEM None 392 Aug 17 06:47 /etc/ssh_host_rsa_key.pub
-rw-r--r-- 1 Nico None 2845 Aug 17 06:50 /etc/sshd_config
Notice the key ownership. On a semi-random basis, running ssh-host-config
sets the ownership to be "Nico:None", and I can only recover the
"SYSTEM:None" ownership being set by killing off my Cygwin session and
restarting it from scratch. Irksome! But since Wiindows XP Home doesn't
allow normal access to the "Administrator" user to play with file ownership
in complex ways, except by rebooting into single user mode, I've tried just
resetting those to allow group-read permission for now.
I then get this:
$ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
/var/empty must be owned by root and not group or world-writable.
Well, let's look at /var/empty:
$ ls -al /var/empty/
total 0
drwxr-xr-x+ 2 SYSTEM root 0 Aug 16 18:56 .
drwxrwx---+ 13 Administrator Users 0 Aug 16 18:56 ..
Unfortunately I can't do much about that without rebooting to "safe mode".
And due to ownership, I can't edit /etc/sshd_config without playing with its
ownership, or re-running ssh-host-config to very carefully *not* use
PrivSep, which I've always hated anyway due to exactly this sort of
cross-platform support whackiness.
OK, so I re-run ssh-host-config and turn off PrivSep, and turned up LogLevel
to DEBUG3 while I'm at it. So now I can start sshd in debug mode: Now I'm in
better shape for debugging:
$ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
So I ssh in with "ssh -v -v":
$ ssh -v -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/Nico/.ssh/identity type -1
debug1: identity file /home/Nico/.ssh/id_rsa type -1
debug1: identity file /home/Nico/.ssh/id_dsa type -1
ssh_exchange_identification: read: Software caused connection abort
And I see this on the server side:
$ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: fd 4 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
Then it dies.
There is *nothing* in /var/log/sshd.log. Running strace on it gives a lot of
messages I don't understand, but would be happy to post.
For me, this is Not Good(tm). I've been recommending to people that they use
SSHD for Windows access and tunneling things like rsync, and finding this
kind of problem in just getting the daemon running discourages me from
recomminding CygWin/OpenSSH as a means to provide these secured services.
Darren Tucker
> And I see this on the server side:
>
> $ /usr/sbin/sshd -d
> debug1: sshd version OpenSSH_4.3p2
> debug1: private host key: #0 type 0 RSA1
> debug1: read PEM private key done: type RSA
> debug1: private host key: #1 type 1 RSA
> debug1: read PEM private key done: type DSA
> debug1: private host key: #2 type 2 DSA
> debug1: rexec_argv[0]='/usr/sbin/sshd'
> debug1: rexec_argv[1]='-d'
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
> Generating 768 bit RSA key.
> RSA key generation complete.
> debug1: fd 4 clearing O_NONBLOCK
> debug1: Server will not fork when running in debugging mode.
> debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
This is the point where sshd re-execs itself to handle the new connection.
I suspect that this is failing for because of some change that occurred
when you installed the software (PATH, maybe?)
You can prevent the re-exec by adding "-r" to sshd's command line.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Nico Kadel-Garcia
> On 2006-08-17, Nico Kadel-Garcia <nka...@comcast.net> wrote:
>> And I see this on the server side:
>>
>> $ /usr/sbin/sshd -d
>> debug1: sshd version OpenSSH_4.3p2
>> debug1: private host key: #0 type 0 RSA1
>> debug1: read PEM private key done: type RSA
>> debug1: private host key: #1 type 1 RSA
>> debug1: read PEM private key done: type DSA
>> debug1: private host key: #2 type 2 DSA
>> debug1: rexec_argv[0]='/usr/sbin/sshd'
>> debug1: rexec_argv[1]='-d'
>> debug1: Bind to port 22 on 0.0.0.0.
>> Server listening on 0.0.0.0 port 22.
>> Generating 768 bit RSA key.
>> RSA key generation complete.
>> debug1: fd 4 clearing O_NONBLOCK
>> debug1: Server will not fork when running in debugging mode.
>> debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
>
> This is the point where sshd re-execs itself to handle the new
> connection. I suspect that this is failing for because of some change
> that occurred when you installed the software (PATH, maybe?)
>
> You can prevent the re-exec by adding "-r" to sshd's command line.
OK, that worked. So it looks like's definitely happening at the re-exec,
darn it. I'm not familiar enough Windows internals to get into this, and my
raw SSH coding is pretty rusty. Any ideas other than "run it from inetd"?
In the meantime, I'm gonna rip out McAfee by the roots and see if that
helps.
Nico Kadel-Garcia
> Darren Tucker wrote:
>> This is the point where sshd re-execs itself to handle the new
>> connection. I suspect that this is failing for because of some change
>> that occurred when you installed the software (PATH, maybe?)
>>
>> You can prevent the re-exec by adding "-r" to sshd's command line.
>
> OK, that worked. So it looks like's definitely happening at the
> re-exec, darn it. I'm not familiar enough Windows internals to get
> into this, and my raw SSH coding is pretty rusty. Any ideas other
> than "run it from inetd"?
> In the meantime, I'm gonna rip out McAfee by the roots and see if that
> helps.
So ripping McAfee out by the roots helped and got it working. It's not a
good long term solution, since other people are going to run into this.
Comcast is providing a free subscription to "McAfee Security Center", which
is what I was working with last night. I can send them a note, and will, but
even turning off all the McAfee features without actually deleting them
didn't fix the problem last night.
Mike Lowery
news:5f2dnZFvn-nPMn7Z...@comcast.com...
If your version of McAfee includes the "Buffer Overflow Protection" feature,
modify your installation of McAfee and REMOVE IT (red "X".)
Chuck
Can't you just tell McAfee that the ssh executable is allowed to do
whatever it wants? (Assuming this is a MacAfee FW issue)
Nico Kadel-Garcia
"Chuck" <skilove...@bluebottle.com> wrote in message
news:%J0Fg.9260$9v1.4356@trnddc07...
No, it's definitely not the firewall, which I'd already permitted SSH and
SSHD through. It's the cotton-picking "personal privacy service", which
blocks web-ads and web-bugs and pop-ups and the like. As long as I don't
install that at all, I'm OK. Disabling it does *not* fix the problem.
Nico Kadel-Garcia
"Mike Lowery" <michael....@boeing.com> wrote in message
news:J45EB...@news.boeing.com...
I'm afraid I don't see that feature: I'm using the current "McAfee Security
Center" provided by Comcast, with the Firewall, VirusScan (which turn out to
be OK) and the Privacy Service (which is the booby trap that scraps up SSHD,
even if disabled).
Darren Tucker
>> This is the point where sshd re-execs itself to handle the new
>> connection. I suspect that this is failing for because of some change
>> that occurred when you installed the software (PATH, maybe?)
>>
>> You can prevent the re-exec by adding "-r" to sshd's command line.
>
> OK, that worked. So it looks like's definitely happening at the re-exec,
> darn it. I'm not familiar enough Windows internals to get into this, and my
> raw SSH coding is pretty rusty. Any ideas other than "run it from inetd"?
You can run sshd as a daemon with -r too.
Nico Kadel-Garcia
> On 2006-08-17, Nico Kadel-Garcia <nka...@comcast.net> wrote:
>> Darren Tucker wrote:
>>> This is the point where sshd re-execs itself to handle the new
>>> connection. I suspect that this is failing for because of some
>>> change that occurred when you installed the software (PATH, maybe?)
>>>
>>> You can prevent the re-exec by adding "-r" to sshd's command line.
>>
>> OK, that worked. So it looks like's definitely happening at the
>> re-exec, darn it. I'm not familiar enough Windows internals to get
>> into this, and my raw SSH coding is pretty rusty. Any ideas other
>> than "run it from inetd"?
>
> You can run sshd as a daemon with -r too.
It seemed to exit after a single connection. I'm wondering if I should try
running out of inetd.
(Dig, dig, dig.)
Ahh, that only happened if I used the "-d" option as well. It seems to be
operating now by using the flags "-D -r" instead of just -D, which is what
CygWin's ssh-host-config sets it up for.
Hmm. Is this a change that should be pushed through CygWin's setup tools?
And to the manpage for sshd?
Mike Lowery
Then the last thing I can recommend trying is a "rebase all" from within Cygwin.
That fixed a similar problem for me.
Alternately, you could use another AV product like AVG
(http://free.grisoft.com/doc/1) or ComodoAV (http://antivirus.comodo.com/).
Nico Kadel-Garcia
Tried that, didn't work. I'm now using the "sshd -D -r" workaround
successfully.
Darren Tucker
>> You can run sshd as a daemon with -r too.
>
> It seemed to exit after a single connection. I'm wondering if I should try
> running out of inetd.
>
> (Dig, dig, dig.)
>
> Ahh, that only happened if I used the "-d" option as well. It seems to be
> operating now by using the flags "-D -r" instead of just -D, which is what
> CygWin's ssh-host-config sets it up for.
>
> Hmm. Is this a change that should be pushed through CygWin's setup tools?
No. It doesn't work because there's something funky with your system but
normally it should work fine.
> And to the manpage for sshd?
Maybe.
Nico Kadel-Garcia
> On 2006-08-18, Nico Kadel-Garcia <nka...@comcast.net> wrote:
>> Darren Tucker wrote:
> [...]
>>> You can run sshd as a daemon with -r too.
>>
>> It seemed to exit after a single connection. I'm wondering if I
>> should try running out of inetd.
>>
>> (Dig, dig, dig.)
>>
>> Ahh, that only happened if I used the "-d" option as well. It seems
>> to be operating now by using the flags "-D -r" instead of just -D,
>> which is what CygWin's ssh-host-config sets it up for.
>>
>> Hmm. Is this a change that should be pushed through CygWin's setup
>> tools?
>
> No. It doesn't work because there's something funky with your system
> but normally it should work fine.
It's a fairly common funkiness: there are a stack of reports of McAfee SSHD
failures on the web and in the McAfee and CygWin forums or mailing lists,
with various workarounds of disabling the "Buffer Overflow Protection" of
McAfee version 8.0 or 8.1. That configuration switch isn't available in
their current "McAfee Security Center" software, or I'd have tried it. But
it does give a software hint about what is going on.
>> And to the manpage for sshd?
>
> Maybe.
Please, yes. The "-r" option isn't even mentioned in the 4.3p1 or 4.3p2 man
pages that I'm reading right now. Having secret command line options is one
of the banes of my software existence.