I have a new machine on the network running MDK9.
When i try to shh into it with:
#ssh -l root 192.168.1.8

i get:
1518: ssh_exchange_identification: Connection closed by remote host


any idea what is causing this. In the past ssh is the one thing that always worked perfectly. Port 22 is open on both sides and sshd is running on both sides.

thanks

Check your sshd log for "refused connect from" then check /etc/hosts.(deny,allow) for the IP/range.

Hi!

Experienced a similar problem with sshd on Mandrake 9.1. My hosts.deny file was All:Alleny. Removing that allowed me to connect to sshd.

However, this is what I get upon connection:

´[root@localhost dmitri]# ssh -v root@localhost
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.5p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'localhost' is known and matches the RSA1 host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Doing challenge response authentication.
debug1: No challenge.
debug1: Doing password authentication.
root@localhost's password:´

after I login:
´debug1: Requesting pty.
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x8066a60(0x0´

Logging in from other users works, though.

Is it possible that I´m disallowing root´s login? Where can I check, if yes?

Thanks!

Just found out the answer to my own problem ... kinda ...

I used webmin to allow root login. However, I´d still like to know how to do that from command line ...

thanks

DANGER, DANGER, WILL ROBINSON!


Always keep



#*****************************************************************************#
#
# file: /etc/hosts.deny
#
#*---------------------------------------------------------------------------*#
#
ALL: ALL
portmap: ALL
#
#*****************************************************************************#



If you remove these entries, it means that the default for your machine is WIDE OPEN. The portmap line is paranoia redundancy.


What you do is add entries to /etc/hosts.allow, for example


#*****************************************************************************#
#
# file: /etc/hosts.allow
#
#*---------------------------------------------------------------------------*#
#
ALL: 127.0.0.1 192.168.1.0/255.255.255.0
#
gdm: 127.0.0.1 192.168.1.0/255.255.255.0
portmap: 127.0.0.1 192.168.1.0/255.255.255.0
sendmail: 127.0.0.1 192.168.1.0/255.255.255.0
#
#*****************************************************************************#

Thanks. I'm, as you probably noticed, a newbie.

Umm .. no matter what I do, the line "All:Alleny" seems to reappear in my hosts.deny file. I'm guessing that's a precaution of some sort ...

Troworld, hey we all start out as newbies.

But remember, forewarned is forearmed! :+)

It is possible, as you are using webmin, that webmin ensures safety by
keeping the ALL:ALL line in the hosts.deny file.

That's possible, as my security level for Mandrake is Paranoid.

I hope it's not a bug of any sort, but now that I don't have SSH access from home, I'll have to wait till tomorrow to check

Thanks for replying.

Thanks again, Corin.

Now that I can access the machine as well, I´m having difficulties allowing access through ssh at all. I tried to add the lines in your example to my hosts.allow file, but to no avail.

Is it possible that sshd reads the hosts.allow file first and hosts.deny file last?

Thanks.

No the way it works is that the TCP wrappers facility sees the ALL:ALL in the hosts.deny file and uses that as the default setting. If the a host then tries to make a connection and it does not find a matching entry in the hosts.allow, then it denies access by default.

My apologies for not adding a necessary addendum to the example I posted above for the hosts.allow.

You must change the 192.168.1.0/255.255.255.0 as appropriate to your network or a list of the hosts you want to allow access.

So if you local network does not have the IP address of 192.168.1.0 you must change the entry to whatever is appropriate.

So first of all decide if you want all machines on your local net to be given access or just certain individuals.

Note that for the portmapper line (which is needed for NFS connections) you must use IP addresses and not hostnames. So to be consistent I use IP addresses throughout.

You should check in the file /var/log/auth.log for sshd entries to see if there are any messages about connections.

Without you specifying the actual symptom of the problem of connecting using ssh I can only speculate and not be very helpful.

Ah. .. I see. Well, I´m not always using the same computer to access my office terminal using ssh. I move around a lot, so I need sshd to accept ssh connections from all possible ip addresses.

The following is the verbose response of ssh when I try to connect:

[root@localhost dmitri]# ssh -v root@localhost
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x8066a60(0x0)

Also, maybe this is a security precaution of some sort, but my hosts.deny file is constantly being rewritten by some process to include the following line:

ALL:ALLENY

Even when I add the ALL:ALL line myself, it adds ALL:ALLENY.

Sorry.

Well now that we have established that you have you /etc/hosts.allow and /etc/hosts.deny files in a secure state, there is something we should tell you.

The security control with these files is only used by applications which have had TCPD support built in and when the application is called within a call to execute TCPD, the xinetd way of doing it being,
in eg /etc/xinetd.d/telnet,

service telnet
{
scoket_type = stream
protocol = tcp
flags = NAMEINARGS
wait = no
user = root
server = /usr/libexec/tcpd
server_args = /usr/libexec/telnetd
}

Now you are ussing (along with everybody else) sshd as a standalone daemon, so this is all academic, since in that mode sshd will allow connections from anywhere.

So the question is why is your ssh session failing as you have indicated in the log above.

First of all have you generated your SSH keys?

Hi!

I believe that the keys were generated when I started the daemon for the first time and I haven´t changed the keys since then. When I removed the ALL:ALL line in hosts.deny a few posts ago, I was able to successfully connect to to sshd, so I´m guessing the keys are in order ...

Nooooooooooooooooo!

You are missing the big picture.

The keys generated when you fire up /etc/init.d/sshd are for the server identification not for user authentication.

On the host FROM where you want to ssh, do the following:

ssh -t dsa

and enter a passphrase known only to yourself. This can be truly a phrase, several words with spaces, and not just a password.

This will then create in the directory $HOME/.ssh two file id_dsa and id_dsa.pub

The file id_dsa is the one you need to secure and never share, chmod 600, or even chmod 400.

Now on the host TO where you want to ssh, do the following.

If it does not exist, then

mkdir -p $HOME/.ssh

Then create/editr a file $HOME/.ssh/authorized_keys and append the entry from id_dsa.pub FROM the host where you want to ssh FROM.

This file can contain multiple entries of all the different hosts FROM where you want to ssh FROM to this host.

This file obviously needs to be secure, chmod 600, or even chmod 400 (until you want to add more entries to it).

Going back now to the other host FROM where you want to ssh, try

slogin remote_host

(assuming the user is the same on each machine)

otherwise

slogin -l user_on_remote_host remote_host

It will now probably complain about not knowing the remote host. Just accept the entry.

Now you enter the passphrase that you originally chose.

In order to avoid having to enter the passphrase everytime, you can, if you are doing this in an X11 windows session, start you Xsession as a child of an ssh-agent process and run

gnome-ssh-askpass

or

x11-ssh-askpass

according to your preference (and availability on the system).

Within a virtual console window, or an xterm you can do

eval `ssh-agent -s`

ssh-add ${HOME}/.ssh/id_dsa

----------------------------------------------------------------------------

So in summary -

1) on the machine you want to ssh FROM, generate a set of keys

2) then add the contents of the generated FROM id_dsa.pub to the authorized_keys on the remote machine to which you want to ssh TO

Hope this helps to get you on your secure slogin and scp way!

ssh -t dsa command didn´t work .. this is what I got :

[root@localhost dmitri]# ssh -t dsa
ssh: dsa: Name or service not known

I believe that on my machine the correct command would be ssh-keygen -t dsa

However, I will be accessing the terminal from a windows machine. I´m using SecureCRT for that. It has its own keypair generator, which I used successfully to create one for myself. I did as you said, creating the authorized_keys file and appending the contents of Identity.pub to that file.

I was still not able to connect with the same kind of error as before.
ALL:ALLENY reappeared in hosts.deny, while hosts.allow had the following: sshd: *.*.*.* (I think this is what I needed to do to allow connections from all ip´s)

I must note that I will only be needing SSH1 to access my terminal. Although I´m very new at this, I believe that for SSH1, a password is all that´s required. I didn´t have any keys before and was able to access the terminal from my Windows machine by simply using a password. Because I had to clear my hosts.deny file before being able to ssh into my terminal successfully, I believe that´s where the problem lies. I could be wrong, of course.

Your instructions on generating a keypair were very helpful, though. I may need to use SSH2 sometime in the future, but I need to figure out SSH1 right now.