Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
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.
I'm not sure if I have a real problem, or if I've somehow mis-configured ssh. I have a Slackware server I use for my business, and a week ago it suddenly lost the ability to load, unload or list kernel modules. RKhunter showed nothing, but chkrootkit showed several hidden processes and suggested the LKM trojan. I checked into the hidden processes and they were all owned by MySQL (which does run on that server). AIDE was not showing any changes to the file system, let alone anything sinister. Since I do need this machine for work, I really didn't have time to do proper forensics, so I reformatted the system hard drive and reinstalled Slackware 10.2 from a trusted CD. A second hard drive is on the system and contains /home but no binaries and was not reformatted.
Since the re-install, I've had a very strange problem with SSH. SSH is configured to use SSH2 only, passkeys only (no usernames or passwords), root login is not allowed and there are two allowed users listed in AllowUsers. From within my LAN, everything is fine, however trying to access from outside my LAN, I get the error message that the server key has changed. If I delete the ~/.ssh/known_hosts file and then accept the "new" key, my passkey (which works on the LAN) is not accepted. Looking at the server keys, none of them (from either a LAN connection or a WAN connection) match /etc/ssh/ssh_host_rsa_key.pub. However, when connected to the LAN, I consistently get the same key in ~/.ssh/known_hosts. The server is behind a router, but the router is correctly set up to forward port 22 to the Slackware box and other services on the same box (http, https and ftp) seem to be working properly from both inside and outside the LAN.
Here is my sshd_config file:
Code:
# $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 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/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/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
Protocol 2
#AddressFamily any
#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 1h
#ServerKeyBits 768
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# 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
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
#Allowed users listed here
AllowUsers User1 User2
As far as I can tell, nothing evil is happening on this box or on the LAN. There are no unknown services listening and there don't appear to be any hidden processes (at least as far as rkhunter and chkrootkit can tell). AIDE has not detected any unkown changes to to file system since the re-install, although it doesn't monitor /home. Any thoughts on where to go with this would be greatly appreciated.
Could the box that should be port forwarding ssh be actually acepting it?
If you get differant keys depending on where you connect from then there is something wrong. Maybe someone is running SHARP or something like that. In the known hosts file there should be identical entries. If they differ it mean that you are getting connected to the wrong ssh server.
Check you auth.log server log for something related to the uudecode errors, because there was an issue with big key sizes a while ago, although I doubt this is the problem here.
Could the box that should be port forwarding ssh be actually acepting it?
OK, I win a Dope Slap. I've got a new router in front of the Slackware box and it has ssh capability and it was enabled. As soon as I turned that off, connections flowed right through. Thanks for thinking of that, I had completely missed it. Of course this also explains why I haven't seen any of the brute force ssh attacks on this box lately.
Quote:
What does passkeys mean in this context? Public key authentication?
Yeah, I got tired of all the pounding by the ssh script kiddies and figured that public key authentication was the best way to eliminate that threat.
Quote:
What does this mean? Is this a laptop that you access from within the LAN and from the outside world? Or is it two separate machines?
For what it is worth, it was both. I was using my laptop both in the LAN and outside and my business partners computer from the outside as well.
Yeah, I got tired of all the pounding by the ssh script kiddies and figured that public key authentication was the best way to eliminate that threat.
Good idea. There are other ways to harden this service further, but that's another topic.
At this point it seems to me that it would be worthwhile to try to generate a new private/public key pair for each of the clients that are having trouble, and then re-setup the public key authentication. This should be easy enough to test with your own laptop to see if it corrects the problem.
Thanks for the suggestion, but turning off the SSH server on the router did the trick. The server keys are correct and the existing client keys are now accepted. I've heard that Linksys routers now run Linux, and mine (an RTP300) definitely has an SSH server. From what I can tell router's SSH server is always listening on the LAN side, but on the WAN side there is a configuration option on the router. I had been messing around with it and apparently forgot to turn it off. From the behavior, it appears that the router's SSH server takes precedence over forwarding port 22. Once I turned off the option, port 22 was forwarded to the Slackware server as it should.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.