PAM and OpenSSH in 4.3-20010906-STABLE
Greetings, I'm pretty new to this -stable business, so maybe my problem is due to my inexperience, but here goes: I have two freshly installed stable boxes - both installed from a snap-server. One box from 20010604 [1] and one from 20010609 [2]. The last one won't let me use rsa or dsa keys to log in via slogin. Password authentication works. [1] works fine with both key- and password auth.. I cant really see the difference between these boxes, but nevertheless on [2] I get: sshd[27906]: fatal: PAM setcred failed[6]: Permission denied Below is a dump from sshd in debug mode.. Any ideas? Otherwise I hope the problem will go away by itself :-) / IE debug1: sshd version OpenSSH_2.3.0 [EMAIL PROTECTED] 20010321 debug1: read DSA private key done debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from remote host port 723 Connection from remote host ip port 723 debug1: Client protocol version 2.0; client software version OpenSSH_2.5.1p1 debug1: no match: OpenSSH_2.5.1p1 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.3.0 [EMAIL PROTECTED] 20010321 debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug1: got kexinit: ssh-rsa,ssh-dss debug1: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[EMAIL PROTECTED] debug1: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[EMAIL PROTECTED] debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug1: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug1: got kexinit: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client-server 3des-cbc hmac-sha1 none debug1: kex: server-client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. debug1: bits set: 1039/2049 debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP. debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT. debug1: bits set: 1049/2049 debug1: sig size 20 20 debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: userauth-request for user user service ssh-connection method none debug1: attempt #1 debug1: Starting up PAM with username user Failed none for user from remote host ip port 723 ssh2 debug1: userauth-request for user user service ssh-connection method publickey debug1: attempt #2 debug1: matching key found: file /home/user/.ssh/authorized_keys2, line 1 debug1: len 55 datafellows 0 debug1: dsa_verify: signature correct debug1: PAM setting rhost to remote host Accepted publickey for user from remote host ip port 723 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 32768 max 16384 debug1: open session debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: confirm session debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 debug1: session_pty_req: session 0 alloc /dev/ttyp3 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0 debug1: Received request for X11 forwarding with auth spoofing. debug1: bind port 6010: Address already in use debug1: fd 8 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug1: fd 9 setting O_NONBLOCK debug1: fd 9 IS O_NONBLOCK debug1: channel 2: new [X11 inet listener] debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 debug1: PAM setting tty to /dev/ttyp3 debug1: do_pam_session: euid 0, uid 0 debug1: PAM establishing creds fatal: PAM setcred failed[6]: Permission denied debug1: Calling cleanup 0x8054fa4(0x807c880) debug1: xauthfile_cleanup_proc called debug1: Calling cleanup 0x8055018(0x807c880) debug1: pty_cleanup_proc: /dev/ttyp3 debug1: Calling cleanup 0x8066bf8(0x0) debug1: channel_free: channel 1: status: The following connections are open: #0 server-session (t10 r0 i1/0 o16/0 fd -1/-1) debug1: channel_free: channel 2: status: The following connections are open: #0 server-session (t10 r0 i1/0 o16/0 fd -1/-1) debug1: Calling cleanup 0x8058bf4(0x0) debug1: Cannot delete credentials[6]: Permission
Re: Going -stable - not as easy as you'd think?
On Sunday 10 June 2001 6:50 pm, Mixtim wrote: Is it related to the recent ipfilter migration to contrib/ ? A lot of people must have a bad source tree or wacky /etc/make.conf options. I've done several make buildworld's with 4.3-STABLE since the IPFilter move and haven't had a single build failure. And yes, I use IPFilter. Hmmm, none of the machines I've been building have actually used it, or had it anywhere in the kernel config... As for 'wacky make.conf'? - Not here :) - Source trees? - The jury's still out - on two of the three machines I'd blown away the whole of /usr/src and re-cvsup'd to see if that fixed... I guess it must (hope) it's just a 'bad patch' [excuse the pun, please :)] -Kp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: PAM and OpenSSH in 4.3-20010906-STABLE
On Sun, 10 Jun 2001, Ivan Eriksen wrote: sshd[27906]: fatal: PAM setcred failed[6]: Permission denied Forget the above - I see, that you guys already discussed the problem. I'll go read the archives instead. Thanks! / IE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
unknown option TCP_RESTRICT_RST ?
Hello to all, I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10, when I'm make buildkernel I got the error: unknown option TCP_RESTRICT_RST . Does this option has been deprecated? Thanks very much, -- Nuno Teixeira Dir. Técnico pt-quorum.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: unknown option TCP_RESTRICT_RST ?
On 2001.06.10 13:05 Nuno Teixeira wrote: Hello to all, I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10, when I'm make buildkernel I got the error: unknown option TCP_RESTRICT_RST . Does this option has been deprecated? Thanks very much, -- Nuno Teixeira Dir. Técnico pt-quorum.com I believe support for it needs to be compiled-in to your kernel. Look at LINT, etc. for details. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: unknown option TCP_RESTRICT_RST ?
Hi, Yes, I looked at LINT file, and this tag is missing. The strange thing is that I make a buildkernel 4 days ago and everything is fine and now I got the this error. Bye, -- Nuno Teixeira Dir. Técnico pt-quorum.com -- PGP Pwublic Key: http://www.pt-quorum.com/pgp/nunoteixeira.asc Key fingerprint: 8C2C B364 D4DC 0C92 56F5 CE6F 8F07 720A 63A0 4FC7 -- On Sun, 10 Jun 2001, John Merryweather Cooper wrote: On 2001.06.10 13:05 Nuno Teixeira wrote: Hello to all, I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10, when I'm make buildkernel I got the error: unknown option TCP_RESTRICT_RST . Does this option has been deprecated? Thanks very much, -- Nuno Teixeira Dir. Técnico pt-quorum.com I believe support for it needs to be compiled-in to your kernel. Look at LINT, etc. for details. jmc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: unknown option TCP_RESTRICT_RST ?
On Sun, Jun 10, 2001 at 09:05:26PM +0100, Nuno Teixeira wrote: Hello to all, I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10, when I'm make buildkernel I got the error: unknown option TCP_RESTRICT_RST . Does this option has been deprecated? [from cvs-all] Date: Sat, 9 Jun 2001 09:18:15 -0700 (PDT) From: Dag-Erling Smorgrav [EMAIL PROTECTED] Log: MFC: Nuke the TCP_RESTRICT_RST option. [/from cvs-all] -- Kirill Ponomarew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Going -stable - not as easy as you'd think?
On Sun, 10 Jun 2001, Mixtim wrote: A lot of people must have a bad source tree or wacky /etc/make.conf options. It turns out that I had some bad .depend files around the source tree, and just removing /usr/obj didn't fix the problem. I removed all them and everything went fine :o) -- jimmy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
fatal trap 12 while copying files from a currupt filesystem?
Hi!
My system has a fatal trap 12 during copying files from one filesystem
to another.
The story:
- crashed filesystem during heavy load with ide write cashe enabled
- to many errors after fsck...newfs
newfs -v -b 32768 -f 4096 -i 2 -c 50 /dev/vinum/dhea-stripe
- filesystem restored (tape)
The result was a corrupted filesystem. Don't really know why but
that is not the problem at this point. I didn't know it at this
point. That may happen. :(
First crash happened during dumping the filesystem. The percent
counter ran over 100% - panic.
After looking on the files I found some 0-bytes-files and
decided that the filesystem must be corrupt. Copying the whole
file-structure with tar from this filesystem to another also
results in a panic.
A corrupt filesystem may happen but it should not panic the system.
There are no hints about the problem in the logfiles. So how could
i find the error? Finding the 0-byte-files was really luck. fsck
runs over the filesystem and says that it is fine.
It may log read-errors or something like that. But panic? I think
that is a bit to heavy. *g*
The system is 4.3-stable cvsupped around 2 weeks ago. If you need any
more information let me know.
Jens Trzaska
--
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.1
(kgdb) core-file /var/crash/vmcore.1
SMP 2 cpus
IdlePTD 3489792
initial pcb at 2c6800
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x1c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc165b579
stack pointer = 0x10:0xd5fe0c8c
frame pointer = 0x10:0xd5fe0c98
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14416 (tar)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... 170 134 67 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers
Uptime: 3h3m27s
dumping to dev #da/0x20001, offset 1048704
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498
497 496
495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478
477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460
459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442
441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424
423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406
405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388
387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370
369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352
351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334
333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316
315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298
297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280
279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262
261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244
243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226
225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208
207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190
189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154
153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136
135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118
117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100
99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76
75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52
51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
#1 0xc01604bb in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:309
#2 0xc016086c in poweroff_wait (junk=0xc0299b8f, howto=-706226144) at
/usr/src/sys/kern/kern_shutdown.c:556
#3 0xc025ddd3 in trap_fatal (frame=0xd5fe0c4c, eva=28) at
/usr/src/sys/i386/i386/trap.c:951
#4 0xc025da69 in trap_pfault (frame=0xd5fe0c4c, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:844
#5 0xc025d603 in trap (frame={tf_fs = 24, tf_es = -704774128, tf_ds =
-1050345456, tf_edi = 396, tf_esi = -1033618496, tf_ebp = -704770920,
tf_isp = -704770952, tf_ebx =
Re: Going -stable - not as easy as you'd think?
Jimmy Olgeni wrote: On Sun, 10 Jun 2001, Mixtim wrote: A lot of people must have a bad source tree or wacky /etc/make.conf options. It turns out that I had some bad .depend files around the source tree, and just removing /usr/obj didn't fix the problem. I removed all them and everything went fine :o) Shortly after this thread appeared, I cvsup'ed and rebuilt 4.3-stable just fine. The .depend's might be something that a make cleandir would remove. Kent -- jimmy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
USB Smartmedia readers
Following up on previous correspondance, I can confirm that both models of the FujiFilm USB SmartMedia readers (the obsolete SM-R1 and the current SM-R2) work OK with FreeBSD 4.3. In fact, they seem almost identical, apart from the fact that the case is now painted gloss purple rather than matt grey. On the inside, the PCB has had a re-layout but appears to have much the same chipset. They've forgotten to private-label the firmware in the new version: SM-R1 (empty): umass0: Fuji Photo Film SmartMedia R/W, rev 1.00/1.00, addr 4 umass0: Get Max Lun not supported (STALLED) da1 at umass-sim0 bus 0 target 0 lun 0 da1: GENERIC SmartMedia R/W 1.00 Removable Direct Access SCSI-2 device da1: 650KB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present SM-R2 (with card loaded): umass0: Hagiwara Sys-Com SmartMedia R/W, rev 1.10/2.00, addr 5 umass0: Get Max Lun not supported (STALLED) da1 at umass-sim0 bus 0 target 0 lun 0 da1: HAGIWARA SmartMedia R/W 2.00 Removable Direct Access SCSI-2 device da1: 650KB/s transfers da1: 62MB (128000 512 byte sectors: 64H 32S/T 62C) Performance is good: reading through the filesystem gives a shade over 700Kbyte/sec; reading the raw device depends on the block size - with a 32K block size you get the same 700Kbyte/sec, down to about 80Kbyte/sec with 512byte block. Writing is slower - about 150 to 200Kbyte/sec. Software notes: 1) Hot-plugging the USB doesn't work: the device has to be connected at boot time for it to get properly associated with the CAM subsystem (doesn't matter if there is a card in the drive or not). After attempts to hot-plug, camcontrol devlist reports that the USB device is associated with pass1 but not da1, and camcontrol rescan 1 hangs forever, sometimes leading to a panic if you then unplug. 2) The USB controller gets scanned before the SCSI controllers (at least in my system), so you need a kernel with the SCSI devices wired down if your root is on a SCSI drive (to avoid trying to mount root from the smartmedia). 3) The standard SmartMedia formatting has a full FDISK table and a DOS filesystem on it, so mount -t msdos /dev/da1s1 /mnt is required to mount a card written from a camera. 4) camcontrol eject da1 turns off the drive active LED allowing the card to be removed (Fuji seem to be paranoid about this: there is a sticker on the top warning you not to try removing the card while the LED is on; there's a sensor attached to the eject lever that (presumably) allows the firmware to power down the card if you press the lever intemperately, and in any case the contacts on the card are designed so that GND disconnects last and so you'd be unlucky to blow it up anyhow). 5) camcontrol format da1 will re-write the low-level format. This is useful if you have cards that have been used in a Rio MP3 player: the Rio uses a proprietary low-level format, and my (olympus) camera refuses to touch cards that have been used in the Rio, even with the menu option to format the card. After a low-level format in the reader, the camera is then happy to high-level format the card and you are back in business. As an aside, I also tried a very cheap smartmedia reader: ugen0: SCM Microsystems Inc. SCM eUSB SmartMedia , rev 1.00/1.00, addr 5 This is sold here as the Cardport Swift and claims to be made in the UK, (though I have my doubts, given the above ident string and I am fairly sure I've seen this OR-gate shaped housing elsewhere - see http://www.premierelect.co.uk/CARDportSwift.html for a picture). This unit does NOT work with FreeBSD. Compared to Fuji's concern over ejecting, this unit has no LEDs or eject levers at all - you just yank the card out when you feel like it. Surprisingly, their supplied Windows drivers don't crash when you do this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Disk geometry oddity
:: By allowing sysinstall to use a more likely geometry, it :: fixed the problem, :: see also FAQ 1.17. Silly question, perhaps, but if you change to the more likely geometry with the G key, would you lose data? :: In case you weren't aware, dangerously dedicated mode is :: still available, :: albeit not recommended, using the (purposely) undocumented 'F' key. No, I gather so, but it's an existing installation with two dangerously dedicated disks. Thanks! -- Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
