LinuxQuestions.org
Help answer threads with 0 replies.
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 08-01-2003, 07:39 PM   #16
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31

Yup, sorry that was a typo, ssh-keygen -t dsa (not just ssh -t dsa).

To reiterate what I said above though, ssh does not to the best of my knowledge use TCP wrappers so the presence or not of the sshd line in the hosts.allow file is irrelevant and unecessary.

IMHO, hosts.allow and hosts.deny is a complete red herring in this problem.

Even if you are just using SSH1, you still add the generated key to the authorized keys on the host to which you are trying to ssh into.

So now we must check the sshd configuration file on the machine into which you are trying to ssh into.

/etc/ssh/sshd_config

Because on my little network, it is linux to linux, I just use the most secure
dsa method and so have a line

Protocol 2

but in your case you want to do SSH1 with rsa1 key, so you need a line to enable both

Protocol 2,1

or just

Protocol 1

if you really insist on just using rsa1, the least secure.

So if you have not already checked, can you check this one?

Let's do this step by step ...
 
Old 08-01-2003, 08:04 PM   #17
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
Ouch, ok. The terminal is at the office, and I won't be back there until Monday

I'll check then and reply, but I'm 100% positive that sshd on the terminal accepts both SSH1 and SSH2, so I have "Protocol 1,2"

As for hosts.deny -- the reason that I point in its direction is because when I clear out the line, everything works. It could be, of course, because I simply leave the machine open for all connections (which isn't actually the case, because it's connected through a hub/router, which only opens ports 80,21, and 22). I think you're right, though, hosts.deny shouldn't be important if it's not used by sshd.

When it comes to security, I would, of course, prefer the highest setting, but I thought that SSH1 would be a lot easier to figure out than SSH2. Seeing as how this is not really the case, I'll go with SSH2, as I would move towards higher security eventually anyway.

I'll post again on Monday when I'll be in the office.

Thanks again for walking me through this.

Last edited by troworld; 08-01-2003 at 08:05 PM.
 
Old 08-01-2003, 08:25 PM   #18
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
As well as checking your Protocols line, can you please, please, please have a look in /var/log/auth.log for lines corresponding to sshd e.g.

grep -i sshd /var/log/auth.log

to see something like this

auth.log:Aug 1 18:25:35 koala sshd(pam_unix)[4506]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=koala.wsl.com user=tester
auth.log:Aug 1 18:25:46 koala sshd[4506]: Failed password for tester from 192.168.1.2 port 35356 ssh2
auth.log:Aug 1 18:25:46 koala sshd(pam_unix)[4506]: 1 more authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=koala.wsl.com user=tester
auth.log:Aug 1 18:28:37 koala sshd(pam_unix)[4513]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=wolverine.wsl.com user=tester
auth.log:Aug 1 18:30:38 koala sshd(pam_unix)[4525]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=wolverine.wsl.com user=tester
auth.log:Aug 1 18:32:36 koala sshd(pam_unix)[4579]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=wolverine.wsl.com user=root
auth.log:Aug 1 20:08:34 koala sshd[944]: Received signal 15; terminating.

If the problem is not the protocols line, then there could be a problem with your pam.d setup. You should have a file /etc/pam.d/sshd with entries like

#%PAM-1.0
#
#*****************************************************************************#
#
# file : /etc/pamd.d/sshd
#
#*---------------------------------------------------------------------------*#
#
account required pam_stack.so service=system-auth
#
auth required pam_nologin.so
auth required pam_stack.so service=system-auth
#
password required pam_stack.so service=system-auth
#
session required pam_limits.so
session required pam_stack.so service=system-auth
session optional pam_console.so
#
#*****************************************************************************#
 
Old 08-01-2003, 11:13 PM   #19
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
Something important to check which I forgot and which another posting
in another thread mentioned.

Make sure that in /etc/ssh you have generated keys for the SERVER for all
three types of session. The /etc/init.d/ssh script may only have generated one type.

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""

and you need matching entries for each

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

in the /etc/ssh/sshd_config file.
 
Old 08-03-2003, 09:08 PM   #20
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
It seems that all of this will have to wait till Tuesday. I just remembered that Monday is Civic holiday.

I'll try all of the above on Tuesday.

Thanks!!
 
Old 08-05-2003, 01:51 PM   #21
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
sshd_config file :

# $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 120
#PermitRootLogin yes
#StrictModes yes

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt no

X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
PermitRootLogin no


Just a note: Above ^^^ PermitRootLogin. No matter how many times I set it to ¨yes¨, it resets itself to ¨no¨.
 
Old 08-05-2003, 01:56 PM   #22
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
Here´s something from my /var/log/auth.log.

Aug 5 13:54:00 localhost last message repeated 8 times
Aug 5 13:54:01 localhost last message repeated 3 times
Aug 5 13:54:15 localhost sshd[2978]: Server listening on 0.0.0.0 port 22.
Aug 5 13:54:25 localhost snort: [1:1917:3] SCAN UPNP service discover attempt [Classification: Detection of a Network Scan] [Priority: 3]: {UDP} 192.168.0.140:1904 -> 192.168.0.1:1900
Aug 5 13:54:26 localhost last message repeated 3 times
Aug 5 13:54:28 localhost sshd[2991]: refused connect from 127.0.0.1 (127.0.0.1)
Aug 5 13:54:50 localhost snort: [1:1917:3] SCAN UPNP service discover attempt [Classification: Detection of a Network Scan] [Priority: 3]: {UDP} 192.168.0.140:1904 -> 192.168.0.1:1900

Do you think snort is blocking the ssh connection?
 
Old 08-05-2003, 01:58 PM   #23
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
/etc/pam.d/sshd file:


#%PAM-1.0
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_limits.so
session optional /lib/security/pam_console.so
 
Old 08-05-2003, 02:00 PM   #24
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
I believe that the server keys are in order:

# Some functions to make the below more readable
KEYGEN=/usr/bin/ssh-keygen
SSHD=/usr/sbin/sshd
RSA1_KEY=/etc/ssh/ssh_host_key
RSA_KEY=/etc/ssh/ssh_host_rsa_key
DSA_KEY=/etc/ssh/ssh_host_dsa_key
PID_FILE=/var/run/sshd.pid
 
Old 08-05-2003, 07:55 PM   #25
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
I hope you had an enjoyable Civic Holiday and did obeisance to Ernie for the privilege of a day of not working. ;+}

Quote:
Originally posted by troworld
Aug 5 13:54:25 localhost snort: [1:1917:3] SCAN UPNP service discover attempt [Classification: Detection of a Network Scan] [Priority: 3]: {UDP} 192.168.0.140:1904 -> 192.168.0.1:1900
A simple question, is the host 192.168.0.140, the host from where you were trying to slogin in to 192.168.0.1 ?

Quote:
Do you think snort is blocking the ssh connection?
I am not familiar with snort, but it would appear that this is possible.

Your config files sshd_config and pam look fine, and so long as you actually have the RSA1 key files present, then all should be working.

But from your repeated statements that things keep getting changed, it is evident that you have something running on your machine which is keeping a very tight grip on the security of your machine.

My understanding is that snort is just a monitor, so you will have to see what other security software is installed on the machine. Did you install everything on it yourself?

Last edited by Corin; 08-05-2003 at 07:56 PM.
 
Old 08-06-2003, 11:11 AM   #26
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
Quote:
Originally posted by Corin
I hope you had an enjoyable Civic Holiday and did obeisance to Ernie for the privilege of a day of not working. ;+}
Hehe ... 'course

Quote:
A simple question, is the host 192.168.0.140, the host from where you were trying to slogin in to 192.168.0.1 ?
Yes.

Quote:
My understanding is that snort is just a monitor, so you will have to see what other security software is installed on the machine. Did you install everything on it yourself? [/B]
I used the rpm's that came with the distro.

There were quite a few messages from snort during the night while I wasn't in the office, but I guess I'll just make a new thread about that.

Thanks!
Dmitri
 
Old 08-06-2003, 04:52 PM   #27
Corin
Member
 
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446

Rep: Reputation: 31
Would it be at all possible to shutdown snort and do a test?

Of course you would have to close down any external InterNet
connetcion whilst doint this if you are relying on snort as a protection,
which actually is not adequate by its-self.
 
Old 08-06-2003, 05:45 PM   #28
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
I've shut down snort and tried again. Didn't work. I went and removed the ALL:ALLENY line from hosts.deny and added sshd: *.*.*.* to hosts.allow and it connected.

Also, I set my config file to allow root login. It's been half and hour at least and the hosts* files haven't been changed, so I'm assuming it was snort that was changing the files ...

I set SecureCRT to use SSH2. SecureCRT was also trying to first connect using the private/public key and then the password. The keypair was denied, although I added the public key to both authorized_files and identity.pub in /root/.ssh/. I set SecureCRT, then, to use a password first, and then the public key. It's asking me for password now and I'm able to login using that ...

I'm wondering, though, whether sshd is using public key encryption at all right now...
 
Old 08-06-2003, 05:48 PM   #29
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
Forgot to mention that I'm using a 2048bit DSA key ...

debug1: identity file /root/.ssh/id_dsa type -1

the above line seems to suggest that sshd has a DSA key.
 
Old 08-06-2003, 06:03 PM   #30
troworld
Member
 
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41

Rep: Reputation: 15
update: I just lost access to sshd again ... it seems that ALL:ALLENY has been appended again to the hosts.deny file.

So, it´s not snort that´s doing this.
I think snort is just a detection program .. it doesn´t really take any action against intrusions.

Here´s what´s doing this. This is a piece of my auth.log file:

Aug 6 18:01:01 localhost msec: appended in /etc/hosts.deny the line:
Aug 6 18:01:01 localhost msec: ALL:ALLENY
Aug 6 18:01:01 localhost msec: replaced in /etc/ssh/sshd_config the line 93:
Aug 6 18:01:01 localhost msec: PermitRootLogin yes
Aug 6 18:01:01 localhost msec: with the line:
Aug 6 18:01:01 localhost msec: PermitRootLogin no
Aug 6 18:01:01 localhost msec: /etc/ssh/sshd_config modified so launched command: [ -f /var/lock/subsys/sshd ] && /etc/rc.d/init.d/sshd restart
Aug 6 18:01:01 localhost sshd[9774]: Received signal 15; terminating.
Aug 6 18:01:01 localhost msec: Stopping sshd:^[[65G[^[[1;32m OK ^[[0;39m]^M
Aug 6 18:01:01 localhost msec: Starting sshd:^[[65G[^[[1;32m OK ^[[0;39m]^M
Aug 6 18:01:01 localhost sshd[10923]: Server listening on 0.0.0.0 port 22.
Aug 6 18:01:17 localhost sshd[10963]: warning: /etc/hosts.allow, line 6: missing newline or line too long
Aug 6 18:01:17 localhost sshd[10963]: refused connect from 127.0.0.1 (127.0.0.1)
Aug 6 18:01:27 localhost sshd[10965]: warning: /etc/hosts.allow, line 6: missing newline or line too long
Aug 6 18:01:27 localhost sshd[10965]: refused connect from 127.0.0.1 (127.0.0.1)

what´s msec?

Last edited by troworld; 08-06-2003 at 06:10 PM.
 
  


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 02:55 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