Linux - SoftwareThis 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.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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?
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.
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,
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.
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 ...
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.