[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] RaQ2 openssh-3.4p1 monitor_fdpass.c:
- Subject: Re: [cobalt-users] RaQ2 openssh-3.4p1 monitor_fdpass.c:
- From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
- Date: Sat Jun 29 16:56:01 2002
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
GW> Date: Sat, 29 Jun 2002 17:35:29 -0400
GW> From: Gerald Waugh
GW> On Saturday 29 June 2002 05:15 pm, Glenn Parsons wrote:
GW> > So you're running ssh on port 55555 now? Are you really? How did that come
GW> > about? How did you figure that out?
GW>
GW> That was a test, port....
GW> Well, its a fact you can run it on almost any port
GW> "E.B. Dreger" suggested 55555 on one of the lists, sounded
GW> like it might be easy to remember.
Correct. I use some port (suggested 55555) to temporarily run
new sshd, so I don't chop my legs out from beneath me. Once I'm
convinced new sshd works properly on 22, I kill the one on 55555.
GW> But, I still have the old sshd running of port 22.
GW> I wish I could get the new one to install correctly...
GW> I know I could just copy the executables and the configs over
GW> the old ones but that is not really the way to do it.
Compiled correctly wrt paths, one only need alter config by:
1) adding sshd user or similar (unless pkg uses "nobody")
2) creating "/var/empty" or similar
3) updating config file to use privilege separation and perhaps
disabling compression.
It'll work fine with those small changes. I didn't bother
testing compression on 3.4.
There's some debate as to whether encrypting a compressed stream
poses a significant security risk... do a Google search for
bijective compression security
for a good intro to the issue. Standard compression algorithms
are NOT bijective.
Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.