Disable ssh-agent on boot

hello, I'd like to know how to disable ssh agent since I don't use it. It's a kde dependancy so it cannot be removed. So is there a way to make it not start on boot?

pacman -qli kde-agent
Name : kde-agent
Version : 20090801-2
URL : http://www.kde.org
Licenses : GPL LGPL FDL
Groups : None
Provides : None
Depends On : pinentry openssh qt
Optional Deps : None
Required By : kdepim-libkdepim kdeutils-kgpg
Conflicts With : None
Replaces : None
Installed Size : 8.00 K
Packager : Tobias Powalowski <[email protected]>
Architecture : i686
Build Date : Sat 01 Aug 2009 09:49:35 AM EDT
Install Date : Mon 14 Mar 2011 11:10:48 PM EDT
Install Reason : Installed as a dependency for another package
Install Script : No
Description : Startup and shutdown scripts for gpg-agent and ssh-agent in KDE
kde-agent /etc/
kde-agent /etc/kde/
kde-agent /etc/kde/env/
kde-agent /etc/kde/env/agent-startup.sh
kde-agent /etc/kde/shutdown/
kde-agent /etc/kde/shutdown/agent-shutdown.sh
You may be able to change some setting in /etc/kde/env/agent-startup.sh .

Similar Messages

  • Disable Kde ssh-agent

    hello. Is there a way  not to load or remove ssh agent while using KDE SC? I do not need ssh and I'd like it disabled for security reasons.

    anyone?

  • [SOLVED] ssh-passphrase not recognized by ssh-agent

    After an upgrade yesterday, I cannot enter my system anymore. It boots with some (rapidly passing) error messages (related to AF_UNIX) and shows me the login prompt. But fontsize isn't the one I had before, and customized keymappings of my keyboard are missing. Thus my configurations for the console have not been read.
    Then I can successfully enter my login and password - but not the ssh-passphrase asked for by ssh-agent. I typed it many times, it must be correct, but is not recognized anymore. So at this point I'm stuck. I rebooted and tried fallback Arch - with the same result.
    Then I chose the grub> shell during boot, and tab gave me a list of available commands. But I don't know what to do now.
    So my question is:
    how can I enter my system besides the ssh-passphrase problem? And if I managed to get into the system again - what might be the cause of this problem?
    EDIT:
    Ok, I tried to enter my pass-phrase as if I had an US keyboard (I have a German keyboard) and that worked. Now I can enter my system again, so I close this question. Maybe I will open another question soon, related to the root-cause of the problem (why my configuration isn't loaded on startup).
    Last edited by 4on6 (2012-11-29 11:35:01)

    After an upgrade yesterday, I cannot enter my system anymore. It boots with some (rapidly passing) error messages (related to AF_UNIX) and shows me the login prompt. But fontsize isn't the one I had before, and customized keymappings of my keyboard are missing. Thus my configurations for the console have not been read.
    Then I can successfully enter my login and password - but not the ssh-passphrase asked for by ssh-agent. I typed it many times, it must be correct, but is not recognized anymore. So at this point I'm stuck. I rebooted and tried fallback Arch - with the same result.
    Then I chose the grub> shell during boot, and tab gave me a list of available commands. But I don't know what to do now.
    So my question is:
    how can I enter my system besides the ssh-passphrase problem? And if I managed to get into the system again - what might be the cause of this problem?
    EDIT:
    Ok, I tried to enter my pass-phrase as if I had an US keyboard (I have a German keyboard) and that worked. Now I can enter my system again, so I close this question. Maybe I will open another question soon, related to the root-cause of the problem (why my configuration isn't loaded on startup).
    Last edited by 4on6 (2012-11-29 11:35:01)

  • How to disable GnuPG agent?

    When I log in gpg-agent is running. I have no idea what starts it. I use XFCE. I start OpenSSH's ssh-agent by having "eval $(ssh-agent)" in my ~/.bash_profile. I don't want to use gpg-agent. How can I disable it from starting automatically?

    I have it too. Some Googling took me here and here.
    This command did the trick for me:
    xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false
    GPG agent is a key manager used for signing/verifying entities like mail and packages (pacman!). But for pacman, you don't need the user session.
    Last edited by Rexilion (2014-02-10 14:51:54)

  • [SOLVED]ssh key persists across logins - xfce/ssh-agent/pgp-agent

    Hi,
    I am a new Arch user. I must say, that I am very happy with my installation so far. Thanks for providing a sensible Linux distribution.
    I am coming from Ubuntu 12.04 LTS with xfce as desktop. Ubuntu 12.04 has xfce 4.8.2. Now I am running lightdm and xfce 4.10 which I consider a very useful desktop environment. Now, there is one bug I ran into and I didn't see it documented anywhere :
    After logging out or even rebooting, my ssh-key was still cached/stored by gpg-agent.
    Now, well. Can't be that hard, can it?
    % ssh-add -D
    SSH_AGENT_FAILURE
    Failed to remove all identities.
    Great! Now that really bugged me: I am unable to remove my ssh-key, even across reboots!
    It took me a while to realize, that gpg-agent is now capable of handling ssh-keys.
    I was unable to find any startup configuration for gpg-agent in /etc/profile[.d], systemd, .xinitrc, ...
    Disabling xfce-session gpg-agent autostart
    After even more searching, I found xfce to be the culprit:
    http://docs.xfce.org/xfce/xfce4-session/advanced
    Apparently xfce4-session starts gpg-agent
    To disable it:
    % xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false
    Kind'a obvious, right?
    Key recovery
    To get rid of the ssh-key dangling around unencrypted (?) on your harddisk, have a look at
    $HOME/.gnupg/private-keys-v1.d
    Looks like gpg-agent is storing ssh keys here. I simply deleted the directory.
    BE CAREFUL: I don't know if the directory is only used for cached ssh keys. You might have other valid keys you don't want to delete there. Maybe someone else can shed some light on this.
    Now I have my good old ssh-agent back, started automatically as described in the wiki
    https://wiki.archlinux.org/index.php/SSH_Keys#ssh-agent
    Last edited by georgnix (2014-03-06 12:13:56)

    Thanks for reminding
    Btw, my problem/issue with gpg2's (inexistent, yet there-in-the-man-pages) "--with-keygrip" option still persists - though I am not sure if this is the place to mention about it.

  • SSH Agent in GNOME Doesn't Work

    Hey There,
    I'm using GNOME for my personal desktop needs.. I have to connect to several remote server (or PC's) in a shell and I don't want to re-enter my passwords in the same session. This is my problem:
    [14:28] (tunix@penguix ~)$ ps aux |grep ssh
    root      6264  0.0  0.0   3756   816 ?        Ss   09:03   0:00 /usr/sbin/sshd
    tunix     6457  0.0  0.0   3400   508 ?        Ss   09:05   0:00 /usr/bin/ssh-agent -- /usr/bin/gnome-session
    tunix    19141  0.0  0.0   3428   784 pts/2    R+   14:28   0:00 grep ssh
    [14:28] (tunix@penguix ~)$ ssh tunix@kulupler
    Enter passphrase for key '/home/tunix/.ssh/id_rsa':
    Last login: Sat Sep 29 14:22:37 2007 from 85.97.128.179
    [14:26] (tunix@kulupler ~)$ logout
    Connection to kulupler closed.
    [14:28] (tunix@penguix ~)$ ssh tunix@kulupler
    Enter passphrase for key '/home/tunix/.ssh/id_rsa':
    [14:28] (tunix@penguix ~)$
    So SSH Agent doesn't cache or save the passwords I enter.. So I have to enter the password each time. (Maybe this is happening because of the same reason why Seahorse doesn't working on my system.. :S)
    Thanks for any replies..

    Did you run ssh-add to tell ssh-agent which key to use ?  If not, ssh-agent will not know anything about any keys/pass phrases you enter into specific ssh sessions.
    There's a pretty good tutorial here, with all the basic steps :
    http://mah.everybody.org/docs/ssh
    WRT seahorse...
    Is seahorse-daemon running ?  I haven't used seahorse, so I only have the following as a reference :
    http://live.gnome.org/Seahorse/SSHAgent

  • Updating the system has broken ssh-agent

    Hi everyone, I recently encountered a strange problem with ssh-agent. For a very long I started it with a simple
    ssh-agent
    and everything was fine - I could add a key from a different console and everything was immediately visible in all the applications that needed SSH key authentication. However, after the last updates I noticed that simple ssh-agent no longer works - the environment variables are not exported to the system. I know I can use eval `ssh-agent`, but:
    - Once I close the console, I cannot use the ssh-agent process anymore.
    - The agent is not visible from a different console.
    - The agent is not visible from NetBeans or something similar.
    I noticed the problem for the first time in December, after switching to Arch x86_64, but I managed to get the old call working somehow. Unfortunately, I have no idea, how I did that . Now I've updated Arch x86 both on laptop and on a desktop and the problem appeared again on both of them. I found several resources about ssh-agent via Google, but nothing concerns my problem directly. Has anyone encountered a similar problem, too and knows, what is wrong with the new Arch SSH packages or how to fix it? I would appreciate any help, because SSH is critical for me and now it doesn't work correctly on any of my computers.

    I'm not sure how to directly answer your question, but here's the portion of my .bashrc I use to start the ssh agent on login. Hope it helps! I'm also running x86_64.
    SSH_ENV="$HOME/.ssh/environment"
    function start_agent {
    echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null
    /usr/bin/ssh-add;
    # Source SSH settings, if applicable
    if [ -f "${SSH_ENV}" ]; then
    . "${SSH_ENV}" > /dev/null
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
    start_agent;
    else
    start_agent;
    fi
    Good luck!
    Scott

  • Disable SSH root login in RAC system

    Hi Alll,
    We have a oracle 11.2.7 RAC in Linux. As statement, SA will disable ssh root log and Nagios will monitor each nodes in RAC system.
    As I know, Nagios only apply DH key for SSH. But Oracle RAC apply two type of SSH key for ssh_equivelancy in Oracle CRS.
    Dees any experts have experience for oracle RAC and database when disable root SSH log in Linux system?
    Thanks very much!
    JIn

    Security is not based on the number of keys one needs - but on the quality of the locks.Partially agree. But just like in real world one lock is not enough even superb. Why cars have imobilisers, defendlocks etc.? Why there is fence in front of some shop's door? It's very common to have two locks on front door. It's much harder (at least it takes much time) to break two locks than break just one. And the time matters. Back to IT security. Disabled root account is one of best practices and is reasonable because you can't 100% assure that your administrator is using strong password everytime. He might just forgot to change password after installation. He might set weak password just for "temporary" reason. You can of course force the password complexity but of course one you have the system installed.
    So can passwords. Deep packet inspection can occur unknowingly. Perhaps we still talking about SSH, don't we?
    The user may be targeted using social engineering, instead of targeting the actual computer system.It's much harder to get two passwords than just one even by using social engineering.
    The question is whether such a server is exposed to an unsecured or public network. And one would manage the risks differently on such a server than one for example in a private network, protected by a reverse proxy in the DMZ, that in turn provides access from a public network.OK, so we've got another locks here ;-)
    So if that user is compromised, so can root as that user can gain root access. I do not see this as better security. It is merely obfuscating security.Which user acccount? Do you know name of that account? Because I know the name of your's. ;-) So you need to find correct account name, get password for that account and also get the password for root account whilst I need to get password for root account only.
    Yes, partially agree with "obfuscation security" term. But in fact this is not for first time when obfuscation is used in security and neither for last time.
    But you can't consider "PermitRootLogin no" and "wheel" group as an obfuscation.
    Using encryption keys (public & private) is one answer to having to share and keep secrets. No, this is also not 100% safe, but I prefer it over having to know, remember and on occasion, share secrets (passwords).How well is your local machine secured? Are you using strong password? Do have all accounts strong password on your local machine? Is your local machine up to date for known sec. bugs (I don't mean zero days)? Is your local machine in separated VLAN or anybody from LAN can access your machine? Because if there are at least two "No" answers then how much time it will take for some skilled part-time worker (in your company) to break into your computer, steal the keys or even worse use your local machine to access the server?
    Don't get me wrong. I am not against encryption keys. Of course I am using it but in combination with other security restrictions which come from "best practices". And to disable direct root access is one of those practices. Even NSA (and other security institutions) suggest to do that (see page #37): www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf Also security auditors check for disabled direct access to privileged accounts.
    I understand this as good enough proof that disabling of direct access to privileged accounts rises security.
    Another good reason is right here:
    Install
    In other words, if any user has possibility to login as root, he uses "root" as default account which is another well known bad practice.

  • Disable automatic Agent restart

    I need to temporarily disable the agent restart when a RAC node is bounced.
    Can someone tell me how the agent is configured for automatic restart on an AIX RAC node?

    Yeah, I knew about the watchdog.
    I'm talking about server restarts though.
    I have not specifically configured the em agent (10.2.0.2) to restart when the cluster node restarts; however, it does restart on it's own. This is also the case with the non-RAC em agent installs. I could not locate anything in /etc/init.d for this purpose. I seem to recall reading something about gcstart or something like that, but I could not locate the document.
    Thanks.

  • [SOLVED] ssh-agent support removed from kde-agent

    Hi all,
    Since its upgrade yesterday, kde-agent does not support ssh-agent anymore (see here). I consequently can't store unlocked SSH keys anymore, because ssh-add from a konsole can't connect to ssh-agent.
    The update note above mentions that the SSH agent is not needed by KDE since years. What's the recommended way to start it now ?
    Thanks a lot !
    Aurélien.
    Last edited by aurelieng (2014-01-03 08:39:49)

    I have been using ssh-agent with KDE on a daily basis for years and AFAIK, there is no better or more convenient way of keeping your private keys available. So in my opinion, the removal of ssh-agent, a tiny daemon that doesn't do any harm yet serves its purpose very well, was a bad idea.
    I found a solution that does not run multiple ssh-agent daemons, even if KDE crashes. The solution is based on the fact that ssh-agent can be used as a wrapper around a session startup script or program. Unfortunately, my solution is very intrusive and will disappear on each KDE update. It works as follows:
    # cd /usr/bin
    # mv startkde startkde-inner
    # cat > startkde <<- HERE
    #!/bin/sh
    exec /usr/bin/ssh-agent /usr/bin/startkde-inner
    HERE
    # chmod +x startkde
    Now the ssh-agent will be started on each KDE session and there will always be only one ssh-agent per KDE session. Comments in the startkde script suggest starting ssh-agent later in the process and then killing it on logout. However, such a solution is inherently unreliable, because it will not kill your ssh-agent when the X-server or KDE crashes. The same problem applies to starting ssh-agent from profile scripts. The wrapper method resolves the issue in a quite reasonable way.
    Last edited by andrej.podzimek (2014-01-08 13:27:25)

  • How to get Leopard ssh agent to work if you previously used "SSH Agent" App

    Hi Everyone,
    I had previously been using the *SSH Agent* application from http://www.phil.uu.nl/~xges/ssh/ and wanted to get rid of it and use the built-in support for ssh-agent in Leopard.
    However, it didn't work. Doing "env | grep SSH" it would show /tmp/501/nl.uu.phil.SSHAgent.socket and ssh'ing from a terminal window would request your passphrase every time. Executing ssh-agent would say "no agent is running." Even deleting the *SSH Agent* app and rebooting, it would still have this phil socket.
    The solution is to use terminal, go to your home directory, cd to .MacOSX and look and see if there's an environment.plist file. In there will be some XML to set this persistent string for SSHAUTHSOCK. You need to take that out. If there's other stuff in the file, like a CVSHOME entry, hand-edit the XML to take out the SSHAUTHSOCK entry. (How to do that is beyond the scope of this post.) If the only thing is that entry, just delete the environment.plist file.
    Afterwards, reboot, or maybe just log out and log back in, open a terminal window, and you should be able to ssh out and the system will start ssh-agent behind your back and find your .ssh/id_dsa file or whatever.
    Karl

    The man page for ssh-agent provides the following documentation:
    -a bind_address
    Bind the agent to the unix-domain socket bind_address. The
    default is /tmp/ssh-XXXXXXXXXX/agent.<ppid>.
    The system ssh-agent's startup arguments are in /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist so you could add something like the following to array that defines the ProgramArguments:
    <string>-a</string>
    <string>/whatever/the/path/is/that/you/want/to/have</string>
    Note that since these mods are being done in /System, they could be wiped out by any system update. You could try making a copy of the file and putting the copy in /Library/LaunchAgents; perhaps files in that directory take precedence over files in /System. Certainly, stuff in /Library shouldn't be wiped out by a system update, though.

  • Disable SSH version1 in ACS Express 5.0

    Hi,
    Does anybody knows if it is possible to disable SSH v1 in ACS express installed in ADE 1010?
    Appreciate anybody's feedback
    Thanks.
    NetMaint

    Hi,
    This was required by our client to disable SSH v1 after the infosec audit.
    Can this be done? I tried digging but can't find any info. If this can't be done at least provide me some link so I can feedback to our client.
    Appreciate your reply.
    Regards, NetMaint

  • HT201262 how to disable discrete card on boot?

    how to disable discrete card on boot?
    My discrete card now total dead, i can only boot into safe mode, normal boot, some time very rare it pass discrete card check, then it boot in, then i used gfxGraphicsCard to force to use only integrated card, then it run fine.
    if some time i forgot to force. then run ios simulator then it auto switch to discrete card, then it's black screen and i must reboot.

    Do you have a mid 2010 15" Macbook Pro? If so, see here:
    http://support.apple.com/kb/ts4088
    If this is the problem you have, Apple will replace the logic board up to three years from date of purchase.

  • Strange ssh-agent option

    When I run "ps -e|grep ssh" I can see that /usr/bin/ssh-agent is running with a -l option. This is consistent with /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist which also shows a -l option. However, the man page for ssh-agent makes no mention of a -l option and it does not appear in the output of "strings /usr/bin/ssh-agent".
    So what is this mysterious option?

    I downloaded and inspected the source code from your link:
    http://www.opensource.apple.com/
    Here is the source entry (ssh-agent.c):
    #ifdef _APPLE_LAUNCHD_
    if (l_flag) {
    launchdatat resp, msg, tmp;
    size_t listeners_i;
    msg = launchdata_new_string(LAUNCH_KEYCHECKIN);
    resp = launch_msg(msg);
    if (NULL == resp) {
    perror("launch_msg");
    exit(1);
    launchdatafree(msg);
    switch (launchdata_gettype(resp)) {
    case LAUNCHDATAERRNO:
    errno = launchdata_geterrno(resp);
    perror("launch_msg response");
    exit(1);
    case LAUNCHDATADICTIONARY:
    break;
    default:
    fprintf(stderr, "launch_msg unknown response");
    exit(1);
    tmp = launchdata_dictlookup(resp, LAUNCHJOBKEYSOCKETS);
    if (NULL == tmp) {
    fprintf(stderr, "no sockets\n");
    exit(1);
    tmp = launchdata_dictlookup(tmp, "Listeners");
    if (NULL == tmp) {
    fprintf(stderr, "no known listeners\n");
    exit(1);
    for (listeners_i = 0; listeners_i < launchdata_array_getcount(tmp); listeners_i++) {
    launchdatat objatind = launchdata_array_getindex(tmp, listeners_i);
    newsocket(AUTHSOCKET, launchdata_get_fd(obj_atind));
    launchdatafree(resp);
    } else {
    #endif
    Appears to be a sub routine designed to generate program data, error and/or debug
    messages (if needed) whenever ssh-agent is launched automatically from launchd.
    That would explain why it is an Apple only option, since no else uses launchd.
    Kj
    note: if you feel my investigation is in error, fell free to dig through the
    source code yourself.

  • Starting ssh-agent on login

    ssh-agent is a blessing for convenient yet secure remote access, but the standard tool to start it up on login is in my opinion overly complicated. Keychain is a script in more than 1500 lines of code for doing essentially what I do in 8 lines. It does of course have tons more features, but I don't see any reason for all of that. Here's my /etc/profile.d/ssh-agent.sh, I hope somebody finds it useful:
    # If the directory ~/.ssh/agent exists, ssh-agent is started automagically.
    # The script first checks whether $HOSTNAME-sh already contains information
    # about a running ssh-agent process, in which case nothing further is done.
    # When necessary, which should only be once per reboot, ssh-agent is started
    # and the two important variables are defined in $HOSTNAME-sh for use by
    # future login sessions.
    # Tip: Put '. /etc/profile' in your ~/.xinitrc and ~/.xsession
    # This is a good idea not only because of this script.
    if [ -d $HOME/.ssh/agent ]; then
    [ -f $HOME/.ssh/agent/$HOSTNAME-sh ] && . $HOME/.ssh/agent/$HOSTNAME-sh
    if ! [ -S "$SSH_AUTH_SOCK" ]; then
    eval `/usr/bin/ssh-agent` > /dev/null
    echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > $HOME/.ssh/agent/$HOSTNAME-sh
    echo "export SSH_AGENT_PID=$SSH_AGENT_PID" >> $HOME/.ssh/agent/$HOSTNAME-sh
    fi
    fi

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by BRETT GASTON ([email protected]):
    After countless hours, I can get the command ./lsnrctl dbsnmp_start to start the Intelligent Agent. However, if I execute the command ./dbsnmp & the Intelligent Agent will start and I can then use dbsnmp_status and dbsnmp_stop as normal. I have tried relinking, reinstalling, deleting log and config files to no avail. Has anyone else had this problem?
    Brett<HR></BLOCKQUOTE>
    to start intelligent agents manually
    $ lsnrctl
    lsnrctl> help
    dbsnmp_stop
    dbsnmp_start
    dbsnmp_statusd
    lsnrctl>dbsnmp_start
    lsnrctl>exit
    or .........
    lsnrctl dbsnmp_start # to start
    lsnrctl dbsnmp_stop # to stop
    lsnrctl dbsnmp_status # to view status
    good luck
    null

Maybe you are looking for