• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 86
  • Last Modified:

SSH to linux system is failing

We have a vendor who has put his linux based appliance behind a firewall. If I ssh to the system from the same subnet as the linux appliance ssh succeed - giving me a login prompt and then succeeding with authentication. If I login to the linux appliance from the Outside of the firewall the conversation succeeds apparently - I get a login prompt. But when I enter the same credentials the connection is promptly terminated. If I look at the firewall I see only the allowed SSH session and no other denies to the server.
Any idea what might be going on? What logging could be looked at on the linux appliance to give us insight as to why the ssh connection is failing in the second case? Thank you
2 Solutions
The issue might be a restriction on the account you are using that only allows the connection when you are on the internal network and denies the setup of the connection when external.

Consult with the vendor whether external connection to the appliance are authorized?
Check the routing table (netstat -rn) when logged into the appliance locally.

Does your location has DUAL wans two paths to the outside?
create a new standard/limited user, and see if it can login from the outside.
Dr. KlahnPrincipal Software EngineerCommented:
sudo grep -i ssh /var/log/*

This will let you know if the ssh daemon is logging any messages.

I have found it useful to log all ssh messages to one file using an rsyslog rule in /etc/rsyslog.conf.  (This only works with rsyslog.)

# Log ssh into its own file
if $programname == 'sshd' then {
  if $msg contains 'session opened' then stop
  if $msg contains 'session closed' then stop
  action(type="omfile" file="/var/log/ssh")

Open in new window

Oct 17 00:17:48  sshd[27732]:  pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=  user=hostile_hacker
Oct 17 00:19:50  sshd[27732]:  Failed password for kb11cm from port 1597 ssh2
Oct 17 00:37:53  sshd[27732]:  Accepted password for kd11ea from port 1597 ssh2
Oct 17 20:09:53  sshd[8383]:  Accepted password for kb11cm from port 1126 ssh2
Oct 18 01:16:14  sshd[29439]:  Accepted password for vs60 from port 1077 ssh2
Oct 18 17:33:46  sshd[5000]:  Accepted password for kb11cm from port 1105 ssh2
Oct 18 22:24:20  sshd[982]:  Received signal 15; terminating.
Jan  1 00:00:28  sshd[983]:  Server listening on port 22.
Oct 18 23:29:42  sshd[13939]:  Accepted password for dectalk from port 2593 ssh2

Open in new window

David FavorLinux/LXD/WordPress/Hosting SavantCommented:
As arnold suggested, best open a ticket with the vendor of this device/service + debug this issue with them.

On trick you can use is ssh -vvv, then compare the output of the working + failing ssh connection.

This may give you clues too.

My guess is there's some sort of device (load balancer maybe) or firewall rule, that's munging ssh connections from outside, because the rule is slightly broken.

And the vendor will still have to fix this.
amigan_99Network EngineerAuthor Commented:
Thank you both very much. It turned out the appliance was running a version of ssh that the client machine was not matching

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now