There's employers out there that would view a never-updated or rarely-updated Facebook account as anti-social behavior and a troublesome trait. It's sad, scary, and true.
To answer your question: Gate One comes with the SSH plugin pre-installed and enabled. So it's ready-to-go as an SSH client "out of the box" as it were.
As for the plugin architecture, it's not as complicated as it sounds. There's a "plugins" directory. In that directory there's individual plugins such as "ssh" (which is its own directory):/opt/gateone/plugins/ssh
When you execute gateone.py it will scan the plugins directory for plugins and load them accordingly. Plugins can be written in any combination of Python, JavaScript, and CSS (yes, in theory you could make a CSS-only plugin). As an example, here's the layout of the SSH plugin directory:
So in this example the SSH plugin is taking advantage of all three supported plugin types simultaneously: Python, JavaScript, and CSS. Each type will be loaded appropriately... Python files will be imported and their 'hooks' will be attached accordingly, JavaScript files will be automatically added to whatever page is loading Gate One, and CSS files will be automatically added to the HEAD tag of the page. It's all seamless and happens automatically by simply placing the files in the correct locations.
That 'scripts' directory is just somewhere to store that ssh_connect.py script which is what gets called when Gate One spawns a new terminal (by default). Just think of the 'scripts' directory as an arbitrary place to store a non-plugin file or two (I could've just placed them inside the 'ssh' directory but that wouldn't be very organized =).
Cool fact: Gate One loads JS and CSS files over the WebSocket.
THANK YOU SIR! It was AjaxTerm that lead me to develop Escape From The Web which was an HTTP streams-based predecessor to Gate One. If it weren't for AjaxTerm's example of how to write such an application I probably would've never gotten around to making Gate One.
So thanks again; Gate One wouldn't have been possible if you never shared your code.
The other replies covered this already but I thought I'd provide an authoritative answer: It isn't contradictory. Gate One requires no browser plugins but is itself built on top of a plugin architecture. For example, the SSH capabilities all come from a single plugin.
You're right: The four webservers I setup to serve liftoffsoftware.com are barely breaking a sweat right now. Load average on all of them is about 0.02. It is low enough that I'll be taking one or two of them offline I think (why pay for what I don't need?). I also want to mention that I *did* tune them considerably and even modified the Drupal theme to serve up many of the static files via a CDN.
It is the Gate One servers that needed the beefy resources since each open terminal needs to take up enough memory to be stored/kept track of inside of the Python interpreter. 90% of the load there (from a Slashdotting) is memory and I can't believe I didn't foresee this. Lesson learned.
Having said all that I believe I went way overboard by setting up four 4096MB Gate One servers. Here's the line from 'top' on one of the Gate One servers right now (as I'm being slashdotted): 1203 1165 3:51.43 36 5.3 20 0 S 980m 768m 211m 0 python./gateone.py
That's with Google Analytics showing ~400 users on the site right now.
5.3% memory utilization is nothing and as long as everyone doesn't stick around surfing the web all day in text mode that number will probably never rise above 10%. I'll be watching it and likely be swapping these servers out with 1GB ones. I love on-demand cloud hosting!
Because it isn't completely client side. Every time you open a new terminal it spawns a new shell and server-side terminal emulator to run it. Gate One wasn't really made to handle a slashdotting but I believe I can make adjustments if necessary to make it work. If the load stays this steady everything should be running smoothly for the rest of the day:)
I used to be a Payment Card Industry Qualified Security Assessor (QSA). I would to go into a business, audit them, and then give a big report to their payment processor detailing every little thing (related to security controls and credit card stuff) they're doing wrong (and to be fair, everything they're doing right). In this case, all of the U.S. carriers *do* accept and store customer credit card information which means they regularly have QSAs stopping by to audit the place (at least once a year). Therefore they *must* comply with the PCI DSS.
There's no question in my mind: If I were performing a PCI audit of Verizon or AT&T and I stumbled across credit card information in some database along with CVC/CVV2 codes that also happened to have people's usernames and passwords that would definitely go into my report (it would also likely warrant a call to my contacts at the PCI org and the payment processor ASAP)! It would raise all sorts of red flags and they'd have to account for it and protect it like any other credit card/financial data. I'd demand that they show me the following:
1) Where the data came from? 2) How it was being transmitted over the network (cleartext? Hah! That'll increase transaction fees)? 3) How is it being stored? If it isn't encrypted they'd be in serious trouble. 4) CVV2 data? That's just asking to be fined a huge sum of money and to have your transaction fees increased (which in the case of the carriers would be a much worse punishment than a measly seven figure dollar amount). They'd need to provide me a detailed remediation plan for that one (as in, "You have until the end of my audit to write up a detailed plan on how you're going to scrub the CVC/CVV2 data from the database"). 5) Specifications and configuration details on all hardware that runs this collection software. From the perspective of PCI every phone collecting such data is now classified as a terminal. They won't be able to get away with saying it is a service (like a website where the terminals aren't controlled by them) which means they'd say goodbye to me at the end of MY audit and say hello to the PCI org's internal hardware audit team (that usually works with companies that make payment terminals and credit card scanning machines). They're MUCH more strict and have a *lot* more rules than the measly little DSS.
I'd also like to mention that the fact that they still collect data from customers that aren't on contract anymore is an order of magnitude worse than anything else I've previously mentioned. I can't even fathom how pissed a jury would be with Verizon or AT&T (companies that everyone already loves to hate) for knowingly collecting HIPAA-classified private health information alongside GLBA-classified financial information in secret. Throw in a data leak and you've got yourself one hell of a rap sheet.
Some other folks were speculating that since you signed an agreement with your carrier that it somehow makes this legal. This is absolutely false. There are certain rights that you can sign away, certainly, but don't think of it like that. Think of it like, "What is Verizon doing with this data and how are they transporting it?"
Here's a few laws and industry regulations they are violating (by recording all keystrokes) off the top of my head:
1) The Payment Card Industry Data Security Standard (PCI DSS): If anyone ever (ever) enters credit card information into their phone (via an app, web page, whatever) that data must be protected according to the DSS (because all the carriers accept credit cards, that is). That means it must be encrypted in transit, when it is stored, and more importantly: certain information must *NOT* be stored (again, ever). For example, if a user enters the CVV2 from their card into an online form the carrier must ensure that this data does not get stored (good luck with THAT regex! hah!).
2) Graham Leach Bliley Act (GLBA). Undoubtedly, personally identifiable financial information is being recorded, transported, and stored without the user's knowledge or consent (each transaction/event would need its own notice and agreement with the carrier). That could add up to literally MILLIONS of violations.
3) Sarbanes Oxley: If they're recording this data they had better damned well keep an audit trail on it and be regularly disclosing that they're doing so to all their investors. They also must have documented controls & procedures and (likely) perform regular audits to ensure that said controls & procedures are being properly followed.
4) They can be held liable for having knowledge of crimes but not reporting them.
5) They can lose their common carrier status: Since they're now recording literally everything users do online they can be held (partially) accountable for what those users do. If you recorded the data you certainly could've audited it for fraudulent activity. "Have you been the victim of a crime that took place over a cell phone? Call the law offices of Sue & Win."
6) There's probably a dozen laws that say you can't intercept and/or store information related to people's banking accounts and financial transactions (unless you're the bank that the customer is interacting with). These laws are the ones that should make the carriers quiver in their boots. Some of these were written specifically to deal with gangsters and organized crime and as such could land executives in prison (not that I think the U.S. Attourney General would prosecute since our government is sadly, "stupidly hard on individual crime but soft on corporate crime").
7) Unless their contract specifically spells out that they're going to record every keystroke you enter into your phone they've opened themselves up to millions of lawsuits. If anyone ever wins one of these it will be game over for the carriers. "verizon" and "at&t" will likely become some of those "$50-per-click" Adwords on Google.
8) If they're not using proper encryption of this data in transit and storage, the PCI DSS will be the least of their problems... That's criminal negligence right there. After hearing all the controls the Payment Card Industry requires of the carriers for something as simple as a credit card number what jury could be convinced of a defense such as, "We didn't know!"?!? I mean, seriously. Forget being fired. If someone knowingly decided it was a good idea to record all keystrokes they should go to prison. It is the penultimate example of why you don't put non-technical people in charge of making technical decisions.
We had what you prefer for like a decade now and you know what? It sucks. Like PHP is somehow the the pinnacle of how application development should be. Hah!
Not to mention the fact that managing Apache httpd or Nginx with generic language "plugins" is about as intuitive as tying your shoes using a robotic atm controlled by a BlackBerry.
Also, please tell me how this model of development "doesn't work well?" If it doesn't work well no one will use it. Problem solved!
Why don't you take a break from this old school, all-problems-have-been-solved web of yours and go tell some kids to get off your lawn.
The business parts will be selling support/indemnification contacts and proprietary licenses ( so companies can embed Gate One without having to comply with the terms of the AGPLv3).
The key management parts of the code are sitting in an archive directory on my laptop at the moment. Just have to do some copying, pasting, and a little bit of logic rework.
The problem with private keys as you suggest is that they have vulnerabilities of a different sort: They don't scale and they lack centralized administration. Someone suggested in another thread that it would be great if users could store their private SSH key on a USB thumb drive. To me, this sure sounds convenient to the user but it would be a nightmare for anyone that employed them. They could be fired for insubordination and walk right out the door with a key that lets them remotely access all of the company's servers--even if you disable their account from a centralized location (LDAP, Active Directory, etc). To truly disable their access you'd need to login to every server they ever had access to in order to remove their authorized_keys file (you could use the SSH Power Tool to do it--which I also wrote =).
Where I work we have over 40,000 Unix (or Unix-like =) servers and only about 2,000 of them have some kind of NFS-mounted home directory setup. Those servers are managed by about 37 different IT organizations across the planet but nearly all of them (except those in DMZs and special restricted environments) can be logged into via user's Active Directory accounts. There's literally hundreds of teams of sysadmins, DBAs, and application administrators of varying sorts that administer their respective things across a wide variety of geographic locations and organizations. There's not a single admin team that has access to everything the other teams have access to. Also, there's a number of servers that you can't just login to (to make a change) except during special maintenance windows on the weekends (don't ask--super duper restricted--all sorts of alarms would go off and regulators would probably storm in, LOL).
I have friends that work at other big businesses with similar situations (tens of thousands of servers with accounts managed via AD/LDAP). When an employee leaves the organization, how do you propose you disable their access? With key-based authentication you need to visit every server they ever logged into to make sure their authorized_keys file is disabled. With password-based authentication you only have to disable their account in AD/LDAP (it's a cinch!).
I can go on and on about this topic... Especially in regards to Kerberos authentication, 2-factor methods, and whatnot. But the point I'm trying to make is that key-based auth isn't the be-all, end-all to SSH authentication that you're making it out to be.
By default Gate One runs all sessions through the dtach program which is like a mini version of screen... So you CAN resume a session started from Gate One via some other connection method (e.g. traditional ssh). I really need to document how to do this because it is a pretty cool feature.
I haven't set the website up yet (which is why I didn't link to it anywhere but a few places in the docs). There's also a note on the Github page saying this.
Believe it or not, I have this in the TODO for Gate One 2.0. It will require implementing the X11 protocol in JavaScript using the canvas element. It shouldn't be too difficult... Just extremely time consuming. Which is something I don't have much of these days.
Gate One is meant to run on a server. As in, you setup a Gate One server on your network and then you connect to it from a client machine (Windows works fine for this). Another way it can be used is on a server... As a backup in case the SSH daemon stops working or, say, to embed a terminal into a web-based administration interface.
Of course, you could run it on your desktop and use it like a traditional SSH client (I do it every day when I'm working on it) but it wouldn't be as useful.
Slashdot Mirror
There's employers out there that would view a never-updated or rarely-updated Facebook account as anti-social behavior and a troublesome trait. It's sad, scary, and true.
You're confused: Gate One runs on a server. You connect to that server with your browser.
Step 1: Install Gate One on a server somewhere. ...
Step 2: Open up your browser and connect to your Gate One server.
Step 3:
Step 4: Profit!
Note: Gate One can actually run on just about anything with Python installed. I've got it installed and running on my router at home, for example :)
To answer your question: Gate One comes with the SSH plugin pre-installed and enabled. So it's ready-to-go as an SSH client "out of the box" as it were.
As for the plugin architecture, it's not as complicated as it sounds. There's a "plugins" directory. In that directory there's individual plugins such as "ssh" (which is its own directory): /opt/gateone/plugins/ssh
When you execute gateone.py it will scan the plugins directory for plugins and load them accordingly. Plugins can be written in any combination of Python, JavaScript, and CSS (yes, in theory you could make a CSS-only plugin). As an example, here's the layout of the SSH plugin directory:
root@portarisk:/opt/gateone/plugins # ls -lR ssh
ssh:
total 48
drwxr-xr-x 2 root root 4096 2012-02-26 12:29 scripts
-rw-rw-r-- 1 root root 36473 2012-02-09 12:24 ssh.py
drwxr-xr-x 2 root root 4096 2012-02-21 09:12 static
drwxr-xr-x 2 root root 4096 2012-02-07 15:25 templates
ssh/scripts:
total 60
-rw-rw-r-- 1 root root 5708 2012-02-13 10:36 logo.png
-rwxr-xr-x 1 root root 30576 2012-02-26 12:29 ssh_connect.py
ssh/static:
total 56
-rw-r--r-- 1 root root 54852 2012-02-21 09:12 ssh.js
ssh/templates:
total 8
-rw-rw-r-- 1 root root 5052 2012-02-07 15:23 ssh.css
So in this example the SSH plugin is taking advantage of all three supported plugin types simultaneously: Python, JavaScript, and CSS. Each type will be loaded appropriately... Python files will be imported and their 'hooks' will be attached accordingly, JavaScript files will be automatically added to whatever page is loading Gate One, and CSS files will be automatically added to the HEAD tag of the page. It's all seamless and happens automatically by simply placing the files in the correct locations.
That 'scripts' directory is just somewhere to store that ssh_connect.py script which is what gets called when Gate One spawns a new terminal (by default). Just think of the 'scripts' directory as an arbitrary place to store a non-plugin file or two (I could've just placed them inside the 'ssh' directory but that wouldn't be very organized =).
Cool fact: Gate One loads JS and CSS files over the WebSocket.
THANK YOU SIR! It was AjaxTerm that lead me to develop Escape From The Web which was an HTTP streams-based predecessor to Gate One. If it weren't for AjaxTerm's example of how to write such an application I probably would've never gotten around to making Gate One.
So thanks again; Gate One wouldn't have been possible if you never shared your code.
The other replies covered this already but I thought I'd provide an authoritative answer: It isn't contradictory. Gate One requires no browser plugins but is itself built on top of a plugin architecture. For example, the SSH capabilities all come from a single plugin.
You're right: The four webservers I setup to serve liftoffsoftware.com are barely breaking a sweat right now. Load average on all of them is about 0.02. It is low enough that I'll be taking one or two of them offline I think (why pay for what I don't need?). I also want to mention that I *did* tune them considerably and even modified the Drupal theme to serve up many of the static files via a CDN.
It is the Gate One servers that needed the beefy resources since each open terminal needs to take up enough memory to be stored/kept track of inside of the Python interpreter. 90% of the load there (from a Slashdotting) is memory and I can't believe I didn't foresee this. Lesson learned.
Having said all that I believe I went way overboard by setting up four 4096MB Gate One servers. Here's the line from 'top' on one of the Gate One servers right now (as I'm being slashdotted):
./gateone.py
1203 1165 3:51.43 36 5.3 20 0 S 980m 768m 211m 0 python
That's with Google Analytics showing ~400 users on the site right now.
5.3% memory utilization is nothing and as long as everyone doesn't stick around surfing the web all day in text mode that number will probably never rise above 10%. I'll be watching it and likely be swapping these servers out with 1GB ones. I love on-demand cloud hosting!
Because it isn't completely client side. Every time you open a new terminal it spawns a new shell and server-side terminal emulator to run it. Gate One wasn't really made to handle a slashdotting but I believe I can make adjustments if necessary to make it work. If the load stays this steady everything should be running smoothly for the rest of the day :)
OK, I just setup four new servers running Gate One with 4GB of RAM each. If that's not enough I'll just put up more :)
Feel free to try the demo again.
LOL, that'll teach me to use Rackspace's cheap servers. Setting up new ones now with more memory... Should start working again in a bit.
The point of encrypting your data is so that 3rd parties CAN'T access it. Encrypt it yourself and THEN put it in the cloud.
Not to worry, Howard the Duck will save us from any would-be scorpion overlords.
"One tool to rule them all" was the governance policy of Mordor. Silos can be a lot like towers.
I used to be a Payment Card Industry Qualified Security Assessor (QSA). I would to go into a business, audit them, and then give a big report to their payment processor detailing every little thing (related to security controls and credit card stuff) they're doing wrong (and to be fair, everything they're doing right). In this case, all of the U.S. carriers *do* accept and store customer credit card information which means they regularly have QSAs stopping by to audit the place (at least once a year). Therefore they *must* comply with the PCI DSS.
There's no question in my mind: If I were performing a PCI audit of Verizon or AT&T and I stumbled across credit card information in some database along with CVC/CVV2 codes that also happened to have people's usernames and passwords that would definitely go into my report (it would also likely warrant a call to my contacts at the PCI org and the payment processor ASAP)! It would raise all sorts of red flags and they'd have to account for it and protect it like any other credit card/financial data. I'd demand that they show me the following:
1) Where the data came from?
2) How it was being transmitted over the network (cleartext? Hah! That'll increase transaction fees)?
3) How is it being stored? If it isn't encrypted they'd be in serious trouble.
4) CVV2 data? That's just asking to be fined a huge sum of money and to have your transaction fees increased (which in the case of the carriers would be a much worse punishment than a measly seven figure dollar amount). They'd need to provide me a detailed remediation plan for that one (as in, "You have until the end of my audit to write up a detailed plan on how you're going to scrub the CVC/CVV2 data from the database").
5) Specifications and configuration details on all hardware that runs this collection software. From the perspective of PCI every phone collecting such data is now classified as a terminal. They won't be able to get away with saying it is a service (like a website where the terminals aren't controlled by them) which means they'd say goodbye to me at the end of MY audit and say hello to the PCI org's internal hardware audit team (that usually works with companies that make payment terminals and credit card scanning machines). They're MUCH more strict and have a *lot* more rules than the measly little DSS.
I'd also like to mention that the fact that they still collect data from customers that aren't on contract anymore is an order of magnitude worse than anything else I've previously mentioned. I can't even fathom how pissed a jury would be with Verizon or AT&T (companies that everyone already loves to hate) for knowingly collecting HIPAA-classified private health information alongside GLBA-classified financial information in secret. Throw in a data leak and you've got yourself one hell of a rap sheet.
Some other folks were speculating that since you signed an agreement with your carrier that it somehow makes this legal. This is absolutely false. There are certain rights that you can sign away, certainly, but don't think of it like that. Think of it like, "What is Verizon doing with this data and how are they transporting it?"
Here's a few laws and industry regulations they are violating (by recording all keystrokes) off the top of my head:
1) The Payment Card Industry Data Security Standard (PCI DSS): If anyone ever (ever) enters credit card information into their phone (via an app, web page, whatever) that data must be protected according to the DSS (because all the carriers accept credit cards, that is). That means it must be encrypted in transit, when it is stored, and more importantly: certain information must *NOT* be stored (again, ever). For example, if a user enters the CVV2 from their card into an online form the carrier must ensure that this data does not get stored (good luck with THAT regex! hah!).
2) Graham Leach Bliley Act (GLBA). Undoubtedly, personally identifiable financial information is being recorded, transported, and stored without the user's knowledge or consent (each transaction/event would need its own notice and agreement with the carrier). That could add up to literally MILLIONS of violations.
3) Sarbanes Oxley: If they're recording this data they had better damned well keep an audit trail on it and be regularly disclosing that they're doing so to all their investors. They also must have documented controls & procedures and (likely) perform regular audits to ensure that said controls & procedures are being properly followed.
4) They can be held liable for having knowledge of crimes but not reporting them.
5) They can lose their common carrier status: Since they're now recording literally everything users do online they can be held (partially) accountable for what those users do. If you recorded the data you certainly could've audited it for fraudulent activity. "Have you been the victim of a crime that took place over a cell phone? Call the law offices of Sue & Win."
6) There's probably a dozen laws that say you can't intercept and/or store information related to people's banking accounts and financial transactions (unless you're the bank that the customer is interacting with). These laws are the ones that should make the carriers quiver in their boots. Some of these were written specifically to deal with gangsters and organized crime and as such could land executives in prison (not that I think the U.S. Attourney General would prosecute since our government is sadly, "stupidly hard on individual crime but soft on corporate crime").
7) Unless their contract specifically spells out that they're going to record every keystroke you enter into your phone they've opened themselves up to millions of lawsuits. If anyone ever wins one of these it will be game over for the carriers. "verizon" and "at&t" will likely become some of those "$50-per-click" Adwords on Google.
8) If they're not using proper encryption of this data in transit and storage, the PCI DSS will be the least of their problems... That's criminal negligence right there. After hearing all the controls the Payment Card Industry requires of the carriers for something as simple as a credit card number what jury could be convinced of a defense such as, "We didn't know!"?!? I mean, seriously. Forget being fired. If someone knowingly decided it was a good idea to record all keystrokes they should go to prison. It is the penultimate example of why you don't put non-technical people in charge of making technical decisions.
We had what you prefer for like a decade now and you know what? It sucks. Like PHP is somehow the the pinnacle of how application development should be. Hah!
Not to mention the fact that managing Apache httpd or Nginx with generic language "plugins" is about as intuitive as tying your shoes using a robotic atm controlled by a BlackBerry.
Also, please tell me how this model of development "doesn't work well?" If it doesn't work well no one will use it. Problem solved!
Why don't you take a break from this old school, all-problems-have-been-solved web of yours and go tell some kids to get off your lawn.
This is true, but reading a book on java and doing the examples is on par with many CS programs.
The sound file is only temporary regardless. I'll be picking/making something else for 1.0. Probably the favicon too.
Nice catch though. Most people would never have noticed that.
The business parts will be selling support/indemnification contacts and proprietary licenses ( so companies can embed Gate One without having to comply with the terms of the AGPLv3).
The key management parts of the code are sitting in an archive directory on my laptop at the moment. Just have to do some copying, pasting, and a little bit of logic rework.
The problem with private keys as you suggest is that they have vulnerabilities of a different sort: They don't scale and they lack centralized administration. Someone suggested in another thread that it would be great if users could store their private SSH key on a USB thumb drive. To me, this sure sounds convenient to the user but it would be a nightmare for anyone that employed them. They could be fired for insubordination and walk right out the door with a key that lets them remotely access all of the company's servers--even if you disable their account from a centralized location (LDAP, Active Directory, etc). To truly disable their access you'd need to login to every server they ever had access to in order to remove their authorized_keys file (you could use the SSH Power Tool to do it--which I also wrote =).
Where I work we have over 40,000 Unix (or Unix-like =) servers and only about 2,000 of them have some kind of NFS-mounted home directory setup. Those servers are managed by about 37 different IT organizations across the planet but nearly all of them (except those in DMZs and special restricted environments) can be logged into via user's Active Directory accounts. There's literally hundreds of teams of sysadmins, DBAs, and application administrators of varying sorts that administer their respective things across a wide variety of geographic locations and organizations. There's not a single admin team that has access to everything the other teams have access to. Also, there's a number of servers that you can't just login to (to make a change) except during special maintenance windows on the weekends (don't ask--super duper restricted--all sorts of alarms would go off and regulators would probably storm in, LOL).
I have friends that work at other big businesses with similar situations (tens of thousands of servers with accounts managed via AD/LDAP). When an employee leaves the organization, how do you propose you disable their access? With key-based authentication you need to visit every server they ever logged into to make sure their authorized_keys file is disabled. With password-based authentication you only have to disable their account in AD/LDAP (it's a cinch!).
I can go on and on about this topic... Especially in regards to Kerberos authentication, 2-factor methods, and whatnot. But the point I'm trying to make is that key-based auth isn't the be-all, end-all to SSH authentication that you're making it out to be.
There's nothing stopping you from running Gate One on port 80 with SSL still enabled. Your proxy might block the tunnel but it's worth a shot.
By default Gate One runs all sessions through the dtach program which is like a mini version of screen... So you CAN resume a session started from Gate One via some other connection method (e.g. traditional ssh). I really need to document how to do this because it is a pretty cool feature.
So I guess I should've made the website selling the product first before making the actual product? Do you work for Microsoft?
I haven't set the website up yet (which is why I didn't link to it anywhere but a few places in the docs). There's also a note on the Github page saying this.
Believe it or not, I have this in the TODO for Gate One 2.0. It will require implementing the X11 protocol in JavaScript using the canvas element. It shouldn't be too difficult... Just extremely time consuming. Which is something I don't have much of these days.
Gate One is meant to run on a server. As in, you setup a Gate One server on your network and then you connect to it from a client machine (Windows works fine for this). Another way it can be used is on a server... As a backup in case the SSH daemon stops working or, say, to embed a terminal into a web-based administration interface.
Of course, you could run it on your desktop and use it like a traditional SSH client (I do it every day when I'm working on it) but it wouldn't be as useful.