Ever wanted to use SSH to connect to an embedded Linux system over the serial port instead of suffering through some janky login program that supports very limited terminal features?

Well, I did, and the tooling didn't exist, so I made it.

It also supports ppp automatically.

cc @AMS @chaos

https://github.com/ryancdotorg/ugetty

GitHub - ryancdotorg/ugetty: A modern, lightweight, multi-protocol getty.

A modern, lightweight, multi-protocol getty. Contribute to ryancdotorg/ugetty development by creating an account on GitHub.

GitHub
@ryanc @AMS @chaos huhhhhhhh. neat. if we did things that way we could use scp instead of our current workflow, which uses xmodem.
@ryanc @AMS @chaos (we don't trust our own LAN, so we have a workflow for bringing up new machines using the serial port)
@ireneista
That is an interesting trust boundary. I’m curious what makes you draw the line that close
@ryanc @AMS @chaos
@c0dec0dec0de @ryanc @AMS @chaos well, because it's been clear to us for a long time that there's a lot of stuff on any home network that absolutely does not deserve trust. we feel like recent botnet-router stuff has validated this approach, but at the time we started doing this that was a purely theoretical concern... we just felt it was clearly an important one.
@ireneista @c0dec0dec0de @ryanc @AMS @chaos I like this. Even though I run my own NAT router / DNS / DHCP / et cetera, I don’t trust consumer devices on the same network. Corporations these days seem anti-security, which is to say they’re the ones actively doing evil things that we need to guard against.
@AnachronistJohn
I wouldn’t trust the software on my smart TV, but I don’t see an alternative to trusting my router and switches to route packets properly. I can see only trusting point-to-point comms between devices to an extent, but at done point I feel like I’d be chasing an elusive root of trust. Do those devices need to be running chipsets that I understand? If so, I’m fucked. I’m not Bunny Huang.
Understand that I’m not trying to argue against whatever your threat model is, just say that I’ve considered not trusting the DHCP server and the string parameters it passes in an ostensibly closed system and the engineering team decided that if you got that kind of toehold on the network, you could take the machine because there wasn’t any point in putting further effort into securing against that threat.
@ireneista @chaos @AMS @ryanc
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc well, like, trusting them to route properly is a different thing from trusting them not to infect our other stuff
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc happily our personal infrastructure is a lot smaller than most corporate infrastructure. it's possible we're fooling ourselves that we think we can defend it; we won't know until too late. we do tend to think that there being less to defend is helpful.
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc also the toehold reasoning sounds like it might be assuming human attention from the attacker, and we don't think that's a valid assumption if so
@ireneista physically separated network with very limited outside communication, most nodes booted from write-protected flash and got further instruction/software load from a central server. If you owned the server, there wasn’t a lot we could do on the nodes that we were comfortable doing. I mean, we could have converted it into an open problem of key management (probably the correct thing to do), but the organization was really not prepared to do that.
@AnachronistJohn @chaos @AMS @ryanc