ssh problems through a firewall

[robsterooni]

Hi,

New here, so.... hiya people!

I am having trouble logging into my server from my computer at work (runinng linux and XP, behind a firewall with no proxies). I get the error message "Authentication failed..... blah blah.. Connection closed by remote host".

I have successfully logged in from my computer at home (DSL connection) so I know that I have set up SSH secure shell (in winXP) correctly and that my server is running OK.

I have done a little research on this and I believe the problem is that sshd cannot do a reverse DNS lookup on my computer at work, so it kicks me off because it does not trust me. Is this correct? If so, what should I try next? Can sshd be configured to allow connections from certain IP addresses without the reverse DNS verification?

I am new to ssh so I don't want to mess around with it for fear of locking myself out or opening security holes.

Hope you can help,

Rob Sterooni

[dingman]

VerifyReverseMapping no

That's the default, so if you don't find 'VerifyReverseMapping yes' in your sshd_config file it's not the problem. In that case, try sending us the '..... blah blah.. ' part ;)

[robsterooni]

Thanks for your reply,

I did not find 'VerifyReverseMapping yes' in my ssh_config. :( There was a '#VerifyReverseMapping no' in there, so I uncommented it just incase. Unfortunately I am not at work now so I can't check to see if it works or not. Is it safe to Disable Reverse Mapping verification or have I just got "new web server" paranoia?

The original error message (the "blah blah" thing ;) ) was :-

ssh exchange identification: Connection closed by remote host

I can do a "ssh -vvv" when I get to work on moday but as far as I can remember there was nothing much else to go on.

Thanks a lot for your help!

Rob Sterooni

[dingman]

Is it safe to Disable Reverse Mapping verification or have I just got "new web server" paranoia?

Paranoia is healthy :) As it happens, reverse mapping verification is really not all that valuble for security, and SSH has *much* better authentication mechanisms. If you are foolish enough to rely on IP address of the client as your sole authentication mechanism, checking reverse mapping might add a day or two before you got rooted. Maybe. Really it's more of a prejudice against people whose ISP can't configure a DNS server than anything.

BTW, it is well worth carying a known good copy of your server's public key with you, or at least the key fingerprint. After all, if you saw this:

me@work-machine:~ $ ssh -l andrew my-domain.tld
The authenticity of host 'my-domain.tld (127.0.0.1)' can't be established.
RSA key fingerprint is 1d:b6:3c:66:a9:ee:6d:c1:a1:9c:fd:1f:ef:c6:9b:1d.
Are you sure you want to continue connecting (yes/no)?

would you know off the top of your head whether it was safe to connect and type your password or doing so would hand the password to an attacker? I got burned by that once, and lost a machine for months until I could get to the datacenter to recover it. (Luckily, even though I was away for the summer, I had someone on-site who could at least power down the machine, so the cracker only got it for as long as it took me to make a phone call.) Learn from my mistake, not your own.

[dingman]

Oh, and it could be the firewall. I remember one of my former places of employment simply couldn't manage to get a hole punched in Raptor that would let an SSH connection complete. I think I ended up using encrypted telnet sessions to get around that, because the firewall knew what telnet was, and we had to have it open for other reasons.

[robsterooni]

OK, I'll keep the paranoia... might come in handy.

Didn't know about keeping a copy of the servers public key - will look into doing that, thanks! Also, I have heard of chkrootkit (or similar) and am looking into doing that too. Did the "VerifyReverseMapping no" on the weekend - still doesn't work though. I guess the firewall (on the client end) is to blame, although the engineer in control assures me that port 22 is open.

You say you used an encrytped telnet session, is this safe? easy to set up? Thanks for your help dingman, appreciate it. This is my ssh -vvv :-

$ ssh -vvv 69.69.69.69 :-

OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to 69.69.69.69 [69.69.69.69] port 22.
debug1: Connection established.
debug1: identity file /home/robin/.ssh/identity type -1
debug3: Not a RSA1 key file /home/rob/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/robin/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/rob/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/robin/.ssh/id_dsa type 2
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x8065240(0x0)

[dingman]

Do you know what kinds of authentication your server is configured to accept? That looks to me like the server decided it didn't like your private key.

As for encrypted telnet, it wasn't all that hard to set up because at the time there was a pre-packed setup for it available for Debian systems. It's less common than it used to be, because SSH is better. Both provide encryption of the connection, but SSH provides better authentication mechanisms. With SSH and a propperly set-up 'known hosts' file, you can be certain that you are logged into the machine you meant to log in to. (Well, either that or someone managed to steal a copy of your server's secret key file.) With encrypted telnet, as far as I know nobody ever developed that facility, though it's certainly possible in theory.

[robsterooni]

No, I don't know what kinds of authentication my server is configured to accept. The pain in the arse is that I can't find out until I get home because I can't log in here! ahhhh!

What kinds of autentication are safe? I have had a look at my work machine's sshd_config (just to see what sort of options I will have on my web server) and found things like RhostsAuthentication, RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication. RhostsRSAAuthentication appeals to my paranoia because it has RSA in it,... am I close? I would like to enable some more authentication modes on my server tonight and test them out tomorrow.

Cheers!

Rob Sterooni

[dingman]

manual page for the sshd configuration file. [openbsd.org]

If you don't know what Kerberos is, you deffinitely don't need it. Unless you are managing several machines with a shared authentication system, you wouldn't have a use for it. (I think. I'm not absolutely certain I know how it works.)

Which kinds of authentication you want depend in part on what you want to do, and in part on security. Deffinitely, if you want to use host-based authentication, RHostsRSAAuthentication is better than RHostsAuthentication. There are a lot of issues here, though.

First, RHostsRSAAuthentication and RHostsAuthentication are both only applicable to SSH protocol version 1. Protocol version 1 was found to have grave security bugs, and there are known to be exploits for those bugs "in the wild". For that reason, I simply don't allow protocol 1 connections to my machines at all. This is set by using the 'Protocol' option in the configuration file.

For host-based authentication in protocol 2, you would use the 'HostbasedAuthentication' option. The reason it doesn't mention RSA in the option name is that protocol 2 can use either RSA or DSA public-key algorithms. I have a bias against RSA when I can avoid it that arises from a now-expired patent, so I in fact use DSA most of the time, but it makes little difference anymore.

Host-based authentication basically means that if you are connecting from particular machines and claim to be a certain user, then SSH will believe you and just let you in. With protocol 2 and the HostbasedAuthentication option, or protocol 1 and the RhostsRSAAuthentication option, the machine you are connecting from will be verified not only by IP address, which is easy to spoof, but also by public-key authentication with that machine's host key. For that to work, the machine you are connecting to needs to have a copy of the public 'host key' of the machine you are connecting from. I'd only use this method if there are certain machines you want to connect from where you are absolutely certain that you can make a file only you will ever be able to read. It would be an extremely bad idea to set it up for connections from, say, an internet cafe or a public computer lab.

You can also authenticate using a public-private key pair that coresponds to your user. By placing a copy of your public key in a certain file on the server, you can then connect without a password as a particular user from any computer on which you have a copy of the secret key available. Again, there's an issue of trust in the machine you connect from. If someone else can copy that private key file, then they have the same access you do.

Finally, you can authenticate by password. The client will still confirm that the server is who it says it is, using the server's host key, but the user will be authenticated by password, sent over the encrypted chanel between machines. At this point, you don't have to worry about the next person to use the machine coming along and making a copy of your private key. However, someone who was there before could theoretically have installed a keystroke logger, and use that to get your password.

Despite all my warnings about how people could still get access to your machine when you are using SSH, it's worth noting that this is still far safer than not using it. The real weak point when things are propperly set up is the client machine (the one you are connecting from). Ideally, you could even off-load that part into a smart card so that the private key itself never got transferred to the client machine, but I don't know if this has been done for any ssh client programs yet.

The other way I can think of to eliminate the danger of usign a compromised client would be to use a one-time password system on the server, so that even sniffing the password would be of no use, since it wouldn't work a second time. That has been implemented, but I haven't set it up myself.

[amoore]

It almost looks to me like your " /home/rob/.ssh/id_rsa" (your RSA key) file is not what it should be, or at least that ssh is having a hard time parsing it. Those error messages seem to indicate that it doesn't look like it should. Did you copy that file from another machine? You can make yourself a new RSA key file with ssh-keygen.

[dingman]

I got exactly the same messages about the key files making a successful password-authenticated connection to my own machines. That's why I wondered about what his authentication setup was. After all, the client *should* fall back on password auth if the server will allow it.

[amoore]

oh, well perhaps it's an incompatibilty between ssh1 and ssh2. Of course, I can't tell what the server accepts because the poster has presumably replaced his IP address with a different, but valid one. Well, good luck!

[robsterooni]

whoah, thanks for the detailed explanation dingman! That clears up loads for me. :)

'HostbasedAuthentication' was disabled on sshd. I enabled it and appended my public key (created using ssh-keygen on the client machine) to ~/.ssh/known_hosts. amoore : I initially thought there was something wrong with my keys when I started on this nightmare journey, but after some digging I found some information saying it was just ssh being overly verbose and slightly misleading when reading the key files. Don't know how true this is.

I will try logging on again when I get to work tomorrow. Having checked my "SSH Secure Shell Client" configuration (I use Windows XP at home) I found that I connect from my home machine using password authentication. So password auth is enabled on the server; the sshd_config confirms this.

I hope the Hostbased auth works, but I seem to be running out of options.

thanks for all your help,

rob sterooni

[robsterooni]

Tried the hostbased auth. didn't work :-( It has got to be the firewall giving me this trouble. Anyway, gonna have to put this on the back burner for now; will come back to it later though.

Thanks so much for your time and effort! Learnt a lot,.. even though I didn't quite get there in the end(yet). For now I have loads of other stuff to do,.. gotta learn javascript, web server config, linux security, dreamweaver, photoshop, MySQL, php, cgi, perl, bash, marketing, SEO, etc. Also, gotta hunt down all those guys who keep requesting default.ida. ;-)

Cheers :)

Rob Sterooni

[dingman]

Also, gotta hunt down all those guys who keep requesting default.ida.

Mostly poor sods who didn't bone up on their NT security. Sometimes they make up half my logfile entries.

Sounds like you've got a lot on your plate. Just the stuff on your list that I know has taken years :)

[robsterooni]

Lot on my plate for sure, but I'm enjoying every minute of it. This forum is gonna help loads! One glorious day in the future I will be boss-free, I can feel it in my bones :) Thanks again, see ya around,

Rob Sterooni

[1kiwi]

Hi all - I had this same problem:

ssh_exchange_identification error message.

My fix: as root user type

service sshd status

the answer i got was: sshd stopped.

I entered:

service sshd start

then i got returned this message about "Generating ssh1 rsa host key"

I had never used ssh on this machine prior to this run. I had installed the three openssh packages needed for ssh to work ie client, server and openssh itself.

Then ssh worked for me. i got it running through xinetd and it works like a dream. I hope this may be of assistance to somebody sometime. Cheers and out.

[mikejson]

I didn't take the time to read all the replies but...

I had the same problem with some of the clients at my work. We have clients allowing access to our database through a SSH. Now some clients weren't getting through, getting the same error. All we did(only cause there were a few clients only) was allow connection through specific IPs and issues static IPs to that set of clients. You can configure your SSH to allow specific IPs(by number). Well in Unix you can. I'm sure it's similar on WinXp(I think that's what you said you were using). Then they don't have to DNS look up. But your client has to broadcast it's IP so when the request is sent to the client it will reply with it's IP, your server will then verify that the IP is part of the "safe IPs" list you set up in your SSH. Then it works fine. You can also allow groups of IPs through SSH. Setting it to look up the DNS through a DNS server and then allowing groups from a specific set of addresses.

We did something similar like that, allowing all the shawcable.net users to log in. This is not the best solution cause you could include a hostile IP in the group though...

I'm not sure if that made sense, it's something we did at my work, when we had that problem. This may not be useful to you, if you are connecting for an IP that changes all the time... but you could narrow down a group of IPs and allow them all... less secure but it'll work

[mikejson]

err, I read that wrong ... your connecting with windows... heh

SO... in your firewall script you can allow spefic IPs...
Mostly what I said applies hehe