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
On Tue, Sep 16, 2008 at 2:30 AM, roland roland@cat.be 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
On Tue, 16 Sep 2008 18:11:05 +0200, Aldo Foot lunixer@gmail.com wrote:
On Tue, Sep 16, 2008 at 2:30 AM, roland roland@cat.be 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
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
On Tue, 16 Sep 2008 18:48:22 +0200 roland roland@cat.be 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.
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?
roland wrote:
On Tue, 16 Sep 2008 18:11:05 +0200, Aldo Foot lunixer@gmail.com wrote:
On Tue, Sep 16, 2008 at 2:30 AM, roland roland@cat.be 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
On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch niftyfedora@niftyegg.com 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
roland wrote:
On Tue, 16 Sep 2008 22:19:51 +0200, Nifty Fedora Mitch niftyfedora@niftyegg.com 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
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@niftyegg.com 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.
On Thu, 18 Sep 2008 00:30:17 +0200, Nifty Fedora Mitch niftyfedora@niftyegg.com 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@niftyegg.com 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.pubWhen 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_hostsIf 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.pubThese 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 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.
On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen davidsen@tmr.com 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
On Sat, 20 Sep 2008 08:27:49 +0200, roland roland@cat.be wrote:
On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen davidsen@tmr.com 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
roland wrote:
On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen davidsen@tmr.com 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
roland wrote:
On Sat, 20 Sep 2008 08:27:49 +0200, roland roland@cat.be wrote:
On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen davidsen@tmr.com 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
On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen davidsen@tmr.com wrote:
roland wrote:
On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen davidsen@tmr.com 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
roland wrote:
On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen davidsen@tmr.com 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.
On Mon, 22 Sep 2008 15:47:26 +0200, Bill Davidsen davidsen@tmr.com wrote:
roland wrote:
On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen davidsen@tmr.com 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
On Wed, Sep 24, 2008 at 12:04 AM, roland roland@cat.be 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
On Wed, 24 Sep 2008 18:12:24 +0200, Aldo Foot lunixer@gmail.com wrote:
On Wed, Sep 24, 2008 at 12:04 AM, roland roland@cat.be 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
On Wed, Sep 24, 2008 at 11:00 AM, roland roland@cat.be 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
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
On Wed, 24 Sep 2008 21:39:50 +0200, Björn Persson <bjorn@rombobjörn.se> 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
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
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
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....
-
Aldo Foot -
Bill Davidsen -
Björn Persson -
bob smith -
Ed Greshko -
Frank Cox -
Nifty Fedora Mitch -
Otgonbayar.A -
roland