Visit Our UNIX and Linux User Community

Linux and UNIX Man Pages

Test Your Knowledge in Computers #962
Difficulty: Medium
ILOVEYOU, sometimes referred to as Love Bug or Love Letter, was a computer worm that attacked tens of millions of Windows PCs on and after 5 May 2000 local time in the Philippines.
True or False?
Linux & Unix Commands - Search Man Pages

pam_ssh_agent_auth(8) [centos man page]

pam_ssh_agent_auth(8)							PAM						     pam_ssh_agent_auth(8)

PAM_SSH_AGENT_AUTH
       This module provides authentication via ssh-agent.  If an ssh-agent listening at SSH_AUTH_SOCK can successfully authenticate that it has
       the secret key for a public key in the specified file, authentication is granted, otherwise authentication fails.

SUMMARY
/etc/pam.d/sudo: auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys /etc/sudoers: Defaults env_keep += "SSH_AUTH_SOCK" This configuration would permit anyone who has an SSH_AUTH_SOCK that manages the private key matching a public key in /etc/security/authorized_keys to execute sudo without having to enter a password. Note that the ssh-agent listening to SSH_AUTH_SOCK can either be local, or forwarded. Unlike NOPASSWD, this still requires an authentication, it's just that the authentication is provided by ssh-agent, and not password entry. ARGUMENTS
file=<path to authorized_keys> Specify the path to the authorized_keys file(s) you would like to use for authentication. Subject to tilde and % EXPANSIONS (below) allow_user_owned_authorized_keys_file A flag which enables authorized_keys files to be owned by the invoking user, instead of root. This flag is enabled automatically whenever the expansions %h or ~ are used. debug A flag which enables verbose logging sudo_service_name=<service name you compiled sudo to use> (when compiled with --enable-sudo-hack) Specify the service name to use to identify the service "sudo". When the PAM_SERVICE identifier matches this string, and if PAM_RUSER is not set, pam_ssh_agent_auth will attempt to identify the calling user from the environment variable SUDO_USER. This defaults to "sudo". EXPANSIONS
~ -- same as in shells, a user's Home directory Automatically enables allow_user_owned_authorized_keys_file if used in the context of ~/. If used as ~user/, it would expect the file to be owned by 'user', unless you explicitely set allow_user_owned_authorized_keys_file %h -- User's Home directory Automatically enables allow_user_owned_authorized_keys_file %H -- The short-hostname %u -- Username %f -- FQDN EXAMPLES
in /etc/pam.d/sudo "auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys" The default .ssh/authorized_keys file in a user's home-directory "auth sufficient pam_ssh_agent_auth.so file=%h/.ssh/authorized_keys" Same as above. "auth sufficient pam_ssh_agent_auth.so file=~fred/.ssh/authorized_keys" If the home-directory of user 'fred' was /home/fred, this would expand to /home/fred/.ssh/authorized_keys. In this case, we have not specified allow_user_owned_authorized_keys_file, so this file must be owned by 'fred'. "auth sufficient pam_ssh_agent_auth.so file=/secure/%H/%u/authorized_keys allow_user_owned_authorized_keys_file" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar/fred/authorized_keys. In this case, we specified allow_user_owned_authorized_keys_file, so fred would be able to manage that authorized_keys file himself. "auth sufficient pam_ssh_agent_auth.so file=/secure/%f/%u/authorized_keys" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar.baz.com/fred/authorized_keys. In this case, we have not specified allow_user_owned_authorized_keys_file, so this file must be owned by root. v0.8 2009-08-09 pam_ssh_agent_auth(8)

Check Out this Related Man Page

SSH-KEYCONVER(1)					    BSD General Commands Manual 					  SSH-KEYCONVER(1)

NAME
ssh-keyconvert -- convert ssh v1 keys and authorization files SYNOPSIS
ssh-keyconvert [-k] [-o output_file] identity_file ... ssh-keyconvert [-a] [-o output_file] authorization_file ... DESCRIPTION
ssh-keyconvert converts RSA public and private keys used for public key based user authentication with protocol version 1 to the format used with protocol version 2. When using RSA user authentication with SSH protocol version 1, the client uses the private key from $HOME/.ssh/identity to provide its iden- tity to the server. The server grants or denies access based on whether the public part of this key is listed in $HOME/.ssh/authorized_keys. SSH protocol version 2 supports both DSA and RSA keys, but the way RSA keys are stored are differently. On the client, the default file name is .ssh/id_rsa rather than .ssh/identity, and the file's format is different as well. On the server, the public porting of the key can still be stored in .ssh/authorized_keys, but the key notation has changed as well. Therefore, when switching from protocol version 1 to version 2, you either have to create a new identity key using ssh-keygen(1) and add that key to the server's authorized_keys file, or you need to con- vert your keys using ssh-keyconvert. By default, ssh-keyconvert will try to guess the type of file that is to be converted. If it fails to guess correctly, you can tell if what type of conversion to perform by specifying the -k option to convert the private key, or the -a option to convert an authorisation file. When converting your private keys stored in .ssh/identity, ssh-keyconvert will read the private key, prompting you for the pass phrase if the key is protected by a pass phrase. If the -o option is given, it will write the private key to the specified file, using version 2 syntax. If the key was protected by a pass phrase, it will use the same pass phrase to protect the new file. It will also write the public portion of the key to a second file, using the specified file name with ``.pub'' appended. If the -o option was not given, private and public key will be written to id_rsa and id_rsa.pub, respectively, relative to the directory of the input key file. If the destination file already exists, ssh-keyconvert will prompt the user for confirmation before overwriting the file, unless the -f option is given. When converting your authorized_keys file, ssh-keyconvert will ignore any keys in SSH version 2 format. Any public keys in version 1 format will be converted and appended to the output file using the new syntax. If the -o option is given, keys are appended to the specified file. If it is not given, ssh-keyconvert will append all keys to the input file. Note that ssh-keyconvert does not check for duplicate keys, so if you run it on .ssh/authorized_keys more several times, the converted keys will show up several times. OPTIONS
-k Convert private key file(s). The default is to guess the type of file that should be converted. -a Convert authorized_keys file(s). The default is to guess the type of file that should be converted. -o outfile Specify the name of the output file. When converting an authorization file, all public keys will be appended to this file. For pri- vate key conversion, the private and public components of the key will be stored in outfile and outfile.pub, respectively. Note that since every key must be stored in a separate file, you cannot use this option when you specify several input files. -f When converting a key file, and the output file already exists, ssh-keyconvert will ask the user whether to overwrite the file. Using this option forces overwriting. AUTHORS
OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. ssh-keyconvert was contributed by Olaf Kirch. SEE ALSO
ssh(1), ssh-add(1), ssh-agent(1), sshd(8) J. Galbraith and R. Thayer, SECSH Public Key File Format, draft-ietf-secsh-publickeyfile-01.txt, March 2001, work in progress material. BSD
February 2, 2002 BSD

Featured Tech Videos