@jaredbusch said in sudo problems:

@pete-s said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

I don't know what @scottalanmiller uses but ssh-keygen is used to generate ssh certificates as well.

From the man page:
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

But if you are automating certificate generation, you need to wrap this in something.

No, ssh-keygen does not do this (ssh certificate generation).

As you highlight, it can be used as part of the certificate process. But it cannot, and never will, be the certificate authority. Thus it is not the tool for this this.

You're actually mistaken because I've done it many times now. A Certification Authority, when it comes to openssh certificates, is really just a key pair that you carefully guard.

You create certificates by using the CA keys to sign other public keys from users and hosts. The result is a certificate named *-cert.pub

And you do all of this with the ssh-keygen utility.

Similar to how you can create CA and everything else for the more complex x509 certificates with just openssl.

OpenSSH can use host certificates to verify the host (like SSL certs on a webserver). OpenSSH can also use user certificates to verify the user (like passwords or ssh keys).

Both these types of cert to be used independently of each other.

I've tested using user certificates to authorize user login, since that is what most
people do with keys. People never really verify the host identity.

It works great and it's actually very simple. This will be my new SOP going forward.

Before starting to add hosts and users you need to create a Certificate Authority (CA) - which is actually just a key pair. It's a one-liner.

Every time you create a new host, you just need to copy the same file to it - the public key of the CA. And change one line in sshd_config to allow ssh certificates.

Every time you have a new user on your team who need access to servers, you have to generate a certificate for him. It's a one liner. He will copy the certificate to his own machine. And the ssh client will automatically send the certificate when needed.

Generating certificates is the part that could be automated. You could for instance be given a certificate that expires in 5 minutes. That would allow you to login and stay logged in. But if you need to login again, you need to generate a new certificate.

@scottalanmiller that is edgeos syntax.

Thanks, guys. It's actually the most logical solution that the ssh client side decides what keyboard layout to use.

So maybe I was mistaken then or it was something else that was off. I'll give it try with some different settings to verify how it works.

@ing-joserivera26 said in VitalPBX 3:

I will not continue posting on your blog.

This is not my blog. This is an public community targeting IT professionals.

I would (and have) posted on the VitalPBX community, but it seems that i'm eternally moderated.

@krisleslie said in Linux Copy a Disk Over SSH with DD:

@scottalanmiller can this be used while on XCP-NG host?

Can be used on every non-Windows system.

@stacksofplates said in Termius cross platform sync:

@scottalanmiller said in Termius cross platform sync:

@stacksofplates said in Termius cross platform sync:

@scottalanmiller said in Termius cross platform sync:

@JaredBusch said in Termius cross platform sync:

@stacksofplates said in Termius cross platform sync:

@gjacobse said in Termius cross platform sync:

@stacksofplates said in Termius cross platform sync:

@IRJ said in Termius cross platform sync:

Remina is great on Linux platforms, but the question for me is why is this a need?

This seems like everyone could and should manage this independently. All you need is DNS name or IP to initiate a remote connection. In my opinion, it's better for IT team to know exactly where they are trying to go instead of clicking the wrong button or sending the wrong command

Yeah I agree. I'm assuming it's for syncing credentials across devices. Which means you'd have to trust their cloud service with your system credentials.

While yes, it would be nice to sync the entire session - connection and UserID / password. I'm more concerned with the connection itself. Yes, I can keep track of the addresses - but it gets to be a pain.. UserId / Passwords are different. I could care less - I mainly want the address; IP address or dns name..

I mean, honestly what's the difference between a word document/text file and the syncing at that point?

Right. An besides, even Windows has native SSH now. So why use anything else anyway?

Right, I've not used PuTTY in quite some time. Not that it isn't good, I just don't see the point of installing third party software that doesn't do anything any better than the built in tool that is always there and ready to go. And quite frankly, I find PowerShell's terminal to work far better for me.

I can't stand PuTTY. I'm not sure why, I've just always hated it.

I hate that it lacks a local shell and you have to launch the damn thing for every connection!

Maybe that's what it is. Tunnelling is a pain, I just find it awkward.

That, too. Other than doing a good job rendering fonts and being available back in an era when nothing else was, PuTTY really doesn't offer anything positive.

@JaredBusch said in Keep my ssh config file synchronized between two systems:

@stacksofplates said in Keep my ssh config file synchronized between two systems:

I use git for this type of stuff. I have all of my dotfiles stored in a git repo and synced between systems.

I thought about that, but then it gets into git triggers and scheduled jobs.

I just do it when I open my terminal. It auto downloads when a new window is opened.

uptodate.png

@Pete-S said in sftp without ssh shell access?:

Thanks guys.

To summarize the link above, it's these lines in sshd_config that does the magic.

Match User sftpuser ForceCommand internal-sftp <snip>

The first line will tell sshd what user(s) the rest of the settings apply to.
The second line tells it to go straight into sftp mode. So this will only apply to the users that match the rule above.

Just make sure to test SSH after you do the changes ok a new session otherwise you might just have broken SSH access.

@stacksofplates said in Securing SSH:

Another really good option is not letting them log directly into the systems at all and forcing them to use a config management tool. So something like Tower or a Jenkins server that logs all of the commands run and has the permissions set there.

Right. Just like the best defense is a good offense (or vice versa?) The most secure port, is a closed port. Locking down SSH, no matter how good, isn't as good as completely closing it.

Or using config management to only open it when necessary, is an "in between" step, too.

I've already used this guide again. LOL, boy this is handy.

@dafyre said in How to mount remote filesystem over ssh (both Windows & Linux):

@black3dynamite said in How to mount remote filesystem over ssh (both Windows & Linux):

@dafyre Installing sshfs and winfsp via choco is older than the ones from GitHub.

If you installed them via choco do this to mount at the host root directory or other directories.
https://github.com/billziss-gh/sshfs-win/issues/102

Host root directory
\\sshfs\[email protected]\..\..

Specific directory like /var/www
\\sshfs\[email protected]\..\..\var\www

Thanks for the pointer. I did install using choco. I'm able to make it work now.

Edit: Just to see if I can, I may go back and do straight installs.

As I said above with the latest version I mount the root directory with \\sshfs.r\[email protected]

However, if you want to mount another directory like /var/www you have to do:
\\sshfs.r\[email protected]\var\www\
The trailing \ is very important!
It just doesn't work without it if your path is more than one directory deep. You also need to use backslash and not the forward slash.

@black3dynamite said in Copy SSH public key to ssem behind a jump box:

# From your host to your JUMPBOX # Not needed if your public key is already in placed cat ~/.ssh/id_ed25519.pub | ssh jump.domain.com 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys'

ssh-copy-id should do this

@Romo said in Does Windows 2016 Server have SSH?:

@Pete-S start and type winver

Awesome!

Unfortunately it's a version 1607 build 14393.3243.
So I can't install with powershell according to the article above.

@JaredBusch said in SSH Access to Windows 10 Pro Workstations:

@DustinB3403 said in SSH Access to Windows 10 Pro Workstations:

@scottalanmiller said in SSH Access to Windows 10 Pro Workstations:

On Server, no issue. SSH the same as with Linux. SSH on Windows 10 is "single user" just like anything else on Windows 10.

So then why would they have the statement about "usually to correct problems" as to me this would be a two person use. One who is using the desktop and the other administrator who is working on fixing an issue via ssh (presumably while the other user is using said system).

I'm not bothering to reread anything, but MS has long allowed admin connections.

Yes this has been a known fact for as long as i can remember... Admins are exempt for administrative purposes.

@scottalanmiller said in Why does some key combinations not work over ssh?:

@Pete-S said in Why does some key combinations not work over ssh?:

@scottalanmiller said in Why does some key combinations not work over ssh?:

So the issue is that SSH uses the ASCII definitions for what can be passed, and things like Control-Shift aren't defined in the ASCII C0 control set.

https://en.wikipedia.org/w/index.php?title=C0_and_C1_control_codes&oldid=869654887#C0_controls

So they aren't passed because they aren't part of the character set of the protocol. So yes, it's SSH not passing it because it doesn't exist to SSH :(

That's too bad.

Do you have any link where it says that ssh uses these definitions? Maybe there is a way around it.

Can't find one, not with OpenSSH. Tectia supports it, but is crap in general. If you search on it, everyone talks about the ASCII limits of SSH. You'll find SFTP / SCP have the ASCII / Binary option for connections because of the underlying ASCII protocol in use.

Thanks, I'll dig around and see if I can find something. Otherwise I'll just have accept that it is what it is :)

@scottalanmiller said in Tracking Down Ubuntu BASH Session Closing:

@matteo-nunziati said in Tracking Down Ubuntu BASH Session Closing:

@scottalanmiller said in Tracking Down Ubuntu BASH Session Closing:

If I use zsh, I'm good. If I enter BASH from zsh, I get kicked out after several seconds. Definitely is something to do with BASH.

Stupid tryout: use bash and then enter zsh before being kicked out. Still out?
To understand if it is the firing of bash itself or the stay in bash...

No, the underlying bash remains until the ZSH closes. Same as if you were running top from it, for example.

So basically bash is able to run long running jobs with your user...
It's the interactivity with the shell to be broken... Meh.

Sorry the thread is long, did you mention any test from zsh with:

Bash <-- ok this kills the session
Bash -i any difference???
Bash -l ???
bash --norc
bash --noprofile

From bashman page

@JaredBusch said in VPS injected ssh keys:

Under no circumstances do I actually want anyone's key tied to the root user. It negates all accountability.

It's for pre-production setup. Not for deploying straight to production.