Tag Info

Hot answers tagged

9

Security wise you want people to use sudo not su (Sudo can be setup so it logs all activity, a.k.a. an audit log). further more on most *nix root access to ssh is prohibited (Setting in the settings file that I would recommend you enable). this is to prevent a breached SSH(-server) can be utilize for ROOT access. Further security I would recommend is use ...


6

Forwarding ports is NOT inherently dangerous in itself and YES the safety is dependant on the service at the target port. But safety also depends on how good is your router's firewall and how well it is protected, both internally and externally. For remote access, both SSH and VPN works as good as each other. Neither is more secure than the other when ...


6

There are several differences. First, by setting up your API server to accept username/password (as opposed to only allowing access via keys, which is increasingly a best practice to do) you potentially decrease its security in general, as, now, users with weak passwords on the system (or, worse, services that you install which may have hardcoded default ...


4

OpenSSH is unaffected by FREAK for several reasons: It only uses a small, carefully-audited portion of the OpenSSL library. The SSL cipher-negotiation code is not one of the parts it uses. The SSH protocol is resistant to "downgrade" attacks: the size of the server key is fixed at the time of key generation and the key fingerprint is stored by the client. ...


3

It's all about managing a risk - as with all such things. If you routinely do everything as root, I'd suggest that's your problem, rather than the login mechanism. Why? Well, because you're doing everything with a maximum level of privilege. That suggests you haven't set up your permissions and ACLs appropriately. Ideally no one should ever 'work as ...


3

You're correct about how the passphrase works. And, given your situation, I'd advise you to not use an SSH agent. You should also be aware that if someone with root access installs a keylogger on your machine, your passphrase may be compromised. To reduce the risk, you can keep the key on e.g. a USB stick, instead of on the local harddrive. For extra ...


2

Short version: Your solution sacrifices logging and auditing accountability, just so as you're aware. If direct root login is a problem, use a generic non-admin user to ssh in and then sudo to root. If you want to be clever, configure sudo (via pam) to prompt for a human-specific username and password so that local privilege escalation is tied to the ...


2

I recommend that you do not permit direct login as root via ssh on any system. As mentioned in gowenfawr's comment above, it is better to have personal accounts for everyone who will be administering the system on all of the nodes, and give them access to sudo to root locally. They would not need a root password on any node for this; they would use their own ...


2

It sounds off that a service provider will not give you details of the product/service you are purchasing. That is like a contractor not telling you what wood he is using to build a house. I would remind your service provider that "security by obscurity" will not help a remote attacker from figuring our or just launching attacks against all versions of SSH. ...


2

the diffrence comes from the locking / nonlocking random beeing used (e.a. /dev/random and /dev/urandom) from the Manpages of ubuntu 14.04 (man random) NAME: random, urandom - kernel random number source devices SYNOPSIS : #include int ioctl(fd, RNDrequest, param); DESCRIPTION : The character special files /dev/random and /dev/urandom ...


2

I agree that it would be nice to have this site available by https so that the transport from the site to the user is protected. But I think one should put this risk into relation to the risk which remain even if the site has https: How did you know that you must visit winscp.net and not another site like winscp.org (ads), winscp.com, download-winscp.net ...


2

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password (passwd -de). That way users get prompted on their first login and can choose their own passwords. I ...


1

OpenSSH - Line 3090:sshkey.c:sshkey_private_to_blob2 if (strcmp(kdfname, "bcrypt") == 0) { arc4random_buf(salt, SALT_LEN); if (bcrypt_pbkdf(passphrase, strlen(passphrase), salt, SALT_LEN, key, keylen + ivlen, rounds) < 0) { r = SSH_ERR_INVALID_ARGUMENT; goto out; } if ((r = ...


1

What can I do to prevent described attack? WinSCP installer binaries are signed with Authenticode, so you should be able to right-click-properties the .exe and check the signer. Of course you would have to know that Martin Prikryl is the legitimate author, and you would have to trust Verisign to have made sure that's who it really is, and you'd have to ...


1

Keep in mind that there is no way to tell from the public key alone whether the private key even has a passphrase associated with it, and no way to know what the passphrase is or when it was last changed even with access to the private key (although a good guess may be that if the private key has been rewritten per its last modified timestamp since it was ...


1

Interesting topic, for me the safest is password, I use 4 different passwords for different things depending on the security required, for example for a site like this I will use something like (mexico1970) which I dont care if it gets cracked since I just post to the site and there is no credit card info or any other important info to protect, then I will ...


1

Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop. Yes, true, if someone gains full access to your machine, you are in trouble either way. Am I missing something here? Yes. ...


1

Well, if you drop the idea for username/password (that is not secure at all for this use) you could implement a chrooted environment for the ssh-client to connect into. using ECDSA or RSA Public key encryption, (you ship the private key with the app, and store the authorized keys outside of the chroot). Especially if you make a "dropbox" for the clients to ...


1

Simple answer, no. SSH keys are simple cryptographic keys, if you want to add a validity period to it, you end up in PKI territory. There is an answer on the Ubuntu Stack Exchange site, asking how to make SSH keys expire automatically, but this is to do with using the ssh-agent tool. Alternatively, you can use a third party app installed on your server to ...


1

Can someone clearly highlight why this is not recommended? Because any running service is increasing your attack surface. Especially with network capable services, you're always exposed to danger. I don't think anyone can give you a more specific answer than that, since the SSH implementations tend to be quite OK from a security standpoint. Nevertheless ...


1

I always had a problem with SSH keys when I was a QSA. Mainly because people basically build them once and then ignore them. As a penetration tester there are many ways to gain access to systems. The easiest to me was always to gain access to a system admin system with ssh keys, or use a browser or other local exploit (phishing attack) to extract the keys ...


1

What you want is "Upstream SSL". This is when you re-encrypt the backend connection with Nginx. You don't need to buy another certificate. You can use self-signed certificates for the backend. Discussed here: StackOverflow: Nginx load balance with upstream SSL and here: ServerFault: Configure Nginx as reverse proxy with upstream SSL Blog here: "SSL ...


1

It depends... you can set things up so the commands are recorded on the client side. By default the sent commands are not logged by the client though, if that is your question. A much more common configuration (security-wise), if audit logging (via pam or some such method beyond just simple ~/.bash_history) was enabled they would see that ssh was run and ...



Only top voted, non community-wiki answers of a minimum length are eligible