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 |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
08-01-2003, 07:39 PM
|
#16
|
Member
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446
Rep:
|
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 ...
|
|
|
08-01-2003, 08:04 PM
|
#17
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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.
|
|
|
08-01-2003, 08:25 PM
|
#18
|
Member
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446
Rep:
|
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
#
#*****************************************************************************#
|
|
|
08-01-2003, 11:13 PM
|
#19
|
Member
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446
Rep:
|
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.
|
|
|
08-03-2003, 09:08 PM
|
#20
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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!!
|
|
|
08-05-2003, 01:51 PM
|
#21
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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¨.
|
|
|
08-05-2003, 01:56 PM
|
#22
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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?
|
|
|
08-05-2003, 01:58 PM
|
#23
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
/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
|
|
|
08-05-2003, 02:00 PM
|
#24
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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
|
|
|
08-05-2003, 07:55 PM
|
#25
|
Member
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446
Rep:
|
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.
|
|
|
08-06-2003, 11:11 AM
|
#26
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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
|
|
|
08-06-2003, 04:52 PM
|
#27
|
Member
Registered: Jul 2003
Location: Jette, Brussels Hoofstedelijk Gewest
Distribution: Debian sid, RedHat 9, Suse 8.2
Posts: 446
Rep:
|
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.
|
|
|
08-06-2003, 05:45 PM
|
#28
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
I've shut down snort and tried again. Didn't work. I went and removed the ALL:ALL  ENY 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...
|
|
|
08-06-2003, 05:48 PM
|
#29
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
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.
|
|
|
08-06-2003, 06:03 PM
|
#30
|
Member
Registered: Jul 2003
Location: Toronto, ON
Distribution: Mandrake 9.1
Posts: 41
Rep:
|
update: I just lost access to sshd again ... it seems that ALL:ALL  ENY 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:ALL  ENY
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.
|
|
|
All times are GMT -5. The time now is 07:39 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|