ssh2

[roland]

Hello

I am using a terminalemulator Anita to login to a server, who validates  
the ssh connection with 3DES Cipher.

Now this server is hacked, somebody entered with the root user.
Suddenly I have ssh2

So now I get the following message, when trying to login:
dsa_verify failed for server_host_key

I see the directory .ssh2 in the /root directory, but not in any $HOME dir

How can I stop ssh2 verifying?

Or is there something else I can do?

Thanks for help



-- 
Roland Brouwers
C.A.T. bvba

[Aldo Foot]

On Tue, Sep 16, 2008 at 2:30 AM, roland <roland(a)cat.be&gt; wrote:
>  Hello
>
>  I am using a terminalemulator Anita to login to a server, who validates the
>  ssh connection with 3DES Cipher.
>
>  Now this server is hacked, somebody entered with the root user.
>  Suddenly I have ssh2
>
>  So now I get the following message, when trying to login:
>  dsa_verify failed for server_host_key
>
>  I see the directory .ssh2 in the /root directory, but not in any $HOME dir
>
>  How can I stop ssh2 verifying?
>
>  Or is there something else I can do? 
I'd be backing up my data by now and getting ready to reinstall the system.

~af

[roland]

On Tue, 16 Sep 2008 18:11:05 +0200, Aldo Foot <lunixer(a)gmail.com&gt; wrote:

>  On Tue, Sep 16, 2008 at 2:30 AM, roland <roland(a)cat.be&gt; wrote:
> > Hello
> >
> > I am using a terminalemulator Anita to login to a server, who validates  
> > the
> > ssh connection with 3DES Cipher.
> >
> > Now this server is hacked, somebody entered with the root user.
> > Suddenly I have ssh2
> >
> > So now I get the following message, when trying to login:
> > dsa_verify failed for server_host_key
> >
> > I see the directory .ssh2 in the /root directory, but not in any $HOME  
> > dir
> >
> > How can I stop ssh2 verifying?
> >
> > Or is there something else I can do?
>
>  I'd be backing up my data by now and getting ready to reinstall the  
>  system.
>  
My dear friend af,

Of course you are right, I would do the same, but I am on holiday and this  
happens to a client. So I am looking for a solution for 10 days to get ssh  
working and ssh2 out, or something els.

I am blocking as much as I can out of Greece, but I have no intention to  
fly back home.

So please give me another advice, because nobody seems to know how to stop  
ssh2.

Thanks for understanding

Roland

[Aldo Foot]

>  So please give me another advice, because nobody seems to know how to
> stop
>  ssh2.
>
>  Thanks for understanding
>
>  Roland 

Have a look at this:
http://www.securityfocus.com/infocus/1806

is best if you understand some details of how keys work.
~af

[Frank Cox]

On Tue, 16 Sep 2008 18:48:22 +0200
roland <roland(a)cat.be&gt; wrote:

>  So please give me another advice,  
Shut it down if you can't get back to deal with it immediately.

Your client could be currently serving as a site hosting anything from spam to
stolen credit cards to child pornography and anything else.

I don't think the local law enforcement will accept "Our consultant was too busy
to deal with it" as an excuse when they bust your client's door down and seize
the servers.

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

[Bill Davidsen]

roland wrote:
>  On Tue, 16 Sep 2008 18:11:05 +0200, Aldo Foot
> <lunixer(a)gmail.com&gt; wrote:
>  
> > On Tue, Sep 16, 2008 at 2:30 AM, roland <roland(a)cat.be&gt; wrote:
> >> Hello
> >>
> >> I am using a terminalemulator Anita to login to a server, who 
> >> validates the
> >> ssh connection with 3DES Cipher.
> >> 
Do we assume that you tested this and it worked before you left town?

> >> Now this server is hacked, somebody entered with the root
> user.
> >> Suddenly I have ssh2
> >> 
How do you know the server is hacked? Is there evidence of that, or are you

assuming that if you can't connect it must be hacked?

> >> So now I get the following message, when trying to login:
> >> dsa_verify failed for server_host_key
> >> 
My first thought would be that you are connected to the wrong server. Could
the 
client have done admin on the server, or the network? Changed the IP address and 
you are using the old address instead of DNS? My first thought is that you have 
the wrong server or the keys were updated, or (less likely) that there is a man 
in the middle.

> >> I see the directory .ssh2 in the /root directory, but not in
> any 
> >> $HOME dir
> >>
> >> How can I stop ssh2 verifying?
> >> 
This is unclear, if you can get in, why would you stop verifying? I would
be 
finding out why the key changed. I assume you haven't been using the obsolete 
ssh1 protocol...

> >> Or is there something else I can do?
> > 
Describing the problem more fully would help, things like can you get into the

machine, and if not how you see the .ssh2 directory. I don't recall seeing that 
on any version I've used. What version of Fedora are you running on the server?

> > I'd be backing up my data by now and getting ready to
> reinstall the 
> > system.
> > 
I would have current backups, but agree, if the machine really has been hacked

it's time to start clean.

>  My dear friend af,
>  
>  Of course you are right, I would do the same, but I am on holiday and 
>  this happens to a client. So I am looking for a solution for 10 days to 
>  get ssh working and ssh2 out, or something els. 
You mean you left the client without a local backup support and you aren't going 
to return immediately? Hopefully I misunderstand that.
>  
>  I am blocking as much as I can out of Greece, but I have no intention to 
>  fly back home.
>  
>  So please give me another advice, because nobody seems to know how to 
>  stop ssh2.
>  
>  Thanks for understanding
>  
>  Roland
>   

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[Nifty Fedora Mitch]

On Tue, Sep 16, 2008 at 11:30:14AM +0200, roland wrote:
>  I am using a terminalemulator Anita to login to a server, who validates  
>  the ssh connection with 3DES Cipher.
>
>  Now this server is hacked, somebody entered with the root user.
>  Suddenly I have ssh2 
So root has been compromized?
How do you know?

>  So now I get the following message, when trying to login:
>  dsa_verify failed for server_host_key
>
>  I see the directory .ssh2 in the /root directory, but not in any $HOME dir
>
>  How can I stop ssh2 verifying?
>
>  Or is there something else I can do? 
Was Anita compromised?
Was Anita updated?
Was Anita changed?
Was the author of Anita contacted?
Anita for windows?
Anita for the web?

Is Anita connecting to sshd on the linux host in the same way that Putty does?

Can you login and 'su -' to root......

If so you can look at the logs?
Do the logs make sense?

dsa_verify failed for server_host_key tells me that a key was changed
not that the host was compromized... If you update the key the 
old key needs to be removed....  F

Is it possible that the night shift upgraded to ssh2 or added it?
Is it possible that the night shift added (incorrectly) their own key?
-- php, perl, java, etc...

As others indicated -- IF it has been HACKED
SHUT IT DOWN, pull the plug.  The legal liability
of keeping a hacked system up and running 
is large.

Are the keys in the .ssh2 dir telling you anything....

If .ssh2 does not contain your keys -- rename/remove it.

Do the keys in the .ssh2 dir belong to anyone... someone you can call.
Sometimes the comments are informative and id a host or person.

It might be that someone knows what was done in your absence.
Who else has pass words or access to the systems?


-- 
	T o m  M i t c h e l l 
	Found me a new hat, now what?

[roland]

On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch  
<niftyfedora(a)niftyegg.com&gt; wrote:

>  On Tue, Sep 16, 2008 at 11:30:14AM +0200, roland wrote:
> >
> > I am using a terminalemulator Anita to login to a server, who validates
> > the ssh connection with 3DES Cipher.
> >
> > Now this server is hacked, somebody entered with the root user.
> > Suddenly I have ssh2
>
>  So root has been compromized?
>  How do you know?
>  
I saw the login in /var/log/messages
And suddenly I had a dir  ssh2 in /root which is not normal I think. One  
only get it when generating a rsa or dsa key, isn't it?

> > So now I get the following message, when trying to login:
> > dsa_verify failed for server_host_key
> >
> > I see the directory .ssh2 in the /root directory, but not in any $HOME  
> > dir
> >
> > How can I stop ssh2 verifying?
> >
> > Or is there something else I can do?
>
>  Was Anita compromised? 
No, because I have the same problem here from out of Greece

>  Was Anita updated? 
No, why should I, it always worked, and this
version of mine works with  
all other clients

>  Was Anita changed? 
No, same answer

I have to say, somerthing akward is going on there, because all  
workstations failed to connect Anita, except one.

>  Was the author of Anita contacted? 
No
>  Anita for windows? 
yes
>  Anita for the web?
>
>  Is Anita connecting to sshd on the linux host in the same way that Putty  
>  does?
>  
How can I tell? ssh is not a thing i could say I master.

>  Can you login and 'su -' to root...... 
yes

I changed the password and know this guy is trying to login again, but  
fails. Apperently he was not ready, but maybe changed the key.
>  If so you can look at the logs?
>  Do the logs make sense? 
Yes, like I sed above.

>  dsa_verify failed for server_host_key tells me that a key was changed
>  not that the host was compromized... If you update the key the
>  old key needs to be removed....  F
>  
can  you tell me what the best way is to generate those keys, because my  
last experience with this failed.

>  Is it possible that the night shift upgraded to ssh2 or added it?
I am the only one.

>  Is it possible that the night shift added (incorrectly) their own
> key?
>  -- php, perl, java, etc... 
like above
>  As others indicated -- IF it has been HACKED
>  SHUT IT DOWN, pull the plug.  The legal liability
>  of keeping a hacked system up and running
>  is large. 
As I sed, I will do this when I'm back from holidays.
>  Are the keys in the .ssh2 dir telling you anything... 
??.
>  If .ssh2 does not contain your keys -- rename/remove it.
>
>  Do the keys in the .ssh2 dir belong to anyone... someone you can call.
>  Sometimes the comments are informative and id a host or person.
>
>  It might be that someone knows what was done in your absence.
>  Who else has pass words or access to the systems? 
those who could know about the
root password don't know anything about  
linux or others.
>  
How does ssh checks keys. I am asking this because anita fails before she  
knows who is login in. So if she takes the login of windows which is mine,  
she would login or check in $HOME/.ssh. And in $HOME there is no .ssh2, so  
probably there will be checked in /etc/ssh/ for dsa and rsa keys. So if I  
remove those keys, would that change it?

Thanks again
roland

[Bill Davidsen]

roland wrote:
>  On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch 
>  <niftyfedora(a)niftyegg.com&gt; wrote:
>  
> > On Tue, Sep 16, 2008 at 11:30:14AM +0200, roland wrote:
> >>
> >> I am using a terminalemulator Anita to login to a server, who validates
> >> the ssh connection with 3DES Cipher.
> >>
> >> Now this server is hacked, somebody entered with the root user.
> >> Suddenly I have ssh2
> >
> > So root has been compromized?
> > How do you know?
> >
>  I saw the login in /var/log/messages
>  And suddenly I had a dir  ssh2 in /root which is not normal I think. One 
>  only get it when generating a rsa or dsa key, isn't it?
>  
> >> So now I get the following message, when trying to login:
> >> dsa_verify failed for server_host_key
> >> 
Again: that is because the host key on the server has changed, probably
because 
a new sshd has been installed. The fact that the old keys were not used means 
either an incompetent hacker or just that you are connected to the wrong 
machine. It's a warning from your terminal program, so you don't type a password 
which can be stolen.

> >> I see the directory .ssh2 in the /root directory, but not in
> any 
> >> $HOME dir
> >>
> >> How can I stop ssh2 verifying?
> >>
> >> Or is there something else I can do?
> >
> > Was Anita compromised?
>  No, because I have the same problem here from out of Greece
>  
> > Was Anita updated?
>  No, why should I, it always worked, and this version of mine works with 
>  all other clients
>  
> > Was Anita changed?
>  No, same answer
>  
>  I have to say, somerthing akward is going on there, because all 
>  workstations failed to connect Anita, except one.
>  
> > Was the author of Anita contacted?
>  No
> > Anita for windows?
>  yes
> > Anita for the web?
> >
> > Is Anita connecting to sshd on the linux host in the same way that 
> > Putty does?
> >
>  How can I tell? ssh is not a thing i could say I master.
>  
> > Can you login and 'su -' to root......
>  yes
>  
>  I changed the password and know this guy is trying to login again, but 
>  fails. Apperently he was not ready, but maybe changed the key.
> >
> > If so you can look at the logs?
> > Do the logs make sense?
>  Yes, like I sed above.
>  
> >
> > dsa_verify failed for server_host_key tells me that a key was changed
> > not that the host was compromized... If you update the key the
> > old key needs to be removed....  F
> >
>  can  you tell me what the best way is to generate those keys, because my 
>  last experience with this failed.
>  
> > Is it possible that the night shift upgraded to ssh2 or added it?
>  I am the only one.
>  
> > Is it possible that the night shift added (incorrectly) their own key?
> > -- php, perl, java, etc...
>  like above
> >
> > As others indicated -- IF it has been HACKED
> > SHUT IT DOWN, pull the plug.  The legal liability
> > of keeping a hacked system up and running
> > is large.
>  As I sed, I will do this when I'm back from holidays.
> >
> > Are the keys in the .ssh2 dir telling you anything...
>  ??.
> >
> > If .ssh2 does not contain your keys -- rename/remove it.
> >
> > Do the keys in the .ssh2 dir belong to anyone... someone you can call.
> > Sometimes the comments are informative and id a host or person.
> >
> > It might be that someone knows what was done in your absence.
> > Who else has pass words or access to the systems?
>  those who could know about the root password don't know anything about 
>  linux or others.
> >
> >
>  How does ssh checks keys. I am asking this because anita fails before 
>  she knows who is login in. So if she takes the login of windows which is 
>  mine, she would login or check in $HOME/.ssh. And in $HOME there is no 
>  .ssh2, so probably there will be checked in /etc/ssh/ for dsa and rsa 
>  keys. So if I remove those keys, would that change it?
>   
I would not expect the .ssh2 directory to be generated on login from outside, 
although ssh would check for an "authorized keys" file. In checking a number of

accounts I know are used but not for outgoing ssh, I find no such directories on 
any account. Therefore I'm reasonably certain that this was created for an 
outgoing ssh connection.

The reason you get a host key warning is that the host keys in /etc/ssh have 
been changed. It might be that you have an unauthorized copy of sshd running 
which is keylogging every password used to login. This is why people are telling 
you to shut the machine down, it may well be doing more damage every day.

What are the dates on the files in /etc/ssh*? In the .ssh2 directory? Is your 
client going to suffer any damages by having all of their data and passwords 
revealed?

>  Thanks again
>  roland
>  
>  
>  
>  
>  
>  
>  
>   

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[Nifty Fedora Mitch]

On Wed, Sep 17, 2008 at 08:49:43AM +0200, roland wrote:
>  On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch  
>  <niftyfedora(a)niftyegg.com&gt; wrote:
> > On Tue, Sep 16, 2008 at 11:30:14AM +0200, roland wrote:
> >>
> >> I am using a terminalemulator Anita to login to a server, who validates
> >> the ssh connection with 3DES Cipher.
> >> 
,,,,,

>  How does ssh checks keys. I am asking this because anita fails before
> she 
>  knows who is login in. So if she takes the login of windows which is 
>  mine, she would login or check in $HOME/.ssh. And in $HOME there is no 
>  .ssh2, so probably there will be checked in /etc/ssh/ for dsa and rsa 
>  keys. So if I remove those keys, would that change it? 
Do contact the Anita authors.....  you paid for their product.

Background reading http://www.openssh.com/   AND "man ssh; man sshd".


In general for ssh:

There is a set of system key pairs on the host.
   /etc/ssh/ssh_host_dsa_key
   /etc/ssh/ssh_host_dsa_key.pub

And a set of user key pairs on your laptop/ desktop. On linux these are
here... on Windows Anita I do not know.

    ~/.ssh/id_dsa
    ~/.ssh/id_dsa.pub

When connecting to a host there is an initial handshake that involves
the host itself and the hosts key pair.  The signatures of known
hosts are cached in the "known_hosts" file and is used to establish the
initial transport layer and establishes ongoing validation of the host.
This involves the host keys on the server and the known_hosts file on
your laptop.  Anita has a known_hosts equivalent file someplace.  If 
the host keys change (on purpose) you need to update this cache.

Following the initial transport layer setup is the user authentication
layer.  It involves the key pair (id_dsa) on your laptop.  Optionally it
can involve the authorized_keys file on the server which can contain
the public half of the key pair (id_dsa.pub only the public half).  It is possible to use
password authentication over the  secure channel setup in the transport
layer step if the administrator allows it.  The secure link involves the HOST keys.

    $ ls -l  ~/.ssh
    total 52
    -rw------- 1 mitch mitch 8115 2008-09-14 22:39 authorized_keysb
    -rw------- 1 mitch mitch  387 2008-09-14 22:39 config
    -rw------- 1 mitch mitch  744 2008-09-14 22:39 id_dsa
    -rw-r--r-- 1 mitch mitch  946 2008-09-15 11:18 id_dsa.keystore
    -rw------- 1 mitch mitch  615 2008-09-14 22:39 id_dsa.pub
    -rw-r--r-- 1 mitch mitch 8758 2008-09-15 14:09 known_hosts

If the hosts  key pair is compromized it needs to be regenerated.
Anyone with the pair can do stuff.   If you look at /etc/init.d/sshd
on the host you should see code that checks for and if needed generates
the key pairs.  I have not tried it remotly but if you remove /etc/ssh_host_dsa*
and rerun /etc/init.d/sshd you should have a new pair.   In addition
you will see rsa keys.

    $ ls /etc/ssh/*rs*
    /etc/ssh/ssh_host_rsa_key  /etc/ssh/ssh_host_rsa_key.pub

These rsa keys also need to be replaced in the same way if the host has been compromized.

There are three perhaps four key pairs that must be  managed.  The host
dsa and rsa key pair and personal dsa keys.  If you have an rsa keypair
it may also need to be replaced.   Since your keys are used for root access
you MUST have a local lock phrase.

If you remove the keypair from the host --
	# rm *key*
	rm: remove regular file `ssh_host_dsa_key'? y
	rm: remove regular file `ssh_host_dsa_key.pub'? y
	rm: remove regular file `ssh_host_key'? y
	rm: remove regular file `ssh_host_key.pub'? y
	rm: remove regular file `ssh_host_rsa_key'? y
	rm: remove regular file `ssh_host_rsa_key.pub'? y
 
With the keys missing you will see an error.
	$ ssh boxtotest
	ssh_exchange_identification: Connection closed by remote host

Now to rekey the server box (on the server).
	# /etc/init.d/sshd restart
	Stopping sshd:                                             [  OK  ]
	Generating SSH1 RSA host key:                              [  OK  ]
	Generating SSH2 RSA host key:                              [  OK  ]
	Generating SSH2 DSA host key:                              [  OK  ]
	Starting sshd:                                             [  OK  ]

Now to reconnect... (I am tinkering on a single box).
	$ ssh localhost
	The authenticity of host 'localhost (127.0.0.1)' can't be established.
	RSA key fingerprint is f7:53:8a:b7:a1:82:97:26:76:21:bd:74:85:d1:4e:67.
	Are you sure you want to continue connecting (yes/no)? yes
	Warning: Permanently added 'localhost' (RSA) to the list of known hosts.

N.B. (Note well) the new fingerprint the "are you sure" question and that it is

     Perminently added to the list of known hosts.

SSH1 connections should be disallowed in your sshd config file.
see /etc/ssh/sshd_config as well as your personal ssh config.


-- 
	T o m  M i t c h e l l 
	Found me a new hat, now what?

[roland]

On Thu, 18 Sep 2008 00:30:17 +0200, Nifty Fedora Mitch  
<niftyfedora(a)niftyegg.com&gt; wrote:

>  On Wed, Sep 17, 2008 at 08:49:43AM +0200, roland wrote:
> > On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch
> > <niftyfedora(a)niftyegg.com&gt; wrote:
> >> On Tue, Sep 16, 2008 at 11:30:14AM +0200, roland wrote:
> >>>
> >>> I am using a terminalemulator Anita to login to a server, who  
> >>> validates
> >>> the ssh connection with 3DES Cipher.
> >>>
>  ,,,,,
>
> > How does ssh checks keys. I am asking this because anita fails before  
> > she
> > knows who is login in. So if she takes the login of windows which is
> > mine, she would login or check in $HOME/.ssh. And in $HOME there is no
> > .ssh2, so probably there will be checked in /etc/ssh/ for dsa and rsa
> > keys. So if I remove those keys, would that change it?
>
>  Do contact the Anita authors.....  you paid for their product.
>
>  Background reading http://www.openssh.com/   AND "man ssh; man sshd".
>
>
>  In general for ssh:
>
>  There is a set of system key pairs on the host.
>     /etc/ssh/ssh_host_dsa_key
>     /etc/ssh/ssh_host_dsa_key.pub
>
>  And a set of user key pairs on your laptop/ desktop. On linux these are
>  here... on Windows Anita I do not know.
>
>      ~/.ssh/id_dsa
>      ~/.ssh/id_dsa.pub
>
>  When connecting to a host there is an initial handshake that involves
>  the host itself and the hosts key pair.  The signatures of known
>  hosts are cached in the "known_hosts" file and is used to establish the
>  initial transport layer and establishes ongoing validation of the host.
>  This involves the host keys on the server and the known_hosts file on
>  your laptop.  Anita has a known_hosts equivalent file someplace.  If
>  the host keys change (on purpose) you need to update this cache.
>
>  Following the initial transport layer setup is the user authentication
>  layer.  It involves the key pair (id_dsa) on your laptop.  Optionally it
>  can involve the authorized_keys file on the server which can contain
>  the public half of the key pair (id_dsa.pub only the public half).  It  
>  is possible to use
>  password authentication over the  secure channel setup in the transport
>  layer step if the administrator allows it.  The secure link involves the  
>  HOST keys.
>
>      $ ls -l  ~/.ssh
>      total 52
>      -rw------- 1 mitch mitch 8115 2008-09-14 22:39 authorized_keysb
>      -rw------- 1 mitch mitch  387 2008-09-14 22:39 config
>      -rw------- 1 mitch mitch  744 2008-09-14 22:39 id_dsa
>      -rw-r--r-- 1 mitch mitch  946 2008-09-15 11:18 id_dsa.keystore
>      -rw------- 1 mitch mitch  615 2008-09-14 22:39 id_dsa.pub
>      -rw-r--r-- 1 mitch mitch 8758 2008-09-15 14:09 known_hosts
>
>  If the hosts  key pair is compromized it needs to be regenerated.
>  Anyone with the pair can do stuff.   If you look at /etc/init.d/sshd
>  on the host you should see code that checks for and if needed generates
>  the key pairs.  I have not tried it remotly but if you remove  
>  /etc/ssh_host_dsa*
>  and rerun /etc/init.d/sshd you should have a new pair.   In addition
>  you will see rsa keys.
>
>      $ ls /etc/ssh/*rs*
>      /etc/ssh/ssh_host_rsa_key  /etc/ssh/ssh_host_rsa_key.pub
>
>  These rsa keys also need to be replaced in the same way if the host has  
>  been compromized.
>
>  There are three perhaps four key pairs that must be  managed.  The host
>  dsa and rsa key pair and personal dsa keys.  If you have an rsa keypair
>  it may also need to be replaced.   Since your keys are used for root  
>  access
>  you MUST have a local lock phrase.
>
>  If you remove the keypair from the host --
>  	# rm *key*
>  	rm: remove regular file `ssh_host_dsa_key'? y
>  	rm: remove regular file `ssh_host_dsa_key.pub'? y
>  	rm: remove regular file `ssh_host_key'? y
>  	rm: remove regular file `ssh_host_key.pub'? y
>  	rm: remove regular file `ssh_host_rsa_key'? y
>  	rm: remove regular file `ssh_host_rsa_key.pub'? y
>  With the keys missing you will see an error.
>  	$ ssh boxtotest
>  	ssh_exchange_identification: Connection closed by remote host
>
>  Now to rekey the server box (on the server).
>  	# /etc/init.d/sshd restart
>  	Stopping sshd:                                             [  OK  ]
>  	Generating SSH1 RSA host key:                              [  OK  ]
>  	Generating SSH2 RSA host key:                              [  OK  ]
>  	Generating SSH2 DSA host key:                              [  OK  ]
>  	Starting sshd:                                             [  OK  ]
>
>  Now to reconnect... (I am tinkering on a single box).
>  	$ ssh localhost
>  	The authenticity of host 'localhost (127.0.0.1)' can't be established.
>  	RSA key fingerprint is f7:53:8a:b7:a1:82:97:26:76:21:bd:74:85:d1:4e:67.
>  	Are you sure you want to continue connecting (yes/no)? yes
>  	Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
>
>  N.B. (Note well) the new fingerprint the "are you sure" question and  
>  that it is
>       Perminently added to the list of known hosts.
>
>  SSH1 connections should be disallowed in your sshd config file.
>  see /etc/ssh/sshd_config as well as your personal ssh config.
>
>  
Waw, this is a very exhaustive answer, and I thank you very much for this.

How will have to do some reading.
One thing is for sure, I find the known-hosts in de userdir on windows but  
there are no entries added and I do not find anywhere the dsa or rsa or  
whatever keys.

I removed all the keys in /etc/ssh/ and
indeed the keys were recreated.

But Anita continues this difficulty and Putty never did.
Must have to do something with this 3DES.

I don't understand how Putty can login because there aren't any entries in  
known_hosts under windows which are referring to the hosts I'm logging  
into. ???

Must be a Bill Gates miracle.

I thank you very much and if I find something worth writing about I will  
get back to this.

-- 
Roland Brouwers
C.A.T. bvba
B-2660 Antwerpen
Tel: [phone]
Mob: [phone]

[Bill Davidsen]

roland wrote:

>  Waw, this is a very exhaustive answer, and I thank you very much for
> this.
>  
>  How will have to do some reading.
>  One thing is for sure, I find the known-hosts in de userdir on windows 
>  but there are no entries added and I do not find anywhere the dsa or rsa 
>  or whatever keys.
>  
>  I removed all the keys in /etc/ssh/ and
>  indeed the keys were recreated.
>   
Yes, that is the original problem, the host keys changed.

>  But Anita continues this difficulty and Putty never did. 
Anita has no "problem," it is warning you that the host has changed. Trying to 
stop the warning instead of fixing the problem is like taking the battery out of 
the smoke alarm instead of finding the fire!

>  Must have to do something with this 3DES.
>   
It has to do with the system being hacked.

>  I don't understand how Putty can login because there aren't
> any entries 
>  in known_hosts under windows which are referring to the hosts I'm 
>  logging into. ???
>   
That's why putty can't detect that there's a problem, because it
doesn't have 
the *correct* values, and so doesn't know that there is now an incorrect host 
key machine at the end of the socket.

>  Must be a Bill Gates miracle.
>  
>  I thank you very much and if I find something worth writing about I will 
>  get back to this.
>   
-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[roland]

On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen <davidsen(a)tmr.com&gt; wrote:

>  roland wrote:
>
> > Waw, this is a very exhaustive answer, and I thank you very much for  
> > this.
> >  How will have to do some reading.
> > One thing is for sure, I find the known-hosts in de userdir on windows  
> > but there are no entries added and I do not find anywhere the dsa or  
> > rsa or whatever keys.
> >  I removed all the keys in /etc/ssh/ and
> > indeed the keys were recreated.
> >
>  Yes, that is the original problem, the host keys changed.
>
> > But Anita continues this difficulty and Putty never did.
>
>  Anita has no "problem," it is warning you that the host has changed.  
>  Trying to stop the warning instead of fixing the problem is like taking  
>  the battery out of the smoke alarm instead of finding the fire!
>
> > Must have to do something with this 3DES.
> >
>  It has to do with the system being hacked.
>
> > I don't understand how Putty can login because there aren't any entries  
> > in known_hosts under windows which are referring to the hosts I'm  
> > logging into. ???
> >
>  That's why putty can't detect that there's a problem, because it doesn't 
>
>  have the *correct* values, and so doesn't know that there is now an  
>  incorrect host key machine at the end of the socket. 
Putty is using ssh2. So if the key of the remote host is not found in  
known_hosts on the mswindow station, why does nobody complaints? When will  
the key of the remote host be added in this file known_hosts?

following this doc here after your assumption is not correct, or do I  
understand something wrong?

If you reinstall, the reinstalled system creates a new set of  
identification keys. Any clients who had connected to the system with any  
of the OpenSSH tools before the reinstall will see the following message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Roland

[roland]

On Sat, 20 Sep 2008 08:27:49 +0200, roland <roland(a)cat.be&gt; wrote:

>  On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen
> <davidsen(a)tmr.com&gt;  
>  wrote:
>
> > roland wrote:
> >
> >> Waw, this is a very exhaustive answer, and I thank you very much for  
> >> this.
> >>  How will have to do some reading.
> >> One thing is for sure, I find the known-hosts in de userdir on windows  
> >> but there are no entries added and I do not find anywhere the dsa or  
> >> rsa or whatever keys.
> >>  I removed all the keys in /etc/ssh/ and
> >> indeed the keys were recreated.
> >>
> > Yes, that is the original problem, the host keys changed.
> >
> >> But Anita continues this difficulty and Putty never did.
> >
> > Anita has no "problem," it is warning you that the host has changed.  
> > Trying to stop the warning instead of fixing the problem is like taking  
> > the battery out of the smoke alarm instead of finding the fire!
> >
> >> Must have to do something with this 3DES.
> >>
> > It has to do with the system being hacked.
> >
> >> I don't understand how Putty can login because there aren't any  
> >> entries in known_hosts under windows which are referring to the hosts  
> >> I'm logging into. ???
> >>
> > That's why putty can't detect that there's a problem, because it  
> > doesn't have the *correct* values, and so doesn't know that there is  
> > now an incorrect host key machine at the end of the socket.
>
>  Putty is using ssh2. So if the key of the remote host is not found in  
>  known_hosts on the mswindow station, why does nobody complaints? When  
>  will the key of the remote host be added in this file known_hosts?
>
>  following this doc here after your assumption is not correct, or do I  
>  understand something wrong?
>
>  If you reinstall, the reinstalled system creates a new set of  
>  identification keys. Any clients who had connected to the system with  
>  any of the OpenSSH tools before the reinstall will see the following  
>  message:
>  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
>  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>  Someone could be eavesdropping on you right now (man-in-the-middle  
>  attack)!
>  It is also possible that the RSA host key has just been changed.
>  
also if your read this

The first time you ssh to a remote machine, you will see a message similar  
to the following:
The authenticity of host 'penguin.example.net' can't be established.
DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?

Type yes to continue. This will add the server to your list of known hosts  
(~/.ssh/known_hosts) as seen in the following message:
Warning: Permanently added 'penguin.example.net' (RSA) to the list of  
known hosts


none of this happens on this server or on the mswin pc

Roland

[Bill Davidsen]

roland wrote:
>  On Sat, 20 Sep 2008 08:27:49 +0200, roland <roland(a)cat.be&gt;
> wrote:
>  
> > On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen <davidsen(a)tmr.com&gt; 
> > wrote:
> >
> >> roland wrote:
> >>
> >>> Waw, this is a very exhaustive answer, and I thank you very much for 
> >>> this.
> >>>  How will have to do some reading.
> >>> One thing is for sure, I find the known-hosts in de userdir on 
> >>> windows but there are no entries added and I do not find anywhere 
> >>> the dsa or rsa or whatever keys.
> >>>  I removed all the keys in /etc/ssh/ and
> >>> indeed the keys were recreated.
> >>>
> >> Yes, that is the original problem, the host keys changed.
> >>
> >>> But Anita continues this difficulty and Putty never did.
> >>
> >> Anita has no "problem," it is warning you that the host has changed. 
> >> Trying to stop the warning instead of fixing the problem is like 
> >> taking the battery out of the smoke alarm instead of finding the fire!
> >>
> >>> Must have to do something with this 3DES.
> >>>
> >> It has to do with the system being hacked.
> >>
> >>> I don't understand how Putty can login because there aren't any 
> >>> entries in known_hosts under windows which are referring to the 
> >>> hosts I'm logging into. ???
> >>>
> >> That's why putty can't detect that there's a problem, because it 
> >> doesn't have the *correct* values, and so doesn't know that there is 
> >> now an incorrect host key machine at the end of the socket.
> >
> > Putty is using ssh2. So if the key of the remote host is not found in 
> > known_hosts on the mswindow station, why does nobody complaints? When 
> > will the key of the remote host be added in this file known_hosts?
> >
> > following this doc here after your assumption is not correct, or do I 
> > understand something wrong?
> >
> > If you reinstall, the reinstalled system creates a new set of 
> > identification keys. Any clients who had connected to the system with 
> > any of the OpenSSH tools before the reinstall will see the following 
> > message:
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> > Someone could be eavesdropping on you right now (man-in-the-middle 
> > attack)!
> > It is also possible that the RSA host key has just been changed.
> >
>  also if your read this
>  
>  The first time you ssh to a remote machine, you will see a message 
>  similar to the following:
>  The authenticity of host 'penguin.example.net' can't be established.
>  DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
>  Are you sure you want to continue connecting (yes/no)?
>  
>  Type yes to continue. This will add the server to your list of known 
>  hosts (~/.ssh/known_hosts) as seen in the following message:
>  Warning: Permanently added 'penguin.example.net' (RSA) to the list of 
>  known hosts
>  
>  
>  none of this happens on this server or on the mswin pc
>   
This is client behavior of the shh Fedora client. Neither amanda nor putty need 
to do this behavior to use the ssh2 protocol. I think putty does store the host 
key, but I haven't used it in some time.

>  Roland
>   

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[Bill Davidsen]

roland wrote:
>  On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen
> <davidsen(a)tmr.com&gt; wrote:
>  
> > roland wrote:
> >
> >> Waw, this is a very exhaustive answer, and I thank you very much for 
> >> this.
> >>  How will have to do some reading.
> >> One thing is for sure, I find the known-hosts in de userdir on 
> >> windows but there are no entries added and I do not find anywhere the 
> >> dsa or rsa or whatever keys.
> >>  I removed all the keys in /etc/ssh/ and
> >> indeed the keys were recreated.
> >>
> > Yes, that is the original problem, the host keys changed.
> >
> >> But Anita continues this difficulty and Putty never did.
> >
> > Anita has no "problem," it is warning you that the host has changed. 
> > Trying to stop the warning instead of fixing the problem is like 
> > taking the battery out of the smoke alarm instead of finding the fire!
> >
> >> Must have to do something with this 3DES.
> >>
> > It has to do with the system being hacked.
> >
> >> I don't understand how Putty can login because there aren't any 
> >> entries in known_hosts under windows which are referring to the hosts 
> >> I'm logging into. ???
> >>
> > That's why putty can't detect that there's a problem, because it 
> > doesn't have the *correct* values, and so doesn't know that there is 
> > now an incorrect host key machine at the end of the socket.
>  
>  Putty is using ssh2. So if the key of the remote host is not found in 
>  known_hosts on the mswindow station, why does nobody complaints? When 
>  will the key of the remote host be added in this file known_hosts?
>   
Putty uses the ssh2 protocol, but probably not the code (haven't looked). In
any 
case, the key is added in the Fedora ssh program after asking if you trust the 
connection (and verify the fingerprint). Without going back and checking to see 
how putty does this (haven't use putty in several years) I can't say how it 
works. I think I recall doing a manual step to save the key, but I haven't 
needed putty since 25 months now.

The use of known_hosts is done by the client, the protocol allows checking.

>  following this doc here after your assumption is not correct, or do I
>
>  understand something wrong?
>   
What you describe below is the behavior of ssh as provided by Fedora, and
that's 
based on OpenSSH from the OpenBSD project. This is their client's warning.

>  If you reinstall, the reinstalled system creates a new set of 
>  identification keys. Any clients who had connected to the system with 
>  any of the OpenSSH tools before the reinstall will see the following 
>  message:
>  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
>  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
>  It is also possible that the RSA host key has just been changed. 
The worrying thing is that since the sshd now asks for ssh2 protocol only, there 
is a new sshd operating, one you didn't install, and one which may be copying 
keystroke data (login names and passwords) to some unauthorized other site. I 
can't say that's happening, but this has all of the characteristics of that. It 
could also be caused by an upgrade of sshd, although I read your posts to say 
that only you could do that.

It would be useful to use 'ps' to see which sshd is running, and to do an 'ls

-l' and md5sum on the executable and post the values here. Also a telnet to the 
ssh port usually gives the protocol and sshd version, although that can be 
faked. Post that if you wish.
>  
>  Roland
>   

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[roland]

On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen <davidsen(a)tmr.com&gt; wrote:

>  roland wrote:
> > On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen <davidsen(a)tmr.com&gt;  
> > wrote:
> >
> >> roland wrote:
> >>
> >>> Waw, this is a very exhaustive answer, and I thank you very much for  
> >>> this.
> >>>  How will have to do some reading.
> >>> One thing is for sure, I find the known-hosts in de userdir on  
> >>> windows but there are no entries added and I do not find anywhere the  
> >>> dsa or rsa or whatever keys.
> >>>  I removed all the keys in /etc/ssh/ and
> >>> indeed the keys were recreated.
> >>>
> >> Yes, that is the original problem, the host keys changed.
> >>
> >>> But Anita continues this difficulty and Putty never did.
> >>
> >> Anita has no "problem," it is warning you that the host has changed.  
> >> Trying to stop the warning instead of fixing the problem is like  
> >> taking the battery out of the smoke alarm instead of finding the fire!
> >>
> >>> Must have to do something with this 3DES.
> >>>
> >> It has to do with the system being hacked.
> >>
> >>> I don't understand how Putty can login because there aren't any  
> >>> entries in known_hosts under windows which are referring to the hosts  
> >>> I'm logging into. ???
> >>>
> >> That's why putty can't detect that there's a problem, because it  
> >> doesn't have the *correct* values, and so doesn't know that there is  
> >> now an incorrect host key machine at the end of the socket.
> >  Putty is using ssh2. So if the key of the remote host is not found in  
> > known_hosts on the mswindow station, why does nobody complaints? When  
> > will the key of the remote host be added in this file known_hosts?
> >
>  Putty uses the ssh2 protocol, but probably not the code (haven't  
>  looked). In any case, the key is added in the Fedora ssh program after  
>  asking if you trust the connection (and verify the fingerprint). Without  
>  going back and checking to see how putty does this (haven't use putty in  
>  several years) I can't say how it works. I think I recall doing a manual  
>  step to save the key, but I haven't needed putty since 25 months now.
>
>  The use of known_hosts is done by the client, the protocol allows  
>  checking.
>
> > following this doc here after your assumption is not correct, or do I  
> > understand something wrong?
> >
>  What you describe below is the behavior of ssh as provided by Fedora,  
>  and that's based on OpenSSH from the OpenBSD project. This is their  
>  client's warning.
>
> > If you reinstall, the reinstalled system creates a new set of  
> > identification keys. Any clients who had connected to the system with  
> > any of the OpenSSH tools before the reinstall will see the following  
> > message:
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> > Someone could be eavesdropping on you right now (man-in-the-middle  
> > attack)!
> > It is also possible that the RSA host key has just been changed.
>
>  The worrying thing is that since the sshd now asks for ssh2 protocol  
>  only, there is a new sshd operating, one you didn't install, and one  
>  which may be copying keystroke data (login names and passwords) to some  
>  unauthorized other site. I can't say that's happening, but this has all  
>  of the characteristics of that. It could also be caused by an upgrade of  
>  sshd, although I read your posts to say that only you could do that.
>
>  It would be useful to use 'ps' to see which sshd is running, and to do  
>  an 'ls -l' and md5sum on the executable and post the values here. Also a  
>  telnet to the ssh port usually gives the protocol and sshd version,  
>  although that can be faked. Post that if you wish 
You will find it in  annex

Thanks again for your time

Roland

[Bill Davidsen]

roland wrote:
>  On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen
> <davidsen(a)tmr.com&gt; wrote:
>  
> > The worrying thing is that since the sshd now asks for ssh2 protocol 
> > only, there is a new sshd operating, one you didn't install, and one 
> > which may be copying keystroke data (login names and passwords) to 
> > some unauthorized other site. I can't say that's happening, but this 
> > has all of the characteristics of that. It could also be caused by an 
> > upgrade of sshd, although I read your posts to say that only you could 
> > do that.
> >
> > It would be useful to use 'ps' to see which sshd is running, and to do 
> > an 'ls -l' and md5sum on the executable and post the values here. Also 
> > a telnet to the ssh port usually gives the protocol and sshd version, 
> > although that can be faked. Post that if you wish
>  
>  You will find it in  annex
>  
>  Thanks again for your time 
 From the attachment:

>  telnet localhost 22
>  Trying 127.0.0.1...
>  Connected to localhost.
>  Escape character is '^]'.
>  SSH-2.0-SSH-1.99-OpenSSH_3.5p1 
That is a *very* old version of OpenSSH, nothing you got from Fedora, I believe. 
I think it's something which the hacker installed, and a hacked sshd would be 
the perfect place to capture login and password information.

>  service sshd status
>  As you can see it doesn't give sshd but this crazy characters, in both cases
>
>  1628 ?        S      0:02 ?a?@°Ó?@?
>  22871 ?        S      0:00 ?a?@°Ó?@? 
Just how old a Fedora do you have? This doesn't look at all as I would expect. 
You might do "ls -lc /bin/ps" and see if that was recently replaced as well. 
However:

>  ls -l /usr/sbin/sshd
>  -rwxr-xr-x    1 root     root      3963123 sep 16 00:03 /usr/sbin/sshd 
This looks as if the sshd was replaced a few days ago, shortly before your first 
message to the list. That makes it even more likely that passwords are being 
captured, perhaps even entire connect sessions.

It looks as if the machine has been totally penetrated, and of course if you 
don't use different account names and passwords for other machines they have as 
well.

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[roland]

On Mon, 22 Sep 2008 15:47:26 +0200, Bill Davidsen <davidsen(a)tmr.com&gt; wrote:

>  roland wrote:
> > On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen <davidsen(a)tmr.com&gt;  
> > wrote:
> >
> >> The worrying thing is that since the sshd now asks for ssh2 protocol  
> >> only, there is a new sshd operating, one you didn't install, and one  
> >> which may be copying keystroke data (login names and passwords) to  
> >> some unauthorized other site. I can't say that's happening, but this  
> >> has all of the characteristics of that. It could also be caused by an  
> >> upgrade of sshd, although I read your posts to say that only you could  
> >> do that.
> >>
> >> It would be useful to use 'ps' to see which sshd is running, and to do  
> >> an 'ls -l' and md5sum on the executable and post the values here. Also  
> >> a telnet to the ssh port usually gives the protocol and sshd version,  
> >> although that can be faked. Post that if you wish
> >  You will find it in  annex
> >  Thanks again for your time
>
>   From the attachment:
>
>   > telnet localhost 22
>   > Trying 127.0.0.1...
>   > Connected to localhost.
>   > Escape character is '^]'.
>   > SSH-2.0-SSH-1.99-OpenSSH_3.5p1
>
>  That is a *very* old version of OpenSSH, nothing you got from Fedora, I  
>  believe. I think it's something which the hacker installed, and a hacked  
>  sshd would be the perfect place to capture login and password  
>  information.
>
>   > service sshd status
>   > As you can see it doesn't give sshd but this crazy characters, in  
>  both cases
>   >
>   > 1628 ?        S      0:02 ?a?@°Ó?@?
>   > 22871 ?        S      0:00 ?a?@°Ó?@?
>
>  Just how old a Fedora do you have? This doesn't look at all as I would  
>  expect. You might do "ls -lc /bin/ps" and see if that was recently  
>  replaced as well. However:
>
>   > ls -l /usr/sbin/sshd
>   > -rwxr-xr-x    1 root     root      3963123 sep 16 00:03 /usr/sbin/sshd
>
>  This looks as if the sshd was replaced a few days ago, shortly before  
>  your first message to the list. That makes it even more likely that  
>  passwords are being captured, perhaps even entire connect sessions.
>
>  It looks as if the machine has been totally penetrated, and of course if  
>  you don't use different account names and passwords for other machines  
>  they have as well.
>  
This is an old version of redhat workstation, just before fedora was  
released.
-r-xr-xr-x    1 root     root        69772 feb 20  2003 /bin/ps
-rw-r--r--    1 root     root           33 feb 26  2003 /etc/redhat-release
  more /etc/redhat-release
Red Hat Linux release 9 (Shrike)

I just wonder why this person/hacker is still trying to login with root  
and other names. So he must have been unsuccessful the first time. Now  
root login is blocked and the root passwd is  changed.

 From what you are saying I can understand that I should reinstall the  
server, even if he is not successfully login in again?



roland

[Aldo Foot]

On Wed, Sep 24, 2008 at 12:04 AM, roland <roland(a)cat.be&gt; wrote:
>  I just wonder why this person/hacker is still trying to login with
> root and
>  other names. So he must have been unsuccessful the first time. Now root
>  login is blocked and the root passwd is  changed.
>
>  From what you are saying I can understand that I should reinstall the
>  server, even if he is not successfully login in again? 
If the root password is changed once again, then it's clear someone is
mocking you.
Just unplug that system already and reinstall. Upgrade to a more recent
OS if you can. Go CentOS if Fedora is too hard for you.
But more importantly learn about tcpwrappers and system security otherwise
it does not matter what effort you put into this thing. You must learn
on your own.


~af

[roland]

On Wed, 24 Sep 2008 18:12:24 +0200, Aldo Foot <lunixer(a)gmail.com&gt; wrote:

>  On Wed, Sep 24, 2008 at 12:04 AM, roland <roland(a)cat.be&gt;
> wrote:
> > I just wonder why this person/hacker is still trying to login with root  
> > and
> > other names. So he must have been unsuccessful the first time. Now root
> > login is blocked and the root passwd is  changed.
> >
> > From what you are saying I can understand that I should reinstall the
> > server, even if he is not successfully login in again?
>
>  If the root password is changed once again, then it's clear someone is
>  mocking you.
>  Just unplug that system already and reinstall. Upgrade to a more recent
>  OS if you can. Go CentOS if Fedora is too hard for you.
>  But more importantly learn about tcpwrappers and system security  
>  otherwise
>  it does not matter what effort you put into this thing. You must learn
>  on your own.
>  
I was not clear enough,
I did changed the password for root and I blocked remote root login.
Now he is still trying to login with root, but unsuccessfully. So probably  
he did not finished his job.

roland

[Aldo Foot]

On Wed, Sep 24, 2008 at 11:00 AM, roland <roland(a)cat.be&gt; wrote:
> >
>  I was not clear enough,
>  I did changed the password for root and I blocked remote root login.
>  Now he is still trying to login with root, but unsuccessfully. So probably
>  he did not finished his job.
>
>  roland 
It was not clear to me whether you or the attacker had changed the root
password.
This guy's got your number and will keep coming.
I would have pull the plug on that system long ago.
There's nothing else really to do about this. I wish you luck with that system.


~af

[Björn Persson]

roland wrote:
>  This is an old version of redhat workstation, just before fedora was
>  released. 
No wonder it was broken into then. Actually, if it hasn't been updated since 
2003 it's something of a wonder if you haven't had any intrusions until now. 
Perhaps the intruders who have been using the box before have been more 
discreet so that you haven't noticed them.

>  I just wonder why this person/hacker is still trying to login with
> root
>  and other names. So he must have been unsuccessful the first time. 
What makes you think it's the same person? There are bots on compromised 
computers constantly scanning the Internet and trying to access any SSH 
servers they find. It's been going on for years. Do you have proof that the 
login attempts you see are something else?

>   From what you are saying I can understand that I should reinstall
> the
>  server, even if he is not successfully login in again? 
Yes you should. Once the system is compromised you can't trust anything in it. 
Unless the intruder is a complete bungler there is now a backdoor installed 
that lets him control the system no matter how many passwords you change. 
Your computer will be used for attacking other computers, churning out spam, 
or any number of other shady activities.

Install the latest version of CentOS and set it up to receive updates 
automatically. Do not transfer any kind of executable code from the old 
system to the new one.

Björn Persson

ssh2 -Thanks to everybody

[roland]

On Wed, 24 Sep 2008 21:39:50 +0200, Björn Persson <bjorn(a)xn--rombobjrn-67a.se&gt;  
wrote:

>  roland wrote:
> > This is an old version of redhat workstation, just before fedora was
> > released.
>
>  No wonder it was broken into then. Actually, if it hasn't been updated  
>  since
>  2003 it's something of a wonder if you haven't had any intrusions until  
>  now.
>  Perhaps the intruders who have been using the box before have been more
>  discreet so that you haven't noticed them.
>
> > I just wonder why this person/hacker is still trying to login with root
> > and other names. So he must have been unsuccessful the first time.
>
>  What makes you think it's the same person? There are bots on compromised
>  computers constantly scanning the Internet and trying to access any SSH
>  servers they find. It's been going on for years. Do you have proof that  
>  the
>  login attempts you see are something else?
>
> >  From what you are saying I can understand that I should reinstall the
> > server, even if he is not successfully login in again?
>
>  Yes you should. Once the system is compromised you can't trust anything  
>  in it.
>  Unless the intruder is a complete bungler there is now a backdoor  
>  installed
>  that lets him control the system no matter how many passwords you change.
>  Your computer will be used for attacking other computers, churning out  
>  spam,
>  or any number of other shady activities.
>
>  Install the latest version of CentOS and set it up to receive updates
>  automatically. Do not transfer any kind of executable code from the old
>  system to the new one.
>  
I THANK EVERYBODY FOR THIS EXTENSIVE HELP.
And I hope next time this person-attacker will wait until after my Holiday

Roland

Followup Re: ssh2 -Thanks to everybody

[bob smith]

roland wrote:
>  I THANK EVERYBODY FOR THIS EXTENSIVE HELP.
>  And I hope next time this person-attacker will wait until after my 
>  Holiday
>
>  Roland
>  
Thre are a number of bot machines and others that seem to be
brute force attacking systems. Has the attack set resumed after
your holiday?
bob

-- 
===============================================
Command Line Interface - the only way to feel like you control the computer.

Is there easier way to install CJK into Texlive

[Otgonbayar.A]

Dear all

I found following link while googling.

How to create Japanese language documents under GNU/Linux using LaTeX
http://www.physics.wustl.edu/~alford/tex/japanese_latex.html


But is there any easy way of installation on Fedora 10? Or I really need 
to follow all these steps manually?

Thank you.

Otgonbayar.A

Is there easier way to install CJK into Texlive

[Ed Greshko]

Otgonbayar.A wrote:
>  Thank you.
>  
I don't know the answer to your question.  However, I do know that you
hijacked a thread.  That is frowned upon since it breaks treading in
people's email clients. 

You are kindly requested to start a new message to the list instead of
replying to an existing message and changing the subject.

Thanks....