[opensuse-security] ssh-ing to an old suse.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses. Today I tried to ssh to it, and i can't: the ssh session stays for ever like this: cer@nimrodel:~> ssh telperion.valinor never asking for the password. What is going on? It worked with 10.2, I think. I know it is not a network issue. It may be related to an authentication method that has changed defaults in 10.3, but I don't know what exactly. There is no entry in the logs. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHQZUDtTMYHG2NR9URAlG7AJ4pLwjrRwgeT/pzMrCNOabhhfSz8QCbB1NM AAjxA7IdKLe3VV6owEpKlKA= =a/67 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Try the verbose mode on the client (I think it was -v). Maybe it is an v1-v2 issue. Good luck, Lars. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Mon, Nov 19, 2007 at 02:51:50PM +0100, Carlos E. R. wrote:
Hi,
I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses.
Today I tried to ssh to it, and i can't: the ssh session stays for ever like this:
cer@nimrodel:~> ssh telperion.valinor
never asking for the password. What is going on? It worked with 10.2, I think.
I know it is not a network issue. It may be related to an authentication method that has changed defaults in 10.3, but I don't know what exactly. There is no entry in the logs.
Firewall? Try ssh -v telperion.valinor to see where it hangs. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. napsal(a):
Hi,
I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses.
Today I tried to ssh to it, and i can't: the ssh session stays for ever like this:
cer@nimrodel:~> ssh telperion.valinor
never asking for the password. What is going on? It worked with 10.2, I think.
I know it is not a network issue. It may be related to an authentication method that has changed defaults in 10.3, but I don't know what exactly. There is no entry in the logs.
Try this: ssh -v telperion.valinor or even ssh -vv telperion.valinor Debug output should tell you more. Bye Lukas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-11-19 at 14:54 +0100, Lukas Ocilka wrote:
Try this:
ssh -v telperion.valinor
or even
ssh -vv telperion.valinor
Debug output should tell you more.
Ah, I forgot that one. Ok, single "-v": cer@nimrodel:~> ssh -v telperion.valinor OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /home/cer/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to telperion.valinor [192.168.1.11] port 22. debug1: Connection established. debug1: identity file /home/cer/.ssh/id_rsa type 1 debug1: identity file /home/cer/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'telperion.valinor' is known and matches the DSA host key. debug1: Found key in /home/cer/.ssh/known_hosts:13 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received And there it stops. Lets try double -vv. cer@nimrodel:~> ssh -vv telperion.valinor OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /home/cer/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to telperion.valinor [192.168.1.11] port 22. debug1: Connection established. debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/cer/.ssh/id_rsa type 1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/cer/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 145/256 debug2: bits set: 530/1026 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'telperion.valinor' is known and matches the DSA host key. debug1: Found key in /home/cer/.ssh/known_hosts:13 debug2: bits set: 510/1026 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received I have also enabled debug mode in the server side (7.3). I'll have to do tricks to paste the server log here... [...] (scp-ing /var/log/messages from 7.3 to 10.3) Importing server side log: Nov 19 21:08:39 telperion sshd[2387]: Connection closed by ::ffff:192.168.1.12 Nov 19 21:09:39 telperion sshd[2388]: Connection closed by ::ffff:192.168.1.12 Nov 19 21:12:05 telperion sshd[974]: Received signal 15; terminating. Nov 19 21:12:06 telperion sshd[2414]: debug1: Bind to port 22 on ::. Nov 19 21:12:06 telperion sshd[2414]: Server listening on :: port 22. Nov 19 21:12:06 telperion sshd[2414]: debug1: Bind to port 22 on 0.0.0.0. Nov 19 21:12:06 telperion sshd[2414]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. Nov 19 21:12:06 telperion sshd[2414]: Generating 768 bit RSA key. Nov 19 21:12:07 telperion sshd[2414]: RSA key generation complete. Nov 19 21:12:26 telperion sshd[2422]: Connection from ::ffff:192.168.1.12 port 29244 Nov 19 21:12:26 telperion sshd[2414]: debug1: Forked child 2422. Nov 19 21:12:26 telperion sshd[2422]: debug1: Client protocol version 2.0; client software version OpenSSH_4.6 Nov 19 21:12:26 telperion sshd[2422]: debug1: match: OpenSSH_4.6 pat ^OpenSSH Nov 19 21:12:26 telperion sshd[2422]: Enabling compatibility mode for protocol 2.0 Nov 19 21:12:26 telperion sshd[2422]: debug1: Local version string SSH-1.99-OpenSSH_2.9p2 Nov 19 21:12:26 telperion sshd[2422]: debug1: Rhosts Authentication disabled, originating port not trusted. Nov 19 21:12:26 telperion sshd[2422]: debug1: list_hostkey_types: ssh-dss Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_KEXINIT sent Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_KEXINIT received Nov 19 21:12:26 telperion sshd[2422]: debug1: kex: client->server aes128-cbc hmac-md5 none Nov 19 21:12:26 telperion sshd[2422]: debug1: kex: server->client aes128-cbc hmac-md5 none Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Nov 19 21:12:26 telperion sshd[2422]: debug1: dh_gen_key: priv key bits set: 122/256 Nov 19 21:12:26 telperion sshd[2422]: debug1: bits set: 531/1026 Nov 19 21:12:26 telperion sshd[2422]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Nov 19 21:12:26 telperion sshd[2422]: debug1: bits set: 525/1026 Nov 19 21:12:26 telperion sshd[2422]: debug1: sig size 20 20 Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Nov 19 21:12:26 telperion sshd[2422]: debug1: kex_derive_keys Nov 19 21:12:26 telperion sshd[2422]: debug1: newkeys: mode 1 Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_NEWKEYS sent Nov 19 21:12:26 telperion sshd[2422]: debug1: waiting for SSH2_MSG_NEWKEYS Nov 19 21:12:26 telperion sshd[2422]: debug1: newkeys: mode 0 Nov 19 21:12:26 telperion sshd[2422]: debug1: SSH2_MSG_NEWKEYS received Nov 19 21:12:26 telperion sshd[2422]: debug1: KEX done Nov 19 21:13:09 telperion sshd[2422]: Connection closed by ::ffff:192.168.1.12 Nov 19 21:13:09 telperion sshd[2422]: debug1: Calling cleanup 0x8068e70(0x0) Nov 19 21:14:32 telperion login: FAILED LOGIN 1 FROM /dev/tty2 FOR cer, Authentication failure (the connection closes when I type ^C) Well, it seems that it is the client side, 10.3, which is stuck. Both logs are very similar, I think, to the best of my limited knowledge. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHQe8etTMYHG2NR9URAlPdAJ9vcZJSuKbDTXLPGs/dkGuFgdpkWACaAowY O4ygS0dC3R4o3l0eqc7P6M0= =KV+J -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
On Mon, Nov 19, 2007 at 09:16:21PM +0100, Carlos E. R. wrote:
The Monday 2007-11-19 at 14:54 +0100, Lukas Ocilka wrote:
or even
ssh -vv telperion.valinor
Debug output should tell you more.
ssh has three debug levels. You can also try ssh -vvv
And there it stops. Lets try double -vv.
cer@nimrodel:~> ssh -vv telperion.valinor OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /home/cer/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to telperion.valinor [192.168.1.11] port 22. debug1: Connection established. debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/cer/.ssh/id_rsa type 1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/cer/.ssh/id_dsa type 2
You have no type2 rsa key, only type2 dss and type1 rsa keys. It seems that both keys have been create with another software. Because most installations default to type2 rsa, you may try to generate a key on 10.3 with ssh-keygen -t rsa -f <keyfile> Use this new key as ~/.ssh/id_rsa on the 10.3 side and add the public key to ~/.ssh/authorized_kes on the 7.3 side (the private type1 key is usally expected in ~/.ssh/identity).
debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received
At least the host keys seems to be okay. To find out more about the user authentication, you should increase the loglevel and compare the ssh_config on the client side with the sshd_config on the server side (esp. parameters like ChallengeResponseAuthentication, UsePrivilegeSeparation, UsePAM that had issues in older ssh versions).
I have also enabled debug mode in the server side (7.3). I'll have to do tricks to paste the server log here...
[...] (scp-ing /var/log/messages from 7.3 to 10.3)
Importing server side log:
Nov 19 21:08:39 telperion sshd[2387]: Connection closed by ::ffff:192.168.1.12 Nov 19 21:09:39 telperion sshd[2388]: Connection closed by ::ffff:192.168.1.12 Nov 19 21:12:05 telperion sshd[974]: Received signal 15; terminating. Nov 19 21:12:06 telperion sshd[2414]: debug1: Bind to port 22 on ::. Nov 19 21:12:06 telperion sshd[2414]: Server listening on :: port 22. Nov 19 21:12:06 telperion sshd[2414]: debug1: Bind to port 22 on 0.0.0.0. Nov 19 21:12:06 telperion sshd[2414]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Are you sure that sshd is listening on th correct IP (v4 or v6) and port?
Hi Carlos, On Mon, Nov 19, 2007 at 02:51:50PM +0100, Carlos E. R. wrote:
Hi,
I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses.
Today I tried to ssh to it, and i can't: the ssh session stays for ever like this:
cer@nimrodel:~> ssh telperion.valinor
never asking for the password. What is going on? It worked with 10.2, I think.
Just to understand correctly: telperion is the suse 7.3 machine? And ssh from 7.3 to 10.3 works but not the other way round? Can you tell us the version of ssh on both sites? Regards, Michel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-11-19 at 15:49 +0100, Michel Messerschmidt wrote:
Just to understand correctly: telperion is the suse 7.3 machine?
Yep.
And ssh from 7.3 to 10.3 works but not the other way round?
Yep. Further more, from 7.3 to 10.3 it works without password, because I set it with keys years ago: the config has survived several system updates in the now 10.3 machine, always working, except now in 10.3. 7.3 --> 10.3 works, passwordless 10.3 --> 7.3 does not work (password mode).
Can you tell us the version of ssh on both sites?
openssh-4.6p1-58.1 (10.3) openssh-2.9p2-39 (7.3) I know that 7.3 may not be secure, but this is a controlled local network (home) and the machine is used for testing. I might try installing a newer, but small footprint, distro, if I'm sufficiently bored one day ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHQfG2tTMYHG2NR9URAnn6AJ4sMGahUIg/C5W9+gSo0twGQaDnbwCfZVHp eOE6Dgrxxufmtrhkwh42rCc= =GSgW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-11-19 at 14:51 +0100, Carlos E. R. wrote:
I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses.
Today I tried to ssh to it, and i can't: the ssh session stays for ever like this:
cer@nimrodel:~> ssh telperion.valinor
never asking for the password. What is going on? It worked with 10.2, I think.
I learnt that I had problems ssh-ing to any destination, but only with my current user: cer@nimrodel:~> ssh 1234@router {no response} Finally, I discovered that the culprit is ssh-agent (by looking at the environment). This works instantly: cer@nimrodel:~> SSH_AGENT_PID='' SSH_ASKPASS='' SSH_AUTH_SOCK='' ssh 1234@router 1234@router's password: -> In my current session: cer@nimrodel:~> set | grep SSH_ SSH_AGENT_PID=6701 SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass SSH_AUTH_SOCK=/tmp/ssh-mypMH6659/agent.6659 There is such an agent running: cer@nimrodel:~> ps ax | grep 6701 6701 ? Ss 0:00 /usr/bin/ssh-agent /bin/bash /home/cer/.xinitrc 27355 pts/18 S+ 0:00 grep 6701 cer@nimrodel:~> And the files do exist: cer@nimrodel:~> ls -l /usr/lib/ssh/x11-ssh-askpass /tmp/ssh-mypMH6659/agent.6659 srw------- 1 cer users 0 2007-12-25 14:49 /tmp/ssh-mypMH6659/agent.6659 -rwxr-xr-x 1 root root 30860 2007-12-12 14:55 /usr/lib/ssh/x11-ssh-askpass But my only option to ssh is to disable the agent. If I start seahorse, preferences, it hangs (it worked previously). If I do: cer@nimrodel:~> seahorse-preferences (seahorse-preferences:1724): GConf-WARNING **: Owner of /tmp/gconfd-cer3 is not the current user ** (seahorse-preferences:1724): WARNING **: Another GPG agent may be running. Disabling cache preferences. and it doesn't display. If I look up the process list, I see: 6847 ? Ss 0:00 seahorse-agent --sm-config-prefix /seahorse-agent-xqyZu2/ --sm-client-id 11c0a8010c000119470830500000184410000 --screen 0 6848 ? Ss 0:00 /usr/bin/seahorse-agent 6849 ? Ss 0:00 seahorse-agent --sm-config-prefix /seahorse-agent-V2r6aH/ --sm-client-id 11c0a8010c000119470880700000205230004 --screen 0 Two agents with very similar PID and ID, so they were started almost simultaneously. I kill -9 the second one (PID 6849), and now seahorse-preferences does work. Under the "passphrase cache" tab I read that "no ssh caching agent is running. Cannot load secure shell keys" - which is false, ssh-agent is running. If I kill the 6848 agent, then it claims there is no agent running, but that's also false, 6847 is running. Another time I'll kill in reverse order. But now I can at last ssh - although my passwords are not cached, the shh-agent thing is useless :-( I this a bug? Have I something wrong? Is this known? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHc82BtTMYHG2NR9URAgT4AJ9IPsJThVhyTSBEmoZ9+PtbC9ZDJwCfbRbv toAahnUi0MvkzOcVacughzU= =9VYu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (5)
-
Carlos E. R. -
Lars O. Grobe -
Lukas Ocilka -
Marcus Meissner -
Michel Messerschmidt