AW: [suse-security] SSH Authentication
I implemented a ssh conection from the outside to my intranet. This ssh requires a username and a password.
In terms of security what is more secure: require authentication (username and password) or having the public key of each user that connects to our intranet in the authorized public key lists (in this case there is no need for username and password)? In the second case there is no need of authentication and only the users wich have the public keys in the list are allowed to enter in my intranet. That's not true. If someone doesn't have the private key belonging to a certain public key in the list, he is asked for the password. Or is it possible to configure a remote computer in such a way that it doesn't give you a login prompt any more if there exists a public key?
This second solution is a good solution or that brings other security problems ? The solution with the keys is less secure than the one with passwords, of course. If Computer A connects to computer B via SSH, and there exists a pair of keys so that you don't have to enter the password, then a hacker who logged into computer A has also free access to computer B (crack one, access two). If there's no real need for a pair of keys (e.g. if a cron job copies files from A to B), then you shouldn't use that. Bye Uli
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi !
In terms of security what is more secure: require authentication (username and password) or having the public key of each user that connects to our intranet in the authorized public key lists (in this case there is no need for username and password)? In the second case there is no need of authentication and only the users wich have the public keys in the list are allowed to enter in my intranet. That's not true. If someone doesn't have the private key belonging to a certain public key in the list, he is asked for the password. Or is it possible to configure a remote computer in such a way that it doesn't give you a login prompt any more if there exists a public key?
- --> You can tell the SSH deamon not to accept passwords. See /etc/ssh/sshd_config Set: PubkeyAuthentication yes PasswordAuthentication no If you allow only port 22 (SSH) from outside, then you can only login to the computer by using an SSH public key.
This second solution is a good solution or that brings other security problems ? The solution with the keys is less secure than the one with passwords, of course. If Computer A connects to computer B via SSH, and there exists a pair of keys so that you don't have to enter the password, then a hacker who logged into computer A has also free access to computer B (crack one, access two). If there's no real need for a pair of keys (e.g. if a cron job copies files from A to B), then you shouldn't use that.
- --> But if computer A is not hacked, it is easier to brute-force crack machine B when "only" guessing a password than if the attacker has to guess a 2048bit private key. So as suggested before, if you are worried about the security of the private keys, create them with a password. Bye, Armin - -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE92Q3MG8Xv4GxznLoRAmJBAJ9O161EvxWFWwvEyJ5mB8ZHJjsquACdEDzR VIDK/u7Z2pLUdy0VcoICxPk= =5jCF -----END PGP SIGNATURE-----
This second solution is a good solution or that brings other security problems ? The solution with the keys is less secure than the one with passwords, of course. If Computer A connects to computer B via SSH, and there exists a pair of keys so that you don't have to enter the password, then a hacker who logged into computer A has also free access to computer B (crack one, access two). If there's no real need for a pair of keys (e.g. if a cron job copies files from A to B), then you shouldn't use that.
- --> But if computer A is not hacked, it is easier to brute-force crack machine B when "only" guessing a password than if the attacker has to guess a 2048bit private key. So as suggested before, if you are worried about the security of the private keys, create them with a password.
Keyexchange works the way the connected pc has an own randomly build key. With the copied key he/she cannot do anything, unless the key is not encrypted with any password. 2048 Bit is secure, but it needs more cpu-time to decode any transmissions. With this your bandwith with ssh is smaller. The only way to get in is to steal both keys by hacking one of your clients. Then he/she can fake ip/hostname and can log in, but there is a chance 1:1.000.000 that this will happen. Another method is to sniff your network with tools like dsniff (even gets secure connections somehow). All those hacking stuff is quite to much to do. Normally you will be safe, if there is no crond job that is done serveal times by key-exchange authentification. If you want extra security change the allowed hosts in /etc/hosts.allow to only allow a range of hosts/ips connect. See tcpd(8) and hosts_access(5) for a description of /etc/hosts.allow. Don't use a key without a passphrase or anyone who has your key can login from everywhere! The key exchange works fine for me to shutdown a server over ssh from the script started by a usv. Therefor I don't need a second serial module for my usv. This is only done, if we got total power down (we had it only one time yet). Philippe
participants (3)
-
Armin Schöch -
Philippe Vogel -
Ulrich Roth