|
|
|
|
||||||
| comp.security.ssh SSH secure remote login and tunneling tools. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 (permalink) |
|
Messages: n/a
Hébergeur: |
Nico Kadel-Garcia wrote:
> Ertugrul Soeylemez wrote: >> john yeo <newsgroups@johnyeo.com> (06-08-15 17:14:21): >> >>> enforce key+password logins >> Using public key authentication is fully appropriate, if your key >> itself is protected by a passphrase. In some environments it would >> even be harmful to use password authentication, too, because someone >> may somehow intercept your login password, and thus be able to log in >> locally (i.e. not via SSH). > > Note that this is *impossible* to enforce, unless you can scan the user's > home machines and anywhere they can log into for keys without passphrases. > It's a long-term vulnerability of SSH. > > its should be possible to generate the keypair with a suitable passphrase and set up the ssh dir so that the user cant change his key, or add any passphrase-less keys. then provide the user with the private key and passphrase. |
|
|
|
#2 (permalink) |
|
Messages: n/a
Hébergeur: |
>>>>> "NKG" == Nico Kadel-Garcia <nkadel@comcast.net> writes:
NKG> "john yeo" <newsgroups@johnyeo.com> wrote in message NKG> news:yprFg.13283$fV1.4838@fe1.news.blueyonder.co.u k... >> Nico Kadel-Garcia wrote: >>> Ertugrul Soeylemez wrote: >>>> john yeo <newsgroups@johnyeo.com> (06-08-15 17:14:21): >>>> >>>>> enforce key+password logins >>>> Using public key authentication is fully appropriate, if your key >>>> itself is protected by a passphrase. In some environments it >>>> would even be harmful to use password authentication, too, >>>> because someone may somehow intercept your login password, and >>>> thus be able to log in locally (i.e. not via SSH). >>> Note that this is *impossible* to enforce, unless you can scan >>> the user's home machines and anywhere they can log into for keys >>> without passphrases. It's a long-term vulnerability of SSH. >>> >>> >> its should be possible to generate the keypair with a suitable >> passphrase and set up the ssh dir so that the user cant change his >> key, or add any passphrase-less keys. then provide the user with >> the private key and passphrase. NKG> The user can then remove the passphrase from the key at NKG> whim. Unless you can search their computers for un-passphraed NKG> keys, you can't enforce this. Not only that, but it's a very bad idea for the sysadmin to know everyone's passphrase, and to not let people choose or change their own. -- Richard Silverman res@qoxp.net |
|
![]() |
| Outils de la discussion | |
|
|