Tag Info

New answers tagged

2

The link you've provided does not mention SSH at all. SSH can be easily configured to use username/password and public key authentication. Major SSH implementation allow for the configuration of Kerberos authentication. But SSH does not allow the use of shared secrets for authentication. The protocol itself just doesn't support it. SSH isn't really ...


1

Ensure that /etc/sshd_config contains the following line: PasswordAuthentication no You likely have that line commented out, which allows you to fall back to password authentication. Be sure to restart sshd after you change your config. If you want to install a key from a new computer, you can temporarily comment out that line, install your key after ...


0

You can always connect with the username and password. Pushing a key does not prevent the password from working; the key offers an additional method to open a session on the target server. If you want to "deactivate" password-based authentication, you can replace your password with a huge random one that you do not remember.


5

No. The "random art" image is created by a random walk through the image area, using the key's fingerprint as the sequence of moves to make. The fingerprint is short enough that the art can never cover more than about 40% of the image. An analysis of the art and some attempts at attacks on it are available in the paper "The Drunken Bishop".


1

You could isolate the user network and production network completely from the CDE, such as so a total compromise of the non-CDE enviroment cannot in any way compromise, reduce the security, or in some other way, affect the CDE enviroment. If you do that, then the user network and production network would be considered out of scope of PCI. However, its good ...


8

In SSL, clocks are used for certificate validation. The client needs to make sure that it talks to the right server; for that, the client will validate the server's certificate. Validation implies verifying a lot of things; two of them involve clocks: The server's certificate (and all involved CA certificates) must include the present time in their ...


1

Simple version (for managers): Time syncs can prevent replay attacks. Without them, someone could record the packets sent between client and server, decrypt, modify data, then resend the packet stream and no one would be the wiser. But, because decryption takes time, a timestamp (validated on both sides) can indicate that the stream is a 'replay'. Perhaps ...


1

In my opinion, sudo for server admins is a bit overkill. If people log in, and they have root access (through some mechanism), they usually do maintaining tasks, where they will use sudo for >90% of the time. The purpose of sudo is to give accounts that are logged in some separation between untrusted applications and admin-like tasks, and make users aware ...


1

SSH authentication and security privileges are two different things, hence no point of having it as a default feature. However, it opens one more vector for attack(there is a CVE) and from my point of view makes it easier for users to overuse it, which is bad. On the topic of passwords, one way is to send a short-lived password to the user and require ...


5

In SSH, RSA keys are used only during the initial connection setup. Once you are connected, size of RSA key has no consequence whatsoever on CPU and bandwidth usage for transferring files. The initial handshake uses asymmetric algorithms (RSA, Diffie-Hellman) to handle authentication and setup of a shared secret, which is then used with symmetric ...


0

Tom's answer is spot on but I'll add an alternative snippet for you. Instead of running full blown X, run only the application you need, e.g.: ssh -X yourserver /usr/bin/gimp yourpicture.jpg Or ssh -X yourserver /usr/bin/jdk/eclipse yourscript.jar


2

There is a rather extreme measure, which should work: run a virtual machine on your side. That machine will power some minimal Linux system with X11. You do the ssh from that machine. That way, if the worst happens, the evil people on the remote machine may compromise your virtual machine, but just the virtual machine. (Beware of "guest additions" from the ...


0

It depends on how much additional security you get from the DMZ. In your situation an encrypted TCP socket is basically proxied directly to the LAN. In that case a DMZ is more or less useless. Attacks on SSH and the FTP protocol are possible, as well as attacks on the application protocol; If you just use the DMZ to forward a connection then you may be ...



Top 50 recent answers are included