I have absorbed like 3 years worth of your videos these past few weeks and they have been fascinating. I love your content and keep up the great work! I look forward to being part of this community :) This video specifically has been spot on what I have been looking for too, so I really appreciate the variety of content you provide. I'm getting ready to setup my homelab environment and am very excited! I wish this got me hooked 10+ years ago instead of gaming, but this was much more boring then :P but now im so engrossed into the topic!!
nice video as usual, i would like to add two things: a) more secure would to let the user‘s forward their ssh agent through the jumpbox and use their individual keys to authenticate to the servers (they are allowed for). distribution of ssh public keys for the allowed users of the machine could easily be done with some scripts and a (even more secure) ssh management server. this you can manage the access per user for every machine b) i guess you would want a backup jumpbox
I knew how to setup ssh keys and authentication, but I didn't know you could do this. In fact, just about a few months ago I didn't know ssh config file was a thing. Now this is cool. I have about 5 Pi's at home with a debian webserver and one digital ocean VPS. Be cool to have one channel of communication.
Thanks Tom, I enjoyed hearing about how you use a jump server. I would recommend that you have a look at SSH certificate authentication, as it solves half the problem in a different way. Both host keys and client keys can be signed by a master key, and hosts and clients can be configured to trust this signature. There are provisions for expiring keys and so much more. I think the jump box is still a handy tool, but I think I'd still prefer to start from a certificate based system.
I debated about making a second video about using SSH certificate management, it's not something I use much and the added complexity creates some drawbacks.
Great Video Tom, very useful information as usual! You always seem to be ahead of the curve. I'm sure you already know this but if you are just VPNing from Point to Point wouldn't it be better to use a /30 subnet to keep things tidy, so if your labtop is '192.168.68.2' and the VPN link is '192.168.68.9' they are treated as separate subnets therefore you shouldn't have any issues routing. Keep up the fab work.
I don't use proxychains, I usually just set up a temp ssh tunnel for like 443 etc.. ssh -g -N -f -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -L 22443::443 user@jumpbox
Great video! Have you ever thought of using something like a smartcard or hsm to store securely the private ssh key from the jumpbox? That way, you would eliminate the risk of someone copying the jumpbox's private key.
There's actually quite a few different options for securing keys but for brevity of the video I did not cover all of them. Maybe I'll make another video on that topic. ;)
@@LAWRENCESYSTEMS Please do. My first thought when you suggested that you could just remove a user's private key from the Jumpbox's authorized_keys file was that anyone with access at any time to the jump server could just copy its private keys and bypass the Jumpbox. Obviously this could be mitigated with firewall and host-based SSH rules, but a concern nonetheless, right?
I see what you’re trying to do. I learned what a jump box is today. Why not configure an LDAP server like FreeIPA to manage users, groups, objects and permissions? I understand FreeIPA also manages ssh keys, too.
The question I would have is if everyone is authenticated to the jump box and traffic goes from box to server, does it do a good job logging user actions once they are Authenticated?
I remember that you have a dynamic IP at your home and how are you getting VPN access to your home server when you have a dynamic IP. Can you please do a video on this topic?
What about using Identity Management Software (like FreeIPA for exemple) to manage Users & Keys? Keys are stored on the IDM and managed there. A user quits, just delete his account on the IDM, and bam, he can't logon anymore and his key don't work anymore. Key compromised, revoked it on the IDM, and replace it with the new one, and bam, key has been replaced on every server on your domain.
If every user has access to the same no user, this user should not have read access to the authorization keys. With sudo you can pivot to a different outgoing user. But that does not allow to see the actual idendity on the target servers..
