ssh server questions

[tomster2300]

Yes, my second linux post in a day!

I cannot connect to my Linux box via ssh through the external ip. Only the WAN ip is able to make a connection. I want to be able to connect to this machine remotely and use it as a file server of sorts.

What I've done so far -

I installed the ssh-server package in Ubuntu, created keys through the command "mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -q -f ~/.ssh/id_rsa -t rsa", and turned it on. I placed the private key in my .ssh directory on my Macbook (since I want to use it to connect to the server), and kept the public key in the same directory on the linux box.

I was able to connect by saying "ssh xxxx@xxxxx" in the terminal, but only with the WAN ip and not an external one.

I have been told that you cannot connect through an external ip from inside your network, but I was able to do so previously by using cyberduck on my mac to connect to a filezilla server running on Vista.

Was I truly connecting to the external address then, or was it somehow rerouting me through the local address? The same address worked outside of my home too.

Sftp works locally as well, connecting to the linux box via cyberduck on my mac.

[kilgoretrout]

Exactly, what error messages do you get when you attempt an ssh login from the terminal?

Also, I'm confused by your terminology. It's sounds like you can ssh to boxes on your local network(LAN) but can't ssh in from outside the LAN. A WAN ip is something I would associate with an "external" ip(WAN=wide area network), i.e. an ip from outside the LAN. Not sure what distinction you're drawing between a WAN ip and an external ip.

If you can ssh from within the LAN but not from outside the LAN, that's usually a firewall issue. You have to open up the ssh port on your firewall allow an ssh connection from outside the LAN. ssh operates on port 22 by default although many configure ssh to operate on another port because of the prevalence of script kiddy dictionary attacks operating on port 22. If you're LAN is behind a router, you will also need to do port forwarding of your ssh port to the ip assigned to your local box that you want to ssh to.

[tomster2300]

Originally Posted by kilgoretrout Exactly, what error messages do you get when you attempt an ssh login from the terminal? Also, I'm confused by your terminology. It's sounds like you can ssh to boxes on your local network(LAN) but can't ssh in from outside the LAN. A WAN ip is something I would associate with an "external" ip(WAN=wide area network), i.e. an ip from outside the LAN. Not sure what distinction you're drawing between a WAN ip and an external ip. If you can ssh from within the LAN but not from outside the LAN, that's usually a firewall issue. You have to open up the ssh port on your firewall allow an ssh connection from outside the LAN. ssh operates on port 22 by default although many configure ssh to operate on another port because of the prevalence of script kiddy dictionary attacks operating on port 22. If you're LAN is behind a router, you will also need to do port forwarding of your ssh port to the ip assigned to your local box that you want to ssh to.

You're right, I was mis-using the term WAN. I can SSH locally but not outside my LAN. I forwarded port 22 on my router, but I did not set which port to run the server through in Linux (I assumed it defaulted to 22, although it may be different like you say). I did the server setup through the terminal, so I never had to choose a port. Do you know the command to change ports?

Thanks for the response, I really appreciate it.

[kilgoretrout]

It will default to port 22 unless you specify otherwise. You can reset the port by editing /etc/ssh/ssh_config. Unless you see this line in ssh_config:

Port [some number other than 22]

ssh is on port 22. Typically you will see this line in ssh_config among many others:

# Port 22

The list of lines with the "#" in front of them is just listing the default configuration settings for ssh.

Instead of running ssh xxxx@xxxxx try running instead:

$ ssh -l [insert username on linux box] [insert appropriate ip for remote box]

I'm curious as to what error message you get. Note, the appropriate ip in the above command will be the ip assigned by your isp, i.e. the web facing ip of your router.

[Tin]

Dont forget to restart SSH afterwards.

sudo /etc/init.d/ssh restart

[tomster2300]

Alright, in an attempt to edit the config file, I realized I had two ssh folders - one is "/home/"myname"/.ssh (the one that the public key was placed into when generated by my terminal commands), and then the folder you referenced, which is "etc/ssh", which has the config file along with a bunch of keys. Why do I have two, and is this why my connection isn't working? Should my public key be in the other folder?

Update: Alright, after looking through the sshd_config file, it looks like the /etc/ssh folder contents run the server, but the host key is kept in both the %home/.ssh/authorized_keys and /etc/ssh_known_hosts ?

I say that because of this, which is listed in the config file ---

PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# 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_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

[tomster2300]

Alright, I got it working 100%...I think. Here's what I did, and hopefully you can correct me / fill in what I'm missing.

I found this guide online and followed it - https://help.ubuntu.com/8.04/serverg...sh-server.html

1) I deleted the old keys and regenerated new dsa ones.
2) I duplicated the public file and placed a copy in the .ssh folder on my Macbook (the computer I want to connect to the server with).
3) I then ran an altered version of this command in terminal on the Mac "cat id_dsa.pub >> .ssh/authorized_keys2" to copy the public file into the authorized keys file. I did not get an error.
4) Now I am able to connect to the Linux desktop through Cyberduck on the Macbook without any kind of password prompt, or failed connection. I am using the WAN ip too and not the LAN.

Now I have some new questions.

1) Did I do this correctly?
2) What is the purpose of the private key - I thought the private key was supposed to be transferred to the computer seeking the connection (in this case the Macbook). Right now the private key is only on the Linux machine in the .ssh folder along side the public key.
3) How do I make a guest account for people to log in? I plan on doing freelance web design / photography this summer, and my ultimate plan is to have an account clients can log into to deliver / take large files from. Do I do this via sftp with a key, password, or straightup ftp? I want to try and keep it as secure as possible.

Thanks for all the help, and I'm sorry for the jumbled, random updates. I test things, post my problems, then slowly solve my own problems.

[kilgoretrout]

It doesn't sound right to me. However, we may not be communicating very well; it's very important to use consistent terminology when dealing with applications/protocols that remotely control another machine. If not, things can get very confusing very fast. So for starters, let's define things consistently as they usually are done. Your linux box is your server. Other boxes will remotely connect to the server and run commands on that server using the ssh protocol. These other boxes are called clients. The only client you presently have is your Mac from what I can see.

When using keypairs for authentication in ssh, the keypairs are typically generated on the client machine, not the server. On a linux client, that would be done using the ssh-keygen command; I suspect a Mac would have a similar command. Whatever command you run to generate the keypairs, two keys will be produced, a public key and a private key, typically named id_dsa (private key) and id_dsa.pub (public key). The public key is copied to the server's ~/.ssh directory. The private key stays on the client box. In addition, on the server box, the configuration file you need to be looking at is /etc/ssh/sshd_config, not /etc/ssh/ssh_config.

Just reading through what you did and the results you got, I'm pretty confused as to what happened but I'm guessing that your sshd_config file has been altered from the defaults in some significant way. Here's a pretty straightforward overview of the process that may help you get back on track:

http://www.g-loaded.eu/2005/11/10/ssh-with-keys/

[tomster2300]

Originally Posted by kilgoretrout It doesn't sound right to me. However, we may not be communicating very well; it's very important to use consistent terminology when dealing with applications/protocols that remotely control another machine. If not, things can get very confusing very fast. So for starters, let's define things consistently as they usually are done. Your linux box is your server. Other boxes will remotely connect to the server and run commands on that server using the ssh protocol. These other boxes are called clients. The only client you presently have is your Mac from what I can see. When using keypairs for authentication in ssh, the keypairs are typically generated on the client machine, not the server. On a linux client, that would be done using the ssh-keygen command; I suspect a Mac would have a similar command. Whatever command you run to generate the keypairs, two keys will be produced, a public key and a private key, typically named id_dsa (private key) and id_dsa.pub (public key). The public key is copied to the server's ~/.ssh directory. The private key stays on the client box. In addition, on the server box, the configuration file you need to be looking at is /etc/ssh/sshd_config, not /etc/ssh/ssh_config. Just reading through what you did and the results you got, I'm pretty confused as to what happened but I'm guessing that your sshd_config file has been altered from the defaults in some significant way. Here's a pretty straightforward overview of the process that may help you get back on track: http://www.g-loaded.eu/2005/11/10/ssh-with-keys/

You were exactly right. Thank you for that link, it was invaluable. I reinstalled the openssh server and client and followed that site step-by-step. I am now connecting to the server (my linux desktop) from my client (my Macbook) with a correctly configured keypair.

Thanks for both the terminology lesson and the guide to make it all work. This is pretty cool. I ran the verbose command during the connection and could actually see the authentication take place, so I know it's working.

Now I have one last question. This set it up for inside a LAN, with my connection being 192.168.1.xxx. What do I do to connect through my external ip?

When I attempt this - ssh 97.81.82.76 it says the authenticity of the host cannot be established, would you like to add, and gives the RSA fingerprint. When I add it and try to connect, it says permission denied. What did I miss?

In my sshd_config file, my ListenAddress says:

#ListenAddress : :
#ListenAddress 0.0.0.0

Does this have anything to do with anything? Should I unhide this?

[kilgoretrout]

On your Mac, see if there's a file in your .ssh directory called known_hosts. If there is, just delete it and try and connect again. It's probably in an inconsistent state from your last go round which is pretty common when you're reconfiguring ssh on the server side. When you try to connect again, a new known_hosts file should be generated.

[tomster2300]

Originally Posted by kilgoretrout On your Mac, see if there's a file in your .ssh directory called known_hosts. If there is, just delete it and try and connect again. It's probably in an inconsistent state from your last go round which is pretty common when you're reconfiguring ssh on the server side. When you try to connect again, a new known_hosts file should be generated.

That worked, although I get this the first time I connect with a new program (terminal, cyberduck, etc.)

Connecting to 97.81.82.76...
The authenticity of host '97.81.82.76 (97.81.82.76)' can't be established.
RSA key fingerprint is (xxxxxxxxxxxxxxxxxxxxxxxx, etc.).
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '97.81.82.76' (RSA) to the list of known hosts.


When I add yes to the above, it validates and doesn't ask me again. Is this just a generic message that anyone would get when attempting to connect for the first time? I know the authentication comes afterwards.

Also, how do I make a guest login and define a single folder for them to use? I would have to turn password authentication on for that, wouldn't I? I want this to be as simple as possible for them.

[LeftyAce]

it validates and doesn't ask me again. Is this just a generic message that anyone would get when attempting to connect for the first time?

Yes. It's telling you you've never been there before. This is useful if later on you attempt to connect to the same server, and someone else is masquerading as the server. It'll show up as "never seen before" and you'll know something's wrong (either that, or you deleted that file again).

Also, how do I make a guest login and define a single folder for them to use? I would have to turn password authentication on for that, wouldn't I? I want this to be as simple as possible for them.

I believe the best way to do that is to create a new user on the server. That user will have its own /home/USERNAME folder, and won't be able to mess with anything else. I believe you can set up password-based logon on a per-user basis (so you can still use the keypair, but the guest will have to enter a password...I'm pretty sure that's what will happen by default).

[tomster2300]

Originally Posted by LeftyAce Yes. It's telling you you've never been there before. This is useful if later on you attempt to connect to the same server, and someone else is masquerading as the server. It'll show up as "never seen before" and you'll know something's wrong (either that, or you deleted that file again). I believe the best way to do that is to create a new user on the server. That user will have its own /home/USERNAME folder, and won't be able to mess with anything else. I believe you can set up password-based logon on a per-user basis (so you can still use the keypair, but the guest will have to enter a password...I'm pretty sure that's what will happen by default).

Alright, that's what I thought I had to do. I could then just make a drop-box folder in their home folder and set the permissions so that they can only give and not take.

How do I make it so that they cannot mess with any of the account settings though? How do I restrain them to only their home folder?

Thanks!

[LeftyAce]

Just to clarify, you are trying to set the server up for sftp, right? You just want a secure way for users to upload files, they don't need access to the functionality of the machine via ssh? (ssh is often used to give remote control of a computer). If you just want sftp, then restricting users as you describe is pretty straight-forward. If you want them to be able to _use_ the machine, the restrictions you describe may not be feasible.

Here's a link to instructions for setting up sftp: http://www.howtoforge.com/chrooted-s...l-debian-lenny
To restrict users to only be able to view their own home folder, you want to set up what is called a chroot jail. Essentially, when the user logs on, it tells them that the folder they are in is the root folder (/). Since their session believes there is nothing above it, they can't get out and wander around.

Setting things up so that users can write but not delete is tricky (and may not be possible). As far as I can tell, if a user can write a file, they can delete it. There may be a way around this, but more googling is in order (or a more knowledgeable passer-by).

EDIT: If all else fails, a kludgy solution would be some kind of script that runs whenever a user logs out, and sets the permissions on all their files to read-only.