smithvoice.com
 Y'herd thisun? 

“There is nothing inherently expensive about rockets. It's just that those who have built and operated them in the past have done so with horrendously poor efficiency.”
-Elon Musk



MONO/Ubuntu part 4 - Remoting to the box with SSH

TaggedLinux

Remoting to the box with SSH

Once you've got your new server core up to date, there are a few fundamental requirements for doing your .Net on Linux... your service management, your MONO, your firewall ... but first get your RDP so you can administer your box remotely.

The 'nix version of Terminal Services is OpenSSH and getting that server installed is easy. Just remember that Linux is stone-age case-sensitive and type:

sudo aptitude install openssh-server

You'll be asked for your password, the source list will look up the location of the files, you'll have to approve the install and whump... you can now do your work from a commandline while watching TV. Well... maybe.

If you have a Linux or a Mac laptop then all you have to do is get on the same network, call up your terminal and type in:

ssh [username on server]@[ip address of the server]

If it's the first time the server's been accessed by the machine then you'll have to add its RSA key to the client, then just type your server account password and you may as well be on the box.

Mac...

Windows is a little different though, you have to use two programs to get the meal-deal. The first is called PuTTY, and you can get it from its creator Simon Tatham, here. Yes, it's trusted by thousands. Just download it, unzip it and doubleclick the exe and you'll get this screen:

Type the server address in the Host Name box and click the "Open" button. You'll get a black & white terminal window asking you to log in. From there it's the same as everyone else EXCEPT for file copying between client and server.

File copying: use SCP

Copying files with a real SSH client is a matter of running your client terminal program and calling upon the scp command to push the file over, like this:

scp /[local path of file to copy]/filetocopy.xyz [server user name]@[server address]:/[path to where  you want the file copied]

Here's an example of moving a file named "sshkub.png" from a Kubuntu desktop machine to the Ubuntu server, and changing the file name to "copiedpic.png" in the process

Or, if you're already in a terminal ssh session and logged into the server, you'd "pull" the file over by reverse-executing scp into the client (requires that your client machine also has the openssh-server installed):

scp [client computer user name]@[client computer name or address]:/[full path of file to copy]/filetocopy.xyz [path on the server to copy the file to]/[filename to use on the server, leave blank to keep the same name]

Here's an example of physically running that Kubuntu desktop but being terminalled-in to the Ubuntu server as kilgore, and moving a file named "copiedpic.png" from the server's kilgore account home folder back over the the Kubuntu client as "copiedback.png":

btw: to not change the file name, just end the destination value with the path separator and don't specify a destination filename.

Unfortunately the scp command doesn't work with PuTTY. To move files between Windows and Linux, you have to use another tool such as the popular WinSCP. Download that, install it and you get a Windows-style GUI that lets you drag & drop files between Windows and Linux over the SSH port.

Caveat: Even with WinSCP, life ain't perfect. WinSCP, as of this writing anyway, won't let you elevate your account privledges to the sudo. That means that by default your ability to copy stuff over From Windows To Linux is going to be restricted to just being able to copy to your /home/[username] directory on the Linux box. Once you plop files there, you'll have to use PuTTY to call up sudo and move the files around to where they belong. Can't fully blame WinSCP, Ubuntu has no "Root" account, just a sudo.

Technically you can get around this limitation by changing the destination folder(s) on the server to have give read/write permissions for you user account(with the command "sudo chmod -R [username]:[username] [path to folder]") . That comes in handy on a test/dev box where you're doing a lot of incremental XCOPYs to a folder over the course of a day.

I had "discussions" about this option with a compusec guy who was totally against it even on test boxes, but the way I see it if your account has sudo rights to move stuff around under PuTTY, and if you get the full permissions using your Mac or LinuxDesktop SSH/SCP terminal, and because anyone who steals your password can use your sudo, it's not a huge security difference to allow folder R/Ws to that account.

If you're going to do the chmod route just make sure what WinSCP is set to prompt you for your password on connection to a server, that you shut down your WinSCP every time you leave your desk and remove the permissions when you're not so active in the folder.

Y'know? As long as we're on the compusec bent...

Securing your SSH server (a.k.a. An excuse to learn some Linux system stuff)

There are a number of options you can set for your SSH server; options for allowing or denying specific users, groups of users, client IP addresses or ranges... lots of options.

We'll quickly cover some of the most basic and useful alternative settings. To get the fullest details on the program, visit the OpenSSH site, and for a dry list of just the server configurations, click here.

Many SSH service options are set in the text file "sshd_config" which is in the "/etc/ssh" folder. We're going to use the nano text editor, a simple but powerful editor with on-screen hotkeys ala the old WordStar program from yesteryear.

And we'll start with something easy.

Changing the default listening port

Unless you're putting your server in a DMZ, changing the publically exposed port of a service would be done with port forwarding on your routers. Thing is that doing this at the service level is a real easy way to get used to the tools and processes you'll be using on the way to getting Mono correctly serving your web pages, so on we'll go...

It's a normal first line of defense to change a common service's default port *IF* the port doesn't have to blindly accept outside calls. You wouldn't change your public web site port from 80 or your mail server ports from 25 and 110 and expect to get much business, but you probably don't want Everyone trying get onto your server to play 'guess the password', so using a non-standard port is a fast & easy security trick.

Typically you'd avoid using the "Well-known ports" between 1 and 1023 (see the fine-print note below), that leaves you with the "Registered range" from 1024 to 49151 and the "Dynamic range" between 49152 and 65535. Lots to choose from, close your eyes and pick a card;-).

Any time you choose to expose a non-standard port to the internet, remember that most Military bases, most smart companies and some cell-carrier data plans will block what they consider non-standard ports. If you have to work under blocking, map your service to some other standard port that you're not using such as 8001 which is commonly opened for media streaming or port 443 if you're not going to be using SSL certificate web encryption. Hit Google for lists of the common standard ports and consider using one of them if your main external locations do blocking.

Navigate to that config file location:

cd /etc/ssh/

Using sudo, open the sshd_config file with nano; sudo is required because we'll be altering the file and saving it with changes. Careful to do this on the sshd_config (with a "d") to open the file for the server configuration, if you do an "ls" on the folder you'll see that it also contains a ssh_config (no "d") which is the client configuration, and that file won't do these tricks.

sudo nano sshd_config

The file opens up and you'll see that right near the top is the Port 22 setting, being the standard port for ssh. Use your arrow keys to go down to that line and just change the number value from 22 to something abnormal. I'm changing mine to 6666 (it's technically a listed irc chat port, but it's odd enough and easy to remember through these tutorials).

Use CTL-X to close the file. You'll be prompted to confirm the changes, press the "y" key and hit enter...

... and prompted to confirm the name of the file, you don't want to change the name so just press enter...

Nano will close and you're back at the command prompt. But, unlike a .Net configuration file change, the SSH server hasn't yet started using the new port. You have to restart OpenSSH to have it pick up the changes. To restart the OpenSSH server service, type the following:

sudo /etc/init.d/ssh restart

Or the more human-readable:

sudo service ssh restart

The /etc/ folder is where most service oriented files live. The oddly named /etc/init.d/ subfolder is sort of like the Windows Services control panel applet or MMC snapin. Linux services generally are started, stopped, restarted or have their status checked by using the command format "sudo /etc/init.d/[service name] [start|stop|restart|status]" but in most cases the call to the service [service name] [start|stop|etc.] command works too.

Make sure that you test the new port from another client before you disconnect the session that made the change; otherwise if it gets mucked up you'll have to physically log into the server box to fix it. Any currently running ssh client connections over the old port won't be killed but if you start another client instance of PuTTY (Windows) or another SSH session from a Mac or Linux box you'll want to get a connection refused error when not using the correct new port.

To use the new remote port from a Windows client, just change the value in PuTTY's main screen textbox from the default 22 to 6666. On Mac or Linux clients you can specify the port in the ssh terminal command such as:

ssh -p 6666 kilgore@172.121.0.9

If you routinely hit the server from the same private client machine, you can have the setting remembered by using nano to create/open the file "/home[username]/.ssh/config and adding these lines:

Host [remote server name or IP Address]
Port [remote server port number]

Continuing our example, the /home/[mac or linux desktop user name]/.ssh/config file would have these lines added to it:

Host 172.121.0.9
Port 6666

You can put as many of these sections as you want in the file, the ssh client knows to group all the sub-settings to the Host line above them. Optionally, you can also add a setting line of "User [remote user name]", so you don't have to type your remote user account name in the terminal; just typing the "ssh [remote servername or IP address]" will attempt the connection for that account and prompt you for the account's password.

  • If you list your Mac or Linux /home/[user name]/ folder with the "ls" command, you won't see the ".ssh" folder, but it is there; Try again using "ls -al" and you'll see it. In Linux, files and directories are hidden by naming them with a leading dot, and since this is a seldom used folder, it's dotted to keep it out of the way.
  • If you "ls" the hidden /.ssh folder, you may not see a file called "config", that's ok because it's an optional file. When you use "sudo nano [file name]", nano will open the named file for editing if it's there and create it if it's not.

Quick points on SCP commands for file copying: Mac/Linux client SCP commands will read the port setting in your /.ssh/config file. If you don't want to make the file, you can use inline syntax with a minor twist: you have to use a capital '-P' instead of a small "-p" for the port switch as in:

For Windows, you just specify the port in the WinSCP session list screen.

Access by User/Group and IP Addresses

If you've been following the bouncing ball of our Ubuntu/Mono tutorial, you so far only have a single user on your server, the one that was created when you installed the OS. And for all that stuff about Ubuntu being more secure because it 'doesn't have a root' ("machine admin" in Windows terms), that first user account may as well be a box administrator because if you sign in as then and use "sudo" you've got most everything at your fingertips. Even if any program that you start fails to do all of its work with a sudo startup because of some silly file/folder permissions, it can usually be gotten around by 'turning off the UAC' in Ubuntu by typing "sudo -s" at the prompt, then running that pesky app again.

What's it got to do with OpenSSH? Same as it does with a Windows RDP. Just as in Windows you know to set up a secondary account with specific rights and exclude the admin account from wild remote access, you should do the same with Ubuntu. So let's add a new user to the server, giving him his own home folder to play around in, then limit external connections to just that new account

There are a number of different commandline ways to add a new user, the ones you see the most are sudo useradd and adduser. On some Linuxes you can just flip a coin, but on Ubuntu server 8.10 they are Not The Same and I'd suggest that when you're setting up a non-service human's account you use adduser.

Quick reason (that I haven't yet seen anyone else mention): useradd, no matter the options used, doesn't set up the full user preferences correctly. The user will hit tab for a directory auto-fill and instead get ... a tab, they won't get a full folder notation on the commnand line, just the simple dollar sign, etc.. All little stuff? Yeah, but also tedious and annoying. Use adduser and let the Ubuntu-specific script guide you to it being done right.

sudo adduser joef

Typing just that from our kilgore account prompted us through the creation of the joef account:

You see that after the wizard ended we did an "ls" to verify that indeed the new /home/joef folder was created. You can also get verification with the account's internal id values and default group membership using the command "id [username]".

If you ssh into the box as joef now (or if physically on the box, type "exit" to logout the current account and be prompted to log in as another user), you will find yourself in the /home/joef/ folder. To confirm that the new account doesn't have any unsafe permissions as a machine admin, just try to sudo something.

Now go back into the sshd_config file (sudo nano /etc/ssh/sshd_config), scroll down the the bottom and add a new case-correct line:

AllowUsers joef

CTL-X to close and save the file changes. Then restart networking (sudo /etc/init.d/networking restart) and *Without logging off of the current connection!* attempt a new remote ssh/PuTTY connection to the box as that same original machine admin account.

And try again logging in as the new user.

Now, using the original machine sudoer connection (if you logged out of it you'll have to physically log onto the box), go back into the /etc/ssh/sshd_config file and remove the AllowUsers line so that everyone can get in again [tip! in nano you can quickly cut a whole line by using your arrow keys to move the cursor to the line and pressing CTL-K]. After saving the change and restarting the networking service, test to make sure both accounts can ssh in. Good?

 

Let's add a new user group to the server and add our boy Joe to it.<.p>

Logged in as the machine sudoer, you create a new machine group called "remoters" like this:

sudo addgroup remoters

And to add Joe Fernwright's account, it's a call again to adduser, but this time following the username with the group name.

sudo adduser joef remoters

sudo nano back into the /etc/ssh/sshd_config file, scroll to the bottom and add this case sensitive line:

AllowGroups remoters

Save the file, restart networking and use new remote instances again for both accounts. You should see the same results, where joef can ssh because he is in the remoters group, but kilgore (or your own machine admin) can't because he isn't in that group.

You can add more users and groups to the same appropriate line by just separating them with a space.

For finer control, there are corresponding DenyUsers and DenyGroups options. They work logically the same way. With them you can allow a group except for certain individual members of that group, and since groups can contain other groups as well as individual users you can Allow a main group and use DenyGroups/DenyUsers to filter out any riffraff.

Allow/DenyUsers has other nice options. For instance, you can specify IP Addresses and IP Address ranges. The following setting will let the joef account log in from ANY remote machine, and allow ANY user that comes from ONLY the IP range 192.168.0.1 to 192.168.0.255 to log in (note the use of asterisks for wildcarding).

AllowUsers joef *@192.168.0.*

Be careful with your use of multiple permission settings. Test Test Test after every modification because they may interreact unexpectedly and leave open holes that you don't want.

 

Almost forgot the cleanups. To remove a user from a group it's:

sudo deluser joef remoters

Likewise to remove a group it's:

sudo delgroup remoters

And to get rid of a user and all of their folders and files use:

sudo deluser --remove-all-files joef

Optional lower level access by IP Address

OpenSSH and other network services can optionally let a lower level of Linux networking take care of IP address restriction for both the whole machine and specific services. This is an option for system admins who like to deal with multiple services in one place and the settings for allowing and denying are respectively set in the /etc/hosts.allow and /etc/hosts.deny files.

To allow all users on the same network to have ssh access to the server, use this line to open the hosts.allow file:

sudo nano /etc/hosts.allow

Now scroll down below all of the default comments (comment lines start with a '#' character) and add a line that tells the machine that for the SSH server ("sshd"), you will allow the same network range that the server is on. For our example the server IP Address is 172.121.0.9 so we'll say that we want to allow ALL connections that come from any sister machine whose IP address starts with 172.121.0.x by specifying the first 3 octets with a trailing dot (you can also add the last zero, that also works to specify the entire octet range of machines) :

sshd: 172.121.0.
#or sshd: 172.121.0.0 will do the same thing

CTL-X and save the changed file. But it won't quite work yet. You have to also add a line to the hosts.deny file AND restart the server networking. First, that file...

sudo nano hosts.deny

Scroll down below the default comments and add the overall denier for the ssh service ('member: Linux be case-sensitive, this option is all small for the service and all caps for the setting):

sshd: ALL

Save the changes, then restart the box's networking with:

sudo /etc/init.d/networking restart

If instead we wanted to restrict more loosely to computers in the range of 172.121.0.001 to 172.121.255.255 we'd drop the last octet in the line in hosts.allow:

sshd: 172.121.

If there are other IP ranges we want to allow we'd just add them to the same line with a space between each, as in:

sshd: 172.121.0. 192.168.2.

All great if you want to allow by full octet groups, but how do you limit connections for specific addresses in the range? With the use of the EXCEPT option. Here we tell the server that the ssh service connections are allowed from any machine originating from 172.121.0.* except for machines specifically using 172.121.0.6 and *.40:

sshd: 172.121.0. EXCEPT 172.121.0.6 172.121.0.40

Remember that the hosts.allow and hosts.deny files work in tandem. Specifying an ip address or range in hosts.allow will not stop someone coming from any other ip address from getting to an ssh connection prompt unless you set the "sshd: ALL" line in hosts.deny. If you're thinking that the implication is that you can set restrictions from the inside-out, you're right. Instead of using the above line in hosts.allow, you could have cleared the line completely in that file, opened up hosts.deny and altered the ALL line such as:

sshd: ALL EXCEPT 172.121.0.42 192.168.2.

After restarting /etc/init.d/networking you would now only be able ssh to the machine if you were specifically coming from IP Address 172.121.0.42 OR coming from a box in the range of 192.168.2.1-192.168.2.255.

One more point: Unfortunately it appears that you can't use traditional Netrange syntax to allow or block ranges of addresses. Netrange syntax would be like "172.121.0.12-172.121.0.16" so only those 5 specific addresses could be allowed/blocked. Instead, the hosts.* options use the CIDR syntax ... which is designed to block large groups of addresses such as full country or geographical region ranges and is great to shutting a door to all of those international pokes we all get all the time. CIDR ("Classless Inter-Domain Routing", also called "supernetting"), is the format xxx.xxx.xxx.0/n which is the starting ip, a slash and then a value for "n" that specifies the number of bits in the netmask. For example 172.121.0.0/16 is the same as a netrange syntax of 172.121.0.0-172.121.0.255 where the machines are using the netmask of 255.255.0.0. Though it is a limitation with respect to ease, fans of 'nix defend it by the logic that Linux isn't supposed to be as easy as Windows ;-). For more information, geek out to the tools and docs about CIDR all over the internet.

 

Quick trick if your logins get slow

Sometimes on some machines you may notice that the prompt for the login password takes a few to a lot of seconds after typing your username. While the prompt does show up, waiting can be annoying. This can be caused by a number of verification issues, so you may have to yahoo it and try a lot of things.

But I've found one fix that so far speeds up the password prompting dramatically when you're attempting to connect using the IP Address of the server. Just nano into your /etc/shh/sshd_conf and at the bottom add this line:

UseDNS no

Restart the ssh server and try loggin in. Hope it works as well for you.

 


Coming next: After a quick tips & tricks for nano, we'll start Firewalling with ufw.


jump to:

  • 1: Why?
  • 2: Installation
  • 3: Update the OS with APT
  • 4: Remoting to the box with SSH
  • 5: NANO quickies for 95% of the jobs
  • 6: Firewalling Ubuntu 8.10 Server
  • 7: Installing Apache2 and MONO
  • 8: Test client host files
  • 9: Configure MONO on Apache2
  • 10: Apache default pages
  • 11: Handling Apache and Mono Errors
  • 12: Subdomains and Christian porn
  • 13: Virtual Host Tweak: unmanaged cAse sensitiviTy
  • 14: Managed cAse sensitiviTy
  • 15: Managing files and folders
  • 16: Logging Apache Accesses and Errors
  • 17: Ubuntu Task Managers
  • 18: Ubuntu Services and Service Managers
  • 19: Installing Oracle 10g XE Server
  • 20: Connecting Mono to Oracle


  • home     who is smith    contact smith     rss feed π
    Since 1997 a place for my stuff, and it if helps you too then all the better smithvoice.com