Live data from Hacker News

SSH Kung Fu

blog.tjll.net

121–130 of 133 posts

Re: SSH Kung Fu

#121
post #72

Earlier quoted context omitted.

"Blocking SSH access is not required meet that compliance requirement." Read up about SSH VPNs. Probably some kid set up a proxy accessed over SSH port forwarding, to access some pr0n site, got caught, and next thing you know, no SSH allowed anymore. If they were really smart they'd allow it but rate limit it to 2400 bit/s, which is fairly fast for console work but not so great for downloading animated pr0n gifs. Wha…

The library has an obligation to make a good faith effort to meet whatever compliance requirements that they are faced with. That's it. It isn't a bank or military installation. If the original poster brings in an air card, and starts watching porn with the volume cranked up, the library doesn't have a right or obligation to jam the cellular network. They do whatever their policy calls for (usually ask the guy to lea…

Cheers for your thoughts. I suspect the UK public library authority I would have to appeal to would have zero motivation to help with SSH access, unfortunately. I imagine it has been blocked for a specific reason, probably some previous or expected abuse, as you've both mentioned.

The SSH over SSL solutions others have pointed out may do the trick for now.

Re: SSH Kung Fu

#122
post #13

A trick I learned recently: create .ssh/config File format: as many of the following blocks as you like Host $ALIAS You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.

Sadly, this doesn't work always. Some apps which implement their own ssh don't support ~/.ssh/config. For example, the OSX Subversion GUI client Cornerstone doesn't support this.

Re: SSH Kung Fu

#123
post #33

One problem I have with SSH is DPI. Deep Packet Inspection seems to be behind the SSH block in place at a local library I work at. SSH out in any form just isn't possible there, even via a browser-based console (such as that used by Digital Ocean, for example). There doesn't seem to be a suitable solution to get around it offered anywhere. My own fix was to use 3G to do the SSH work via a tethered phone and to use th…

Try setting the sshd port to 443

Re: SSH Kung Fu

#124

Earlier quoted context omitted.

Did you ever stop and think about this or are you just repeating something you read on "Hacker""news"? Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it. Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".

Why do you need root access for scp? Just scp the file as a regular user and then use sudo to copy it into place.

tl;dr: "disallow root login entirely, everything else is bad" is cargo culting.

I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2]

And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1]

Also, I prefer my normal user account not to be a sudoer at all.

Besides, please consider that disallowing root access actually only gets you protection against root password guessing anyway. The "stolen key + passphrase" scenario in a sibling subthread is so absurd I felt the urge to bang my head against my desk. Sudo won't help you there either.

[1] Now please don't suggest "passwordless sudo".

[2] And there is another inelegance: /home is usually on a different partition than /, so your way will involve an additional copy. If /home is even large enough to fit that file.

Re: SSH Kung Fu

#125

Earlier quoted context omitted.

Why do you need root access for scp? Just scp the file as a regular user and then use sudo to copy it into place.

tl;dr: "disallow root login entirely, everything else is bad" is cargo culting. I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2] And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1] Also, I…

[1] Why shouldn't I suggest it? Apparently it's obvious, so it would be nice to share. [2] I'm not sure where you get that /home and / are usually on different partitions. There's usually the same partition on machines I've administered. But if that is the case, you can find/create a suitable folder on the same partition (/var/tmp/ comes to mind)

I understand you didn't say impossible, but this doesn't really seem to be impractical to me at all.

Re: SSH Kung Fu

#126

Earlier quoted context omitted.

tl;dr: "disallow root login entirely, everything else is bad" is cargo culting. I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2] And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1] Also, I…

[1] Why shouldn't I suggest it? Apparently it's obvious, so it would be nice to share. [2] I'm not sure where you get that /home and / are usually on different partitions. There's usually the same partition on machines I've administered. But if that is the case, you can find/create a suitable folder on the same partition (/var/tmp/ comes to mind) I understand you didn't say impossible, but this doesn't really seem to…

@Passwordless sudo: Because then you have effectively made your user root, and compromising your user account is enough to get root access immediately. If you do that, then why have a seperate user at all?[3]

@Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run.

@Impractical: it's one additional command for something I do quite often[4], and I still don't see the benefit (reminder: I fully agree with never using "PermitRootLogin yes").

[3] Granted, it does provide some context seperation in the sense that if you want to perform an administrative task, you have to explicitly use sudo. But it doesn't increase security, and it offers no advantage over "direct root access + normal user account".

[4] Not just scp, but also things like "less /var/log/messages" or "git clone root@host:/etc".

And again: what does "PermitRootLogin no" gain you over "without-password"? Why restrict it for no additional benefit?

Re: SSH Kung Fu

#127

Earlier quoted context omitted.

[1] Why shouldn't I suggest it? Apparently it's obvious, so it would be nice to share. [2] I'm not sure where you get that /home and / are usually on different partitions. There's usually the same partition on machines I've administered. But if that is the case, you can find/create a suitable folder on the same partition (/var/tmp/ comes to mind) I understand you didn't say impossible, but this doesn't really seem to…

@Passwordless sudo: Because then you have effectively made your user root, and compromising your user account is enough to get root access immediately. If you do that, then why have a seperate user at all?[3] @Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run. @Impractical: it's…

I'm not really on one side of the argument or the other, but disabling root login means that an attacker doesn't automatically know the name of an account where login is permitted for one. Certainly not the best security mechanism, but if there happened to be some 0-day on the SSH server, you're much more likely to be safe from automated attacks.

Re: SSH Kung Fu

#128

Earlier quoted context omitted.

@Passwordless sudo: Because then you have effectively made your user root, and compromising your user account is enough to get root access immediately. If you do that, then why have a seperate user at all?[3] @Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run. @Impractical: it's…

I'm not really on one side of the argument or the other, but disabling root login means that an attacker doesn't automatically know the name of an account where login is permitted for one. Certainly not the best security mechanism, but if there happened to be some 0-day on the SSH server, you're much more likely to be safe from automated attacks.

Automated 0-day attack: fair point.

Though direct remote code execution is probably much, much more likely than authentication bypass.

Re: SSH Kung Fu

#129
post #98
post #58

Earlier quoted context omitted.

Because a potential intruder is more probable to try "root" than "akerl_35" to get access. It's no big deal to login as any other user and then use sudo (if needed) or even su

If a potential intruder knowing what username to use helps them bruteforce your SSH, then the problem is with the entropy of your password, not your choice of username.

[deleted]

Re: SSH Kung Fu

#130
post #98
post #58

Earlier quoted context omitted.

Because a potential intruder is more probable to try "root" than "akerl_35" to get access. It's no big deal to login as any other user and then use sudo (if needed) or even su

If a potential intruder knowing what username to use helps them bruteforce your SSH, then the problem is with the entropy of your password, not your choice of username.

Yes, but it's easier to teach admins to never use "PermitRootLogin yes" "because it's bad for security" than to teach them to never use weak passwords.
Post reply on HN