A reasonable use for telnet is when the ssh deamon goes down, or isn't
started on bootup because of some configuration error...
Yes, I know it isn't secure, but sometimes it can be the last resort...
/kbn
Dave Ewart wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday, 09.09.2004 at 0
I disagree, when running telnetd, people will use it and hence create a
security flaw. Moreover, you would use it yourself with the very
intention of becoming root and starting a secure daemon, which in my
opinion can do lot more harm than good.
Even on a (virtual) private network I would try t
Hello,
Kim B. Nielsen wrote:
A reasonable use for telnet is when the ssh deamon goes down, or isn't
started on bootup because of some configuration error...
if one can't configure sshd properly to start at bootup, there are - at
least sometimes - other possibilities than using telnet (console via
On Thu, 2004-09-09 at 09:23 +0100, Dave Ewart wrote:
> > getting rid of telnetd is almost always a very good idea.
>
> Quite so, as I suggested.
>
> Are there even any legitimate uses for running a telnet daemon any more?
> (That is a genuine question - as far as I can see, SSH is always a
> per
On Thu, 2004-09-09 at 14:28, ktabic wrote:
> How about, as a service to enable as you are updating SSH remotely from
> the other side of the country to fix the most recent problem security
> problem and need a backup system to get into the server in the event
> that something goes wrong?
>
> ktab
EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Re: Re: open telnet port
I disagree, when running telnetd, people will use it and hence create a
security flaw. Moreover, you would use it yourself with the very
intention of becoming root and starting a secure daemon, which in my
opinion can do lot
> How about, as a service to enable as you are updating SSH remotely from
> the other side of the country to fix the most recent problem security
> problem and need a backup system to get into the server in the event
> that something goes wrong?
Maybe it would work as well, to start a ssh daemon on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
How about setting up another sshd on higher port, statically linked and
with different config as a backup?
For extra better sleep use before every ssh backup. If you can't start
properly during bootup, a walk for physical access would do you good. ;)
Ho
Greetings!
> > > getting rid of telnetd is almost always a very good idea.
> >
> > Are there even any legitimate uses for running a telnet daemon any
> >
> [...] need a backup system to get into the server in
> the event that something goes wrong?
Install an out-band management access, e.g. v
So you'd leave telnet on just incase ssh broke?
Can we say "unnecessary service"?
Leaving an extra avenue of attack because you might break your SSH is a
bad bad bad bad idea. Next you'll be telling us you have a backup user
called "test" with password "test" and uid 0, just incase you forget
your
You really should not need this as the norm. I do this when I'm
working on the ssh daemons, but thats about the only time. What I do
is I enable it on a screwball port number, then use tcp wrappers to
only allow access from my ip address and change the root password
before I begin. In that way t
Generally, I run a seperate sshd on a different port while I'm
upgrading, then disable it. There is never a reason to run telnetd.
On Thu, 09 Sep 2004 13:28:51 +, ktabic <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-09-09 at 09:23 +0100, Dave Ewart wrote:
>
> > > getting rid of telnetd is almo
On 9 Sep 2004, at 06:28, ktabic wrote:
Are there even any legitimate uses for running a telnet daemon any
more?
(That is a genuine question - as far as I can see, SSH is always a
perfect replacement).
How about, as a service to enable as you are updating SSH remotely from
the other side of the cou
On Thu, 2004-09-09 at 09:41 -0400, Andrew Haninger wrote:
> > How about, as a service to enable as you are updating SSH remotely from
> > the other side of the country to fix the most recent problem security
> > problem and need a backup system to get into the server in the event
> > that something
Yep, call-back modem is a very good idea. But we are sliding OT. =)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Volker
Tanger
Sent: Thursday, September 09, 2004 9:18 AM
To: ktabic
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Re: Re: open
> If you need this on as the norm, please at least use TCP wrappers to
> limit from where it can be accessed, and change any used passwords
> immediately after reestablishing control.
I think the real insecurity in telnet comes not from buffer-overflows
and whatnot, but rather from people sniffin
> So the solution to not run a backup telnet server for updating SSH is to
> run a second, known insecure version of sshd on a different port,
> presuming of course, that you are allowed to run said sshd on said high
> port in the first place.
Sorry, that was stupid of me. First build the new sshd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yo Andrew!
On Thu, 9 Sep 2004, Andrew Haninger wrote:
> Maybe it would work as well, to start a ssh daemon on a high port,
> login on that high port, update the current sshd, start it up on port
> 22, logout of the high port, login on port 22, and ki
Dave Ewart wrote:
Quite so, as I suggested.
Are there even any legitimate uses for running a telnet daemon any more?
(That is a genuine question - as far as I can see, SSH is always a
perfect replacement).
Sure - a situation where a system needs a low-bandwidth/low CPU-use
shell-based communic
Oh.. It seemed my little post stirred something up :)
Well, if you use a service, it's not unnecesary. The service only
becomes unnecesary, if you have it on, and don't use it :)
And no, I don't have a backup user called test. I'm not Joe Clueless :)
I merely suggested, that keeping another way
On Thu, 09 Sep 2004 16:37:28 -, ktabic said:
> So the solution to not run a backup telnet server for updating SSH is to
> run a second, known insecure version of sshd on a different port,
> presuming of course, that you are allowed to run said sshd on said high
> port in the first place.
It's
Restarting the SSH daemon won't kill processes, but overlaying the
openssl libraries with a new version will, or has, in my case. Saved
me from having to fly to the other coast.
On Thu, 9 Sep 2004 08:48:21 -0700, Andrew Farmer <[EMAIL PROTECTED]> wrote:
> On 9 Sep 2004, at 06:28, ktabic wrote:
>
> Yo Andrew!
... Right.
> Then you update OpenSSL and it crashes all the ssh processes at the same
> time. Been, there, done that.
Thanks a lot.
After your suggestion that it couldn't be done, I tried it. While it
took thinking, I could have done it had I not killall'ed my sshd's
without changin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Barry" == Barry Fitzgerald <[EMAIL PROTECTED]> writes:
Barry> Dave Ewart wrote:
>> Quite so, as I suggested.
>> Are there even any legitimate uses for running a telnet daemon
>> any more? (That is a genuine question - as far a
D]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew
Haninger
Sent: 09 September 2004 21:46
To: Gary E. Miller
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Re: Re: open telnet port
> Yo Andrew!
... Right.
> Then you update OpenSSL and it crashes all the ssh processes at the
> same time.
Raj Mathur wrote:
Remove low-bandwidth from the list of requirements, since ssh can
compress traffic on the fly and reduce bandwidth consumption
significantly.
I would not remove low-bandwidth from the list. Compressing the
connection requires further CPU consumption, and if the requirement
26 matches
Mail list logo
