[Solved] I don't understand SSH

ilovefridge · 2008-10-07 13:41:21

I setting up a SSH system. It's been using a weak password for authentication for ages as I've just used it over the LAN, but now I want to use over the internet, so I set up keys, disabled password authentication, put it on a non-standard port (is this secure enough for general use? - tell me if you would recommend anything else). I've set up DynDNS on a router level, so I don't even need to worry about the IP.

I'm not even sure I've actually got a problem, I'm just a bit confused through lack of understanding.

Everything works as to be expected over LAN, but when I try and connect to it over the internet, from my phone or desktop, it says that the RSA2 fingerprint isn't recognised, and asks if I'm sure I want to continue. I haven't connected over the net before, but shouldn't the 'fingerprint' be the same as it is on the LAN?

So I found the key as reported by ssh-keygen:

[steve@barry /]$ ssh-keygen -f ~/.ssh/id_rsa -l
2048 14:8a:15:d3:10:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /home/steve/.ssh/id_rsa.pub (RSA)

But when I want to connect over the 'net it says the fingerprint is 3c:0c:13:c5..etc..etc, not the same as above.

Will someone please explain how this all works?

Thanks very much!

Last edited by ilovefridge (2008-10-09 15:48:05)

bender02 · 2008-10-07 14:43:31

As far as I know, that message you get about the RSA key is not referring to your personal key, but to a key that sshd generates for itself on the first run (on arch it's maybe generated on install). You should accept it for the first time you are connecting from a new machine (phone, whatever). Then it's going to be stored somewhere (on linux it's usually ~/.ssh/known_hosts), and on each subsequent connection your ssh client will try to compare the stored key with the one provided by the server. If they don't agree, you get a BIG FAT WARNING, that the server's RSA key has changed. [By the way, they're stored by IP addresses, so if you have a dynamic address, the ssh client is going to ask about the 'unrecognized RSA key' every time the IP of your machine changes.]

dav7 · 2008-10-07 15:03:53

...put it on a non-standard port (is this secure enough for general use? - tell me if you would recommend anything else).

I would recommend something else, if you're ultra paranoid: configuring port knocking (<-- Wikipedia article). Read up on how it works, then, if you're lost for choice, take a gander at knockd, a daemon that looks pretty good and was actually written by Judd Vinet, the author/founder/awesome guy of Arch Linux himself

-dav7

Last edited by dav7 (2008-10-07 15:05:23)

fukawi2 · 2008-10-07 21:19:16

ilovefridge wrote:

(is this secure enough for general use? - tell me if you would recommend anything else).

To be sure, to be sure, I'd set "PermitRootLogin" to no as well. And install fail2ban

ilovefridge · 2008-10-07 21:53:55

Thank you everyone!

thanks, bender02, for explaining everything. Made me feel more confident about it!

I've as to the other suggestions, I've already set "PermitRootLogin" to no, and I will look into fail2ban and knockd, they seem very useful!
Thanks all of you!

bender02 · 2008-10-07 22:12:26

NP

I like blocking after failed attempts more than knocking (although I used that at some point as well), since you don't have to carry around the knock client binary. And there's many more programs similar to fail2ban, there's even just a one or two iptables commands that can block an IP after some attempts for some time. Just google for it (I was using bruteblock, but that works only on FreeBSD).

pointone · 2008-10-07 22:23:35

I used denyhosts on my old Debian server--worked like a charm.

burnside · 2008-10-07 23:40:46

It wouldn't be a bad idea to add logwatch to the mix.

ilovefridge · 2008-10-08 22:15:26

Cheers, I will look into logwatch.

I don't think I will use port knocking as I don't think there is a symbian app (for my phone) to attempt opening them, and even if there was, I think it might make everything a bit fiddly for phone use. I set up Denyhosts though, as it had a good wiki page and it looked pretty simple to configure.

It's all set up, but when testing it, I realised that when an incorrect key passphrase was entered when trying to connect to the SSH server, no attempt of connection was logged in /var/log/auth.log

I remember it logging "failed attempt" or something along those lines when using normal passwords to accsess the sever, why does it not do this with keys+passphrase? Is the key decrypted (for lack of a better word) on the client side when the passphrase is entered before sending anything to the SSH server? Hence no record of a failed login? Or is this completely wrong? It also doesn't record anything in auth.log if someone attempts to connect with no public key at all...

sorry for the questions.. thanks for all your help!

Last edited by ilovefridge (2008-10-08 22:30:50)

bender02 · 2008-10-09 07:23:51

from http://www.ibm.com/developerworks/library/l-keyc.html

... To do this, we simply type ssh drobbins@remotebox at localbox's console, as we always have. However, this time, ssh lets remotebox's sshd know that it would like to use the RSA authentication protocol. What happens next is rather interesting. Remotebox's sshd generates a random number, and encrypts it using our public key that we copied over earlier. Then, it sends this encrypted random number back to the ssh running on localbox. In turn, our ssh uses our private key to decrypt this random number, and then sends it back to remotebox, saying in effect "See, I really do hold the matching private key; I was able to successfully decrypt your message!" Finally, sshd concludes that we should be allowed to log in, since we hold a matching private key. Thus, the fact that we hold a matching private key grants us access to remotebox. ...

Although it doesn't answer your question , I suppose that yes, if you enter a wrong password for your private key, it doesn't get decrypted, so the second part (decrypting the message from the ssh server and sending back the decrypted number) does not happen.

EDIT: thinking about the question again - some connection with the ssh server *is* established before decrypting the local key, since the ssh client apriori does not know whether the server it is connecting to has your public key.

Last edited by bender02 (2008-10-09 07:26:00)

ilovefridge · 2008-10-09 15:47:06

Thanks bender, you have helped a lot with this. That is an interesting link you provided, it was a helpful read!

Yes, like you said the connection is established before decrypting the key, to the extent of sending any banners (I've got a small bit of ASCII art) to the client. I would have thought this connection would be logged in auth.log, but it seems it is only logged if a successful passphrase is submitted.

But then I've been thinking, it doesn't really matter if it is logged or not, as if 'they' did manage to acquire the private key somehow, they could crack the passphrase offline, with an alarmingly short script (easy to find on google) which I assume can try 1000's of passphrases a second, and then log in freely, without sending anything incorrectly to the server at all. Hence making Denyhosts redundant with a key system.

This leaves me wondering if I should have a key system, or a password system.

With a key system, they can crack the passphrase offline, but only if they have acquired the key. If the passphrase is long, it shouldn't be a realistic possibility, but you never know. With a plain password system, anyone can have a go at cracking it, but after 3 or 4 attempts I can deny the IP for 15 minutes. And if the password is long and secure, it shouldn't be an issue even if they were bruteforcing it for months without denying them.

So I think I have come to the conclusion that SSH is pretty secure anyway, and I'm just being a bit paranoid! I think as long as you choose a password/phrase which is secure, you shouldn't have to worry about which method of authentication you choose. The only situation I can think of in which the method would matter, might be if you were a system administrator managing lots of different users connecting. If you couldn't trust them all to have secure passwords, you could make them use keys which you could set the passphrases for yourself.

If any of this is complete rubbish anyone can tell me! But that is how it appears from here.

Thanks again bender02 and everyone else who helped, I will mark this as solved as I understand SSH much better now (I hope)!

Last edited by ilovefridge (2008-10-09 15:54:33)

bender02 · 2008-10-09 15:58:23

ilovefridge, your reasoning is correct. For me the main reason for using keys is convenience - using ssh-agent/keychain makes logging into various remote machines pretty easy, with a lot less password typing. On my own machine, I usually allow password logins - you never know from where you'd need to log in (like a friend's machine, or a random computer at a conference, or such), and then using the keys is quite a hassle.

fukawi2 · 2008-10-09 21:37:54

ilovefridge wrote:

This leaves me wondering if I should have a key system, or a password system.

Why not both? I run all my systems like this:
1) Password and Key authentication allowed
2) Key-based is for convenience from trusted machines (ie, my desktop on the internal network)
3) Password for remote access from "anywhere" as bender02 said
4) Only users in the 'ssh' group are allowed to login (AllowGroups ssh) so "they" have to guess my ssh username before they even start on my password / key.
5) fail2ban blocks any IP address that fails 3 time in 15 minutes.

Just make sure:
a) your passwords are secure (eg, my password is the serial number from my old laptop; >12 characters, upper and lower and I've added in some punctuation too)
b) you protect your private key (ie, don't leave it anywhere publicly accessible, or on a USB stick in your pocket where it could be easily lost)
Then you'll be fine. Moving to a non-standard port such as 2222 or 1022 etc almost eliminates brute-force attacks as most of these are automated to just scan a network segment and look for port 22, ignoring all others.

Last edited by fukawi2 (2008-10-09 21:40:37)

ilovefridge · 2008-10-15 11:34:51

Thanks for that idea fukawi, that is a good way of doing it,. For now I have decided I don't really mind typing in the password when I connect so I've disabled keys and just stuck with the password. It's pretty long and has upper/lowercase numbers and a bit of punctuation.

Denyhosts seems to work, if a wrong password is entered 6 times in a week period, the IP is banned, but the count is reset if they enter it correctly, so hopefuly I won't ban myself! The IP is also banned straight away if they try to login with root or an account that doesn't exist. The port is >40000 and I haven't had anyone even attempt to connect in the last 5/6 days, with the computer left on 24/7. I'm tempted to put it on port 22 for a while, just so it blocks a few and I feel satisfied!

Thanks again!

Arch Linux

#1 2008-10-07 13:41:21

[Solved] I don't understand SSH

#2 2008-10-07 14:43:31

Re: [Solved] I don't understand SSH

#3 2008-10-07 15:03:53

Re: [Solved] I don't understand SSH

#4 2008-10-07 21:19:16

Re: [Solved] I don't understand SSH

#5 2008-10-07 21:53:55

Re: [Solved] I don't understand SSH

#6 2008-10-07 22:12:26

Re: [Solved] I don't understand SSH

#7 2008-10-07 22:23:35

Re: [Solved] I don't understand SSH

#8 2008-10-07 23:40:46

Re: [Solved] I don't understand SSH

#9 2008-10-08 22:15:26

Re: [Solved] I don't understand SSH

#10 2008-10-09 07:23:51

Re: [Solved] I don't understand SSH

#11 2008-10-09 15:47:06

Re: [Solved] I don't understand SSH

#12 2008-10-09 15:58:23

Re: [Solved] I don't understand SSH

#13 2008-10-09 21:37:54

Re: [Solved] I don't understand SSH

#14 2008-10-15 11:34:51

Re: [Solved] I don't understand SSH

Board footer