LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 01-13-2003, 08:28 PM   #1
ocularbob
Member
 
Registered: Nov 2002
Location: brooklyn NYC
Distribution: gentoo
Posts: 212

Rep: Reputation: 30
ssh problem


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
 
Old 01-13-2003, 09:06 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Check your sshd log for "refused connect from" then check /etc/hosts.(deny,allow) for the IP/range.
 
Old 07-29-2003, 11:40 AM   #3
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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!
 
Old 07-29-2003, 11:43 AM   #4
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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
 
Old 07-29-2003, 09:23 PM   #5
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
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
#
#*****************************************************************************#

Last edited by Corin; 07-29-2003 at 09:24 PM.
 
Old 07-29-2003, 11:49 PM   #6
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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 ...
 
Old 07-30-2003, 10:45 AM   #7
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
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.

Last edited by Corin; 07-30-2003 at 10:47 AM.
 
Old 07-30-2003, 12:50 PM   #8
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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.
 
Old 07-31-2003, 09:36 AM   #9
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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.
 
Old 07-31-2003, 03:27 PM   #10
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
Quote:
Originally posted by troworld
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?
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.

Last edited by Corin; 07-31-2003 at 03:31 PM.
 
Old 07-31-2003, 03:45 PM   #11
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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.
 
Old 07-31-2003, 10:40 PM   #12
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
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?
 
Old 08-01-2003, 09:18 AM   #13
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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 ...
 
Old 08-01-2003, 12:55 PM   #14
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
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!
 
Old 08-01-2003, 02:27 PM   #15
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh-agent, ssh-add and ssh-keygen AND CVS raylpc Linux - General 2 11-19-2008 03:50 AM
ssh problem Mystified Linux - Networking 5 01-23-2005 07:17 PM
problem with ssh ito Linux - Networking 6 08-25-2003 05:21 PM
ssh problem juanb Linux - Security 6 08-21-2003 03:58 PM
ssh and X problem mazzo Linux - Networking 7 08-14-2003 12:59 PM


All times are GMT -5. The time now is 10:11 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration