211–220 of 311 posts
Another question, can this be used to create SSO-enabled SFTP? Isn't SFTP just ftp over SSH?
SFTP is a sub-protocol of SSH (technically a "subsystem" in the RFC-speak), which implements features similar to "legacy" FTP. Anyway, our ssh server knows about sftp, so `sftp ` should just work.
Can’t wait to try this.
Earlier quoted context omitted.
Ohhh, this explains why my corporation placed a total firewall block on the Tailscale website. This is a postmortem-worthy incident on Tailscale's part.
If you're not already using Tailscale, with your security or IT teams controlling it, it would be malpractice to allow it on a controlled network. No competent security team allows people to introduce their own VPNs.
I'm one of the authors of this. Happy to answer any questions. One of the fun technical details is that, when enabled on a machine (tailscale up --ssh), the userspace tailscaled process takes over all TCP port 22 packets after the WireGuard decryption and doesn't even feed them into the kernel over TUN. We use gVisor's netstack to handle the TCP connections in-process. So it doesn't matter whether you have other proc…
Hey bradfitz, guy who previously had 32150 here. :-) This looks insanely cool, a couple questions: I know it says it's linux-only right now, but is that client side or server only? Can my Windows users TailSSH into linux boxes? Would be cool if somehow it could wedge into sudo auth so you could login as a a user and sudo without password if allowed by ACLs, especally if I could add "check" to the ssh. agent pam modul…
Minor suggestion, for future and new users, is it possible to get a calculator where you could input the number of users you expect, the number of servers you want to include, expected unique ACL's and provide you an ETA of what your license cost would be?
Earlier quoted context omitted.
In this case, double encryption is a good idea though. Tailscale is a great way to reduce exposure of your infrastructure from the public internet, but it’s not without flaws. In theory, it should be possible for Tailscale and your SSO provider to add new nodes to your Tailnet. Though I don’t believe this is something that they’re actually willing to do, it’s definitely something to keep in mind if you’re planning on…
Double encryption doesn't actually help in that case though - if tailscale (maliciously) added nodes to your network the ssh session being encrypted wouldn't change the fact that they can run commands on your machines. And if they wanted to actively MITM you they could do so (by redirecting your wireguard connection to a server owned by them) even with encryption (presuming they can fake the host key, which they coul…
Also for Linux, the Tailscale client is fully open source and I obtain the binary from the distro. I find that a bit reassuring.
Earlier quoted context omitted.
> This lets people gradually use Tailscale SSH over time without messing with their system one. That is something I have really appreciated about Tailscale. It seems to consistently not mess with the existing environment. Considering it does networking witchcraft and it works on a variety of architectures and OSs this is quite an accomplishment. I suspect Tailscale's customers have found the same.
That is not a feature it is a bug and a big hole. The firewall is the system. Just like apple bypass its own firewall and just send packet back home. Or the chinese way. Of course as said by one of the author the key is to control port 22 or rule for ssh. That is not a totally lost. Still, one that is ok … you are breaking the system by promoting a way to bypass it. Or just 1 rule. It is so hard to remember.
Earlier quoted context omitted.
I'm curious, what's really clunky about SSM? Other than ensuring the pre-requisites are met, and knowing the instance-id, SSM works pretty flawlessly. You can easily write a wrapper that looks up the instance-id from the hostname, if you prefer to use it that way.
Haha I'm not sure if you were being serious, but the workflow you just outlined is the clunky part of SSM. The pre-requisites are getting all the IAM roles and permissions setup (no mean feat), installing the agent, configuring it with keys generated by another user, and getting the connection information back from the aws console. This promises to be a lot easier to setup and authenticate, install tailscale, login.
I made two scripts, one in .Net with a GUI for non-devs to grep a server hostname or tag:name in AWS that resolves to an instance ID for SSH or RDP. And another python script doing the same but without the GUI for the dev team. Works a treat.
But you've already explained why it's a little tedious and now I've documented and understood why. Tailscale MagicDNS does all this nonsense for you. Yeah ok thanks for rubber ducking me I see your point now. :)
Earlier quoted context omitted.
That is not a feature it is a bug and a big hole. The firewall is the system. Just like apple bypass its own firewall and just send packet back home. Or the chinese way. Of course as said by one of the author the key is to control port 22 or rule for ssh. That is not a totally lost. Still, one that is ok … you are breaking the system by promoting a way to bypass it. Or just 1 rule. It is so hard to remember.
No, it's not. Network access control is the whole point of Tailscale; it is the network filtering layer. It serves literally the same function that a Checkpoint Firewall-1 installation would have in 1997, and that's why people buy it. This is basic stuff from the Tailscale website; it doesn't even qualify as analysis. You really ought to understand how these things work before you describe things as "big holes".
This seems like the perfect complement to replace the SSM Agent / bastion instance currently used to access AWS VPC (it is super clunky to use). This should allow an easier time to do reverse tunnelling to databases without having to manage SSH keys.
Hmm AFAIK you don't need a bastion to use SSM agent - it even allows you access through the browser. I think you meant EC2 Instance Connect which manages temporary SSH keys.
So for our RDS instances and containers in ECR we use a bastion which IMO is a lot easier to manage.
This seems like the perfect complement to replace the SSM Agent / bastion instance currently used to access AWS VPC (it is super clunky to use). This should allow an easier time to do reverse tunnelling to databases without having to manage SSH keys.
That feature was recently added to SSM https://aws.amazon.com/about-aws/whats-new/2022/05/aws-syste... Using something like gossm which I just put a PR in for this feature also makes this easier https://github.com/gjbae1212/gossm/pull/54
Earlier quoted context omitted.
If you're not already using Tailscale, with your security or IT teams controlling it, it would be malpractice to allow it on a controlled network. No competent security team allows people to introduce their own VPNs.
Speaking of which, how would they detect it?