What Are You Doing Right Now
-
@thanksajdotcom what did the issues look like? Problems posting?
-
@scottalanmiller said:
@thanksajdotcom what did the issues look like? Problems posting?
Notifications and unread numbers not updating when you open the thread that's unread or the notifications, etc.
-
That would make sense, if logging was failing those things would fail too. The site was working fine, but not recording the views, when I signed in. So clearly some things were working. I'm hoping that posting was working. I've not come across a post that I know was posted during the window, but that would be easy to miss.
-
@thecreativeone91 said:
Installing Zimbra on CentOS 7 and Seafile on another instance. Next project will be a jump box (possibly local)
Jump box? curious....
About to head out to a remote office,.. just put my phone on DnD...
-
@g.jacobse said:
@thecreativeone91 said:
Installing Zimbra on CentOS 7 and Seafile on another instance. Next project will be a jump box (possibly local)
Jump box? curious....
About to head out to a remote office,.. just put my phone on DnD...
That's the first thing that we built on CloudatCost. We had a self-hosted Jump box in our Mississauga datacenter which is scheduled for decom. So we needed a new one, the timing was perfect. Since you typically do not want a Jump box in a datacenter with your other production workloads (at least I prefer not to unless you are a single location facility) it was a perfect use for CloudatCost which was new to us.
Using a Dev1 is perfect for that. You'd need to be a massive organization for that to not be plenty of horsepower. We could make do with nearly half the resources of the Dev1 for that.
We used CentOS 7. Only option packages are the LogStash Forwarder for ELK, SysStat, htop and, of course, Fail2Ban which is super critical on a Jump box.
-
@scottalanmiller said:
@g.jacobse said:
@thecreativeone91 said:
Installing Zimbra on CentOS 7 and Seafile on another instance. Next project will be a jump box (possibly local)
Jump box? curious....
About to head out to a remote office,.. just put my phone on DnD...
That's the first thing that we built on CloudatCost. We had a self-hosted Jump box in our Mississauga datacenter which is scheduled for decom. So we needed a new one, the timing was perfect. Since you typically do not want a Jump box in a datacenter with your other production workloads (at least I prefer not to unless you are a single location facility) it was a perfect use for CloudatCost which was new to us.
Using a Dev1 is perfect for that. You'd need to be a massive organization for that to not be plenty of horsepower. We could make do with nearly half the resources of the Dev1 for that.
We used CentOS 7. Only option packages are the LogStash Forwarder for ELK, SysStat, htop and, of course, Fail2Ban which is super critical on a Jump box.
So a jump box is basically a way to get from the internet into the admin side of your intranet? I guess I'm not sure I understand what a jump box actually is.
-
@coliver said:
So a jump box is basically a way to get from the internet into the admin side of your intranet? I guess I'm not sure I understand what a jump box actually is.
Technically a Jump box is not related to Internet vs. other network. It is a term for a remote access proxy aggregation. In the UNIX world, which is really what we are implying here, it is an SSH proxy 99% of the time. But in theory we could have it as a remote X2Go station. But, you can assume we mean an SSH proxy. In the Windows world they are less common, but still common and well known, and almost exclusively are RDP proxies.
The purpose of a Jump box is a combination of access, access control and security. A Jump box, sometimes called a Jump station, is a gateway for access to other systems. As we are hosted across the world in many datacenters, we use one on the Internet, but lots of companies use them internally and they have nothing but private IPs.
How we use a Jump box in the UNIX world, and you can easily extrapolate for Windows, is to make a very light and lean machine with absolutely no services except for SSH. (Obviously we have normal monitoring on there.... log monitoring and stuff for security.) This system allows any of our UNIX users to log into it. It is heavily locked down, none of the normal user accounts that would have admin access have it there. Even the admins are end users on the Jump box. It is common to log actions heavily on the Jump box to for audit purposes.
The Jump box contains things like the private keys for the users so that they can easily log into the actual servers quickly and easily. It is from the Jump box that the admins or even just UNIX users do all of their work. You always log into it first and from there into everything else. The Jump box would hold your "Screen" sessions.
The normal UNIX servers get the public keys of the Jump box so you can log in without further authentication. This makes working on many servers quick and easy while being super secure. (You can always add more security where needed.) It also allows those machines to lock their SSH access to just the Jump server(s) for added security.
It's very worth it for UNIX users. Makes working in UNIX so much easier.
-
@scottalanmiller said:
@coliver said:
So a jump box is basically a way to get from the internet into the admin side of your intranet? I guess I'm not sure I understand what a jump box actually is.
Technically a Jump box is not related to Internet vs. other network. It is a term for a remote access proxy aggregation. In the UNIX world, which is really what we are implying here, it is an SSH proxy 99% of the time. But in theory we could have it as a remote X2Go station. But, you can assume we mean an SSH proxy. In the Windows world they are less common, but still common and well known, and almost exclusively are RDP proxies.
The purpose of a Jump box is a combination of access, access control and security. A Jump box, sometimes called a Jump station, is a gateway for access to other systems. As we are hosted across the world in many datacenters, we use one on the Internet, but lots of companies use them internally and they have nothing but private IPs.
How we use a Jump box in the UNIX world, and you can easily extrapolate for Windows, is to make a very light and lean machine with absolutely no services except for SSH. (Obviously we have normal monitoring on there.... log monitoring and stuff for security.) This system allows any of our UNIX users to log into it. It is heavily locked down, none of the normal user accounts that would have admin access have it there. Even the admins are end users on the Jump box. It is common to log actions heavily on the Jump box to for audit purposes.
The Jump box contains things like the private keys for the users so that they can easily log into the actual servers quickly and easily. It is from the Jump box that the admins or even just UNIX users do all of their work. You always log into it first and from there into everything else. The Jump box would hold your "Screen" sessions.
The normal UNIX servers get the public keys of the Jump box so you can log in without further authentication. This makes working on many servers quick and easy while being super secure. (You can always add more security where needed.) It also allows those machines to lock their SSH access to just the Jump server(s) for added security.
It's very worth it for UNIX users. Makes working in UNIX so much easier.
Thanks for the explanation, I assumed about half of that but you, as usual, went into far greater depth. Wouldn't having the private keys on this server be an issue? Or is it because it is so locked down and none of the other servers will accept connection coming from anywhere else that this is less of a concern?
-
It's a handy thing to have. I've used it in the past as a way to access my Linux servers via SSH in case I wasn't on a machine that had Pertino on it. I download PuTTY/KiTTY quick, ssh to the jump server via the hostname I setup publicly and boom, I have access to all my internal SSH-accessible devices. And since I have root as the username for all and keys setup, it's super easy.
-
@coliver said:
Thanks for the explanation, I assumed about half of that but you, as usual, went into far greater depth. Wouldn't having the private keys on this server be an issue? Or is it because it is so locked down and none of the other servers will accept connection coming from anywhere else that this is less of a concern?
Nothing is perfect, of course. But the theory is that if you have a single, highly secure, heavily monitored gateway it is far more secure than many less secure, less watched, less monitored systems. And keys are way more secure than passwords. And breaking into Jump server is as hard, or possibly harder, than breaking into the individual servers. So the theory is that it manages to add tighter security overall while also improving ease of use so that people actually leverage the security. It is certainly a compromise, but far better than people putting private keys onto every desktop and laptop that they touch for the same purposes!!
Because you need only log in once and then get access as needed, using a Jump server offers a reasonable chance to implement a super tight key + passphase system for accessing it AND it is a great opportunity to implement two factor authentication. Make people work hard to access that one box, one time. Once in, then doing their work is super easy. It's a great tradeoff between security and usability which, after decades of use, has proven to be one of the most viable compromises in making a system that makes work both easy and secure.
-
@thanksajdotcom said:
It's a handy thing to have. I've used it in the past as a way to access my Linux servers via SSH in case I wasn't on a machine that had Pertino on it. I download PuTTY/KiTTY quick, ssh to the jump server via the hostname I setup publicly and boom, I have access to all my internal SSH-accessible devices. And since I have root as the username for all and keys setup, it's super easy.
We use it even when there is Pertino. We just access the Jump box and then other machines via Pertino on the Jump box. And in some cases, access the Jump box via Pertino too. You could easily make a Jump box that uses the Internet ONLY for patching and Pertino and all access in and out via SSH is on the Pertino network.
-
Or you can use the Jump station as a way into Pertino - access the Jump station via the Internet from anywhere but get Pertino access once logged in.
-
@scottalanmiller said:
@thanksajdotcom said:
It's a handy thing to have. I've used it in the past as a way to access my Linux servers via SSH in case I wasn't on a machine that had Pertino on it. I download PuTTY/KiTTY quick, ssh to the jump server via the hostname I setup publicly and boom, I have access to all my internal SSH-accessible devices. And since I have root as the username for all and keys setup, it's super easy.
We use it even when there is Pertino. We just access the Jump box and then other machines via Pertino on the Jump box. And in some cases, access the Jump box via Pertino too. You could easily make a Jump box that uses the Internet ONLY for patching and Pertino and all access in and out via SSH is on the Pertino network.
Yup, I've done that too.
-
@scottalanmiller I personally have always put in RD Proxies that have to be used to get to other servers. It's much easier for logging who accessed what. It's actually the only thing that saved my butt when I left my last job and they tried to say I sabotaged servers after I was no longer there.
-
Now seeing if I can find a dirt cheap laptop (or maybe a freebie on craigslist) to use. Likely will just run CentOS on it.
-
Just received the best ticket I've had in a while...
On Mar 12, 2015 @ 10:10 am, Christine wrote:
Good morning,This message just turned up in my inbox. I don't recall ever sending a message to Matt Speller. Does this indicate that my computer has a virus?
Christine
-----Original Message-----
From: Mail Delivery System [mailto:
Sent: March-12-15 10:07 AM
To: Christine
Subject: Mail delivery failed: returning message to senderThis message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
[email protected]
retry timeout exceeded -
Darn that Matt Speller.
-
What a virus sending jerk right? Geez.
-
That should be the name of the next big virus.
-
Lets hope not
